inspec 2.0.16 → 2.0.17

data/docs/resources/security_policy.md.erb

@@ -1,47 +1,47 @@
----
-title: About the security_policy Resource
-platform: windows
----
-
-# security_policy
-
-Use the `security_policy` InSpec audit resource to test security policies on the Windows platform.
-
-<br>
-
-## Syntax
-
-A `security_policy` resource block declares the name of a security policy and the value to be tested:
-
-    describe security_policy do
-      its('policy_name') { should eq 'value' }
-    end
-
-where
-
-* `'policy_name'` must specify a security policy
-* `{ should eq 'value' }` tests the value of `policy_name` against the value declared in the test
-
-<br>
-
-## Examples
-
-The following examples show how to use this InSpec audit resource.
-
-### Verify that only the Administrators group has remote access
-
-    describe security_policy do
-      its('SeRemoteInteractiveLogonRight') { should eq '*S-1-5-32-544' }
-    end
-
-<br>
-
-## Matchers
-
-For a full list of available matchers, please visit our [matchers page](https://www.inspec.io/docs/reference/matchers/).
-
-### policy_name
-
-The `policy_name` matcher must be the name of a security policy:
-
-    its('SeNetworkLogonRight') { should eq '*S-1-5-11' }
+---
+title: About the security_policy Resource
+platform: windows
+---
+
+# security_policy
+
+Use the `security_policy` InSpec audit resource to test security policies on the Windows platform.
+
+<br>
+
+## Syntax
+
+A `security_policy` resource block declares the name of a security policy and the value to be tested:
+
+    describe security_policy do
+      its('policy_name') { should eq 'value' }
+    end
+
+where
+
+* `'policy_name'` must specify a security policy
+* `{ should eq 'value' }` tests the value of `policy_name` against the value declared in the test
+
+<br>
+
+## Examples
+
+The following examples show how to use this InSpec audit resource.
+
+### Verify that only the Administrators group has remote access
+
+    describe security_policy do
+      its('SeRemoteInteractiveLogonRight') { should eq '*S-1-5-32-544' }
+    end
+
+<br>
+
+## Matchers
+
+For a full list of available matchers, please visit our [matchers page](https://www.inspec.io/docs/reference/matchers/).
+
+### policy_name
+
+The `policy_name` matcher must be the name of a security policy:
+
+    its('SeNetworkLogonRight') { should eq '*S-1-5-11' }

data/docs/resources/service.md.erb

@@ -1,121 +1,121 @@
----
-title: About the service Resource
-platform: os
----
-
-# service
-
-Use the `service` InSpec audit resource to test if the named service is installed, running and/or enabled.
-
-Under some circumstances, it may be necessary to specify the service manager by using one of the following service manager-specific resources: `bsd_service`, `launchd_service`, `runit_service`, `systemd_service`, `sysv_service`, or `upstart_service`. These resources are based on the `service` resource.
-
-<br>
-
-## Syntax
-
-A `service` resource block declares the name of a service and then one (or more) matchers to test the state of the service:
-
-    describe service('service_name') do
-      it { should be_installed }
-      it { should be_enabled }
-      it { should be_running }
-    end
-
-where
-
-* `('service_name')` must specify a service name
-* `be_installed`, `be_enabled`, and `be_running` are valid matchers for this resource
-
-<br>
-
-## Examples
-
-The following examples show how to use this InSpec audit resource.
-
-### Test if the postgresql service is both running and enabled
-
-    describe service('postgresql') do
-      it { should be_enabled }
-      it { should be_running }
-    end
-
-### Test if the mysql service is both running and enabled
-
-    describe service('mysqld') do
-      it { should be_enabled }
-      it { should be_running }
-    end
-
-### Test if ClamAV (an antivirus engine) is installed and running
-
-    describe package('clamav') do
-      it { should be_installed }
-      its('version') { should eq '0.98.7' }
-    end
-
-    describe service('clamd') do
-      it { should_not be_enabled }
-      it { should_not be_installed }
-      it { should_not be_running }
-    end
-
-### Test Unix System V run levels
-
-On targets that are using SystemV services, the existing run levels can also be checked:
-
-    describe service('sshd').runlevels do
-      its('keys') { should include(2) }
-    end
-
-    describe service('sshd').runlevels(2,4) do
-      it { should be_enabled }
-    end
-
-### Override the service manager
-
-Under some circumstances, it may be required to override the logic in place to select the right service manager. For example, to check a service managed by Upstart:
-
-    describe upstart_service('service') do
-      it { should_not be_enabled }
-      it { should be_installed }
-      it { should be_running }
-    end
-
-This is also possible with `systemd_service`, `runit_service`, `sysv_service`, `bsd_service`, and `launchd_service`. Provide the control command when it is not to be found at the default location. For example, if the `sv` command for services managed by runit is not in the `PATH`:
-
-    describe runit_service('service', '/opt/chef/embedded/sbin/sv') do
-      it { should be_enabled }
-      it { should be_installed }
-      it { should be_running }
-    end
-
-### Verify that IIS is running
-
-    describe service('W3SVC') do
-      it { should be_installed }
-      it { should be_running }
-    end
-
-<br>
-
-## Matchers
-
-For a full list of available matchers, please visit our [matchers page](https://www.inspec.io/docs/reference/matchers/).
-
-### be_enabled
-
-The `be_enabled` matcher tests if the named service is enabled:
-
-    it { should be_enabled }
-
-### be_installed
-
-The `be_installed` matcher tests if the named service is installed:
-
-    it { should be_installed }
-
-### be_running
-
-The `be_running` matcher tests if the named service is running:
-
-    it { should be_running }
+---
+title: About the service Resource
+platform: os
+---
+
+# service
+
+Use the `service` InSpec audit resource to test if the named service is installed, running and/or enabled.
+
+Under some circumstances, it may be necessary to specify the service manager by using one of the following service manager-specific resources: `bsd_service`, `launchd_service`, `runit_service`, `systemd_service`, `sysv_service`, or `upstart_service`. These resources are based on the `service` resource.
+
+<br>
+
+## Syntax
+
+A `service` resource block declares the name of a service and then one (or more) matchers to test the state of the service:
+
+    describe service('service_name') do
+      it { should be_installed }
+      it { should be_enabled }
+      it { should be_running }
+    end
+
+where
+
+* `('service_name')` must specify a service name
+* `be_installed`, `be_enabled`, and `be_running` are valid matchers for this resource
+
+<br>
+
+## Examples
+
+The following examples show how to use this InSpec audit resource.
+
+### Test if the postgresql service is both running and enabled
+
+    describe service('postgresql') do
+      it { should be_enabled }
+      it { should be_running }
+    end
+
+### Test if the mysql service is both running and enabled
+
+    describe service('mysqld') do
+      it { should be_enabled }
+      it { should be_running }
+    end
+
+### Test if ClamAV (an antivirus engine) is installed and running
+
+    describe package('clamav') do
+      it { should be_installed }
+      its('version') { should eq '0.98.7' }
+    end
+
+    describe service('clamd') do
+      it { should_not be_enabled }
+      it { should_not be_installed }
+      it { should_not be_running }
+    end
+
+### Test Unix System V run levels
+
+On targets that are using SystemV services, the existing run levels can also be checked:
+
+    describe service('sshd').runlevels do
+      its('keys') { should include(2) }
+    end
+
+    describe service('sshd').runlevels(2,4) do
+      it { should be_enabled }
+    end
+
+### Override the service manager
+
+Under some circumstances, it may be required to override the logic in place to select the right service manager. For example, to check a service managed by Upstart:
+
+    describe upstart_service('service') do
+      it { should_not be_enabled }
+      it { should be_installed }
+      it { should be_running }
+    end
+
+This is also possible with `systemd_service`, `runit_service`, `sysv_service`, `bsd_service`, and `launchd_service`. Provide the control command when it is not to be found at the default location. For example, if the `sv` command for services managed by runit is not in the `PATH`:
+
+    describe runit_service('service', '/opt/chef/embedded/sbin/sv') do
+      it { should be_enabled }
+      it { should be_installed }
+      it { should be_running }
+    end
+
+### Verify that IIS is running
+
+    describe service('W3SVC') do
+      it { should be_installed }
+      it { should be_running }
+    end
+
+<br>
+
+## Matchers
+
+For a full list of available matchers, please visit our [matchers page](https://www.inspec.io/docs/reference/matchers/).
+
+### be_enabled
+
+The `be_enabled` matcher tests if the named service is enabled:
+
+    it { should be_enabled }
+
+### be_installed
+
+The `be_installed` matcher tests if the named service is installed:
+
+    it { should be_installed }
+
+### be_running
+
+The `be_running` matcher tests if the named service is running:
+
+    it { should be_running }

data/docs/resources/shadow.md.erb

@@ -1,144 +1,144 @@
----
-title: About the shadow Resource
-platform: linux
----
-
-# shadow
-
-Use the `shadow` InSpec audit resource to test the contents of `/etc/shadow`, which contains password details that are only readable by the `root` user. The format for `/etc/shadow` includes:
-
-* A username
-* The password for that user (on newer systems passwords should be stored in `/etc/shadow` )
-* The last time a password was changed
-* The minimum number of days a password must exist, before it may be changed
-* The maximum number of days after which a password must be changed
-* The number of days a user is warned about an expiring password
-* The number of days a user must be inactive before the user account is disabled
-* The number of days a user account has been disabled
-
-These entries are defined as a colon-delimited row in the file, one row per user:
-
-    dannos:Gb7crrO5CDF.:10063:0:99999:7:::
-
-<br>
-
-## Syntax
-
-A `shadow` resource block declares one (or more) users and associated user information to be tested:
-
-    describe shadow do
-      its('users') { should_not include 'forbidden_user' }
-    end
-
-or with a single query:
-
-    describe shadow.users('root') do
-      its('count') { should eq 1 }
-    end
-
-or with a filter:
-
-    describe shadow.filter(min_days: '0', max_days: '99999') do
-      its('count') { should eq 1 }
-    end
-
-The following properties are available:
-
-* `users`
-* `passwords`
-* `last_changes`
-* `min_days`
-* `max_days`
-* `warn_days`
-* `inactive_days`
-* `expiry_date`
-* `reserved`
-
-Properties can be used as a single query or can be joined together with the `.filter` method.
-
-<br>
-
-## Examples
-
-The following examples show how to use this InSpec audit resource.
-
-### Test for a forbidden user
-
-    describe shadow do
-      its('users') { should_not include 'forbidden_user' }
-    end
-
-### Test that a user appears one time
-
-    describe shadow.users('bin') do
-      its('passwords') { should cmp 'x' }
-      its('count') { should eq 1 }
-    end
-
-<br>
-
-## Matchers
-
-For a full list of available matchers, please visit our [matchers page](https://www.inspec.io/docs/reference/matchers/).
-
-### count
-
-The `count` matcher tests the number of times the named user appears in `/etc/shadow`:
-
-    its('count') { should eq 1 }
-
-This matcher is best used in conjunction with filters. For example:
-
-    describe shadow.users('dannos') do
-       its('count') { should eq 1 }
-    end
-
-### expiry_dates
-
-The `expiry_dates` matcher tests the number of days a user account has been disabled:
-
-    its('expiry_dates') { should eq '' }
-
-### inactive_days
-
-The `inactive_days` matcher tests the number of days a user must be inactive before the user account is disabled:
-
-    its('inactive_days') { should eq '' }
-
-### last_changes
-
-The `last_changes` matcher tests the last time a password was changed:
-
-    its('last_changes') { should eq '' }
-
-### max_days
-
-The `max_days` matcher tests the maximum number of days after which a password must be changed:
-
-    its('max_days') { should eq 90 }
-
-### min_days
-
-The `min_days` matcher tests the minimum number of days a password must exist, before it may be changed:
-
-    its('min_days') { should eq 0 }
-
-### passwords
-
-The `passwords` matcher returns the encrypted password string from the shadow file. The returned string may not be an encrypted password, but rather a `*` or similar which indicates that direct logins are not allowed.
-
-For example:
-
-    its('passwords') { should cmp '*' }
-
-### users
-
-The `users` matcher tests if the user name exists `/etc/shadow`:
-
-    its('users') { should eq 'root' }
-
-### warn_days
-
-The `warn_days` matcher tests the number of days a user is warned about an expiring password:
-
-    its('warn_days') { should eq 7 }
+---
+title: About the shadow Resource
+platform: linux
+---
+
+# shadow
+
+Use the `shadow` InSpec audit resource to test the contents of `/etc/shadow`, which contains password details that are only readable by the `root` user. The format for `/etc/shadow` includes:
+
+* A username
+* The password for that user (on newer systems passwords should be stored in `/etc/shadow` )
+* The last time a password was changed
+* The minimum number of days a password must exist, before it may be changed
+* The maximum number of days after which a password must be changed
+* The number of days a user is warned about an expiring password
+* The number of days a user must be inactive before the user account is disabled
+* The number of days a user account has been disabled
+
+These entries are defined as a colon-delimited row in the file, one row per user:
+
+    dannos:Gb7crrO5CDF.:10063:0:99999:7:::
+
+<br>
+
+## Syntax
+
+A `shadow` resource block declares one (or more) users and associated user information to be tested:
+
+    describe shadow do
+      its('users') { should_not include 'forbidden_user' }
+    end
+
+or with a single query:
+
+    describe shadow.users('root') do
+      its('count') { should eq 1 }
+    end
+
+or with a filter:
+
+    describe shadow.filter(min_days: '0', max_days: '99999') do
+      its('count') { should eq 1 }
+    end
+
+The following properties are available:
+
+* `users`
+* `passwords`
+* `last_changes`
+* `min_days`
+* `max_days`
+* `warn_days`
+* `inactive_days`
+* `expiry_date`
+* `reserved`
+
+Properties can be used as a single query or can be joined together with the `.filter` method.
+
+<br>
+
+## Examples
+
+The following examples show how to use this InSpec audit resource.
+
+### Test for a forbidden user
+
+    describe shadow do
+      its('users') { should_not include 'forbidden_user' }
+    end
+
+### Test that a user appears one time
+
+    describe shadow.users('bin') do
+      its('passwords') { should cmp 'x' }
+      its('count') { should eq 1 }
+    end
+
+<br>
+
+## Matchers
+
+For a full list of available matchers, please visit our [matchers page](https://www.inspec.io/docs/reference/matchers/).
+
+### count
+
+The `count` matcher tests the number of times the named user appears in `/etc/shadow`:
+
+    its('count') { should eq 1 }
+
+This matcher is best used in conjunction with filters. For example:
+
+    describe shadow.users('dannos') do
+       its('count') { should eq 1 }
+    end
+
+### expiry_dates
+
+The `expiry_dates` matcher tests the number of days a user account has been disabled:
+
+    its('expiry_dates') { should eq '' }
+
+### inactive_days
+
+The `inactive_days` matcher tests the number of days a user must be inactive before the user account is disabled:
+
+    its('inactive_days') { should eq '' }
+
+### last_changes
+
+The `last_changes` matcher tests the last time a password was changed:
+
+    its('last_changes') { should eq '' }
+
+### max_days
+
+The `max_days` matcher tests the maximum number of days after which a password must be changed:
+
+    its('max_days') { should eq 90 }
+
+### min_days
+
+The `min_days` matcher tests the minimum number of days a password must exist, before it may be changed:
+
+    its('min_days') { should eq 0 }
+
+### passwords
+
+The `passwords` matcher returns the encrypted password string from the shadow file. The returned string may not be an encrypted password, but rather a `*` or similar which indicates that direct logins are not allowed.
+
+For example:
+
+    its('passwords') { should cmp '*' }
+
+### users
+
+The `users` matcher tests if the user name exists `/etc/shadow`:
+
+    its('users') { should eq 'root' }
+
+### warn_days
+
+The `warn_days` matcher tests the number of days a user is warned about an expiring password:
+
+    its('warn_days') { should eq 7 }