inspec 2.1.80 → 2.1.81

data/docs/resources/apache_conf.md.erb

@@ -1,68 +1,68 @@
----
-title: About the apache_conf Resource
-platform: linux
----
-
-# apache_conf
-
-Use the `apache_conf` InSpec audit resource to test the configuration settings for Apache. This file is typically located under `/etc/apache2` on the Debian and Ubuntu platforms and under `/etc/httpd` on the Fedora, CentOS, RedHat Enterprise Linux, and ArchLinux platforms. The configuration settings may vary significantly from platform to platform.
-
-<br>
-
-## Syntax
-
-An `apache_conf` InSpec audit resource block declares configuration settings that should be tested:
-
-    describe apache_conf('path') do
-      its('setting_name') { should eq 'value' }
-    end
-
-where
-
-* `'setting_name'` is a configuration setting defined in the Apache configuration file
-* `('path')` is the non-default path to the Apache configuration file
-* `{ should eq 'value' }` is the value that is expected
-
-<br>
-
-## Examples
-
-The following examples show how to use this InSpec audit resource.
-
-### Test for blocking .htaccess files on CentOS
-
-    describe apache_conf do
-      its('AllowOverride') { should cmp 'None' }
-    end
-
-### Test ports for SSL
-
-    describe apache_conf do
-      its('Listen') { should cmp '443' }
-    end
-
-### Test multiple ports are listening
-
-    describe apache_conf do
-      its('Listen') { should =~ [ '80', '443' ] }
-    end
-
-<br>
-
-## Matchers
-
-For a full list of available matchers, please visit our [matchers page](https://www.inspec.io/docs/reference/matchers/).
-This InSpec audit resource matches any service that is listed in the Apache configuration file:
-
-    its('PidFile') { should_not eq '/var/run/httpd.pid' }
-
-or:
-
-    its('Timeout') { should cmp '300' }
-
-For example:
-
-    describe apache_conf do
-      its('MaxClients') { should cmp '100' }
-      its('Listen') { should cmp '443' }
-    end
+---
+title: About the apache_conf Resource
+platform: linux
+---
+
+# apache_conf
+
+Use the `apache_conf` InSpec audit resource to test the configuration settings for Apache. This file is typically located under `/etc/apache2` on the Debian and Ubuntu platforms and under `/etc/httpd` on the Fedora, CentOS, RedHat Enterprise Linux, and ArchLinux platforms. The configuration settings may vary significantly from platform to platform.
+
+<br>
+
+## Syntax
+
+An `apache_conf` InSpec audit resource block declares configuration settings that should be tested:
+
+    describe apache_conf('path') do
+      its('setting_name') { should eq 'value' }
+    end
+
+where
+
+* `'setting_name'` is a configuration setting defined in the Apache configuration file
+* `('path')` is the non-default path to the Apache configuration file
+* `{ should eq 'value' }` is the value that is expected
+
+<br>
+
+## Examples
+
+The following examples show how to use this InSpec audit resource.
+
+### Test for blocking .htaccess files on CentOS
+
+    describe apache_conf do
+      its('AllowOverride') { should cmp 'None' }
+    end
+
+### Test ports for SSL
+
+    describe apache_conf do
+      its('Listen') { should cmp '443' }
+    end
+
+### Test multiple ports are listening
+
+    describe apache_conf do
+      its('Listen') { should =~ [ '80', '443' ] }
+    end
+
+<br>
+
+## Matchers
+
+For a full list of available matchers, please visit our [matchers page](https://www.inspec.io/docs/reference/matchers/).
+This InSpec audit resource matches any service that is listed in the Apache configuration file:
+
+    its('PidFile') { should_not eq '/var/run/httpd.pid' }
+
+or:
+
+    its('Timeout') { should cmp '300' }
+
+For example:
+
+    describe apache_conf do
+      its('MaxClients') { should cmp '100' }
+      its('Listen') { should cmp '443' }
+    end

data/docs/resources/apt.md.erb

@@ -1,71 +1,71 @@
----
-title: About the apt Resource
-platform: linux
----
-
-# apt
-
-Use the `apt` InSpec audit resource to verify Apt repositories on the Debian and Ubuntu platforms, and also PPA repositories on the Ubuntu platform.
-
-<br>
-
-## Syntax
-
-An `apt` resource block tests the contents of Apt and PPA repositories:
-
-    describe apt('path') do
-      it { should exist }
-      it { should be_enabled }
-    end
-
-where
-
-* `apt('path')` must specify an Apt or PPA repository
-* `('path')` may be an `http://` address, a `ppa:` address, or a short `repo-name/ppa` address
-* `exist` and `be_enabled` are a valid matchers for this resource
-
-<br>
-
-## Examples
-
-The following examples show how to use this InSpec audit resource.
-
-### Test if apt repository exists and is enabled
-
-    describe apt('http://ppa.launchpad.net/juju/stable/ubuntu') do
-      it { should exist }
-      it { should be_enabled }
-    end
-
-### Verify that a PPA repository exists and is enabled
-
-    describe apt('ppa:nginx/stable') do
-      it { should exist }
-      it { should be_enabled }
-    end
-
-### Verify that a repository is not present
-
-    describe apt('ubuntu-wine/ppa') do
-      it { should_not exist }
-      it { should_not be_enabled }
-    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 a package exists in the repository:
-
-    it { should be_enabled }
-
-### exist
-
-The `exist` matcher tests if a package exists on the system:
-
-    it { should exist }
+---
+title: About the apt Resource
+platform: linux
+---
+
+# apt
+
+Use the `apt` InSpec audit resource to verify Apt repositories on the Debian and Ubuntu platforms, and also PPA repositories on the Ubuntu platform.
+
+<br>
+
+## Syntax
+
+An `apt` resource block tests the contents of Apt and PPA repositories:
+
+    describe apt('path') do
+      it { should exist }
+      it { should be_enabled }
+    end
+
+where
+
+* `apt('path')` must specify an Apt or PPA repository
+* `('path')` may be an `http://` address, a `ppa:` address, or a short `repo-name/ppa` address
+* `exist` and `be_enabled` are a valid matchers for this resource
+
+<br>
+
+## Examples
+
+The following examples show how to use this InSpec audit resource.
+
+### Test if apt repository exists and is enabled
+
+    describe apt('http://ppa.launchpad.net/juju/stable/ubuntu') do
+      it { should exist }
+      it { should be_enabled }
+    end
+
+### Verify that a PPA repository exists and is enabled
+
+    describe apt('ppa:nginx/stable') do
+      it { should exist }
+      it { should be_enabled }
+    end
+
+### Verify that a repository is not present
+
+    describe apt('ubuntu-wine/ppa') do
+      it { should_not exist }
+      it { should_not be_enabled }
+    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 a package exists in the repository:
+
+    it { should be_enabled }
+
+### exist
+
+The `exist` matcher tests if a package exists on the system:
+
+    it { should exist }

data/docs/resources/audit_policy.md.erb

@@ -1,47 +1,47 @@
----
-title: About the audit_policy Resource
-platform: linux
----
-
-# audit_policy
-
-Use the `audit_policy` InSpec audit resource to test auditing policies on the Windows platform. An auditing policy is a category of security-related events to be audited. Auditing is disabled by default and may be enabled for categories like account management, logon events, policy changes, process tracking, privilege use, system events, or object access. For each enabled auditing category property, the auditing level may be set to `No Auditing`, `Not Specified`, `Success`, `Success and Failure`, or `Failure`.
-
-<br>
-
-## Syntax
-
-An `audit_policy` resource block declares a parameter that belongs to an audit policy category or subcategory:
-
-    describe audit_policy do
-      its('parameter') { should eq 'value' }
-    end
-
-where
-
-* `'parameter'` must specify a parameter
-* `'value'` must be one of `No Auditing`, `Not Specified`, `Success`, `Success and Failure`, or `Failure`
-
-<br>
-
-## Examples
-
-The following examples show how to use this InSpec audit resource.
-
-### Test that a parameter is not set to "No Auditing"
-
-    describe audit_policy do
-      its('Other Account Logon Events') { should_not eq 'No Auditing' }
-    end
-
-### Test that a parameter is set to "Success"
-
-    describe audit_policy do
-      its('User Account Management') { should eq 'Success' }
-    end
-
-<br>
-
-## Matchers
-
-For a full list of available matchers, please visit our [matchers page](https://www.inspec.io/docs/reference/matchers/).
+---
+title: About the audit_policy Resource
+platform: linux
+---
+
+# audit_policy
+
+Use the `audit_policy` InSpec audit resource to test auditing policies on the Windows platform. An auditing policy is a category of security-related events to be audited. Auditing is disabled by default and may be enabled for categories like account management, logon events, policy changes, process tracking, privilege use, system events, or object access. For each enabled auditing category property, the auditing level may be set to `No Auditing`, `Not Specified`, `Success`, `Success and Failure`, or `Failure`.
+
+<br>
+
+## Syntax
+
+An `audit_policy` resource block declares a parameter that belongs to an audit policy category or subcategory:
+
+    describe audit_policy do
+      its('parameter') { should eq 'value' }
+    end
+
+where
+
+* `'parameter'` must specify a parameter
+* `'value'` must be one of `No Auditing`, `Not Specified`, `Success`, `Success and Failure`, or `Failure`
+
+<br>
+
+## Examples
+
+The following examples show how to use this InSpec audit resource.
+
+### Test that a parameter is not set to "No Auditing"
+
+    describe audit_policy do
+      its('Other Account Logon Events') { should_not eq 'No Auditing' }
+    end
+
+### Test that a parameter is set to "Success"
+
+    describe audit_policy do
+      its('User Account Management') { should eq 'Success' }
+    end
+
+<br>
+
+## Matchers
+
+For a full list of available matchers, please visit our [matchers page](https://www.inspec.io/docs/reference/matchers/).

data/docs/resources/auditd.md.erb

@@ -1,79 +1,79 @@
----
-title: About the auditd Resource
-platform: linux
----
-
-# auditd
-
-Use the `auditd` InSpec audit resource to test the rules for logging that exist on the system. The audit.rules file is typically located under /etc/audit/ and contains the list of rules that define what is captured in log files. These rules are output using the auditctl -l command. This resource supports versions of `audit` >= 2.3.
-
-<br>
-
-## Syntax
-
-An `auditd` resource block declares one (or more) rules to be tested, and then what that rule should do:
-
-    describe auditd do
-      its('lines') { should include %r(-w /etc/ssh/sshd_config) }
-    end
-
-or test that multiple individual rules are defined:
-
-    describe auditd do
-      its('lines') { should include %r(-a always,exit -F arch=.* -S init_module,delete_module -F key=modules) }
-      its('lines') { should include %r(-a always,exit -F arch=.* -S chmod,fchmod,fchmodat -F auid>=1000 -F auid!=-1 -F key=.+) }
-    end
-
-where each test must declare one (or more) rules to be tested.
-
-<br>
-
-## Examples
-
-The following examples show how to use this InSpec audit resource.
-
-### Test if a rule contains a matching element that is identified by a regular expression
-
-For `audit` >= 2.3:
-
-    describe auditd do
-      its('lines') { should include %r(-a always,exit -F arch=.* -S chown.* -F auid>=1000 -F auid!=-1 -F key=perm_mod) }
-    end
-
-### Query the audit daemon status
-
-    describe auditd.status('backlog') do
-      it { should cmp 0 }
-    end
-
-### Query properties of rules targeting specific syscalls or files - uniq is used to handle multiple rules for the same syscall with redundant field values
-
-    describe auditd.syscall('open') do
-      its('action.uniq') { should eq ['always'] }
-      its('list.uniq') { should eq ['exit'] }
-    end
-
-    describe auditd.file('/etc/sudoers') do
-      its('permissions') { should include ['x'] }
-    end
-
-The where accessor can be used to filter on fields. For example:
-
-    describe auditd.syscall('chown').where { arch == "b32" } do
-      its('action') { should eq ['always'] }
-      its('list') { should eq ['exit'] }
-      its('exit') { should include ['-EACCES'] }
-      its('exit') { should include ['-EPERM'] }
-    end
-
-The key filter may be useful in evaluating rules with particular key values:
-
-    describe auditd.where { key == "privileged" } do
-      its('permissions') { should include ['x'] }
-    end
-
-<br>
-
-## Matchers
-
-For a full list of available matchers, please visit our [matchers page](https://www.inspec.io/docs/reference/matchers/).
+---
+title: About the auditd Resource
+platform: linux
+---
+
+# auditd
+
+Use the `auditd` InSpec audit resource to test the rules for logging that exist on the system. The audit.rules file is typically located under /etc/audit/ and contains the list of rules that define what is captured in log files. These rules are output using the auditctl -l command. This resource supports versions of `audit` >= 2.3.
+
+<br>
+
+## Syntax
+
+An `auditd` resource block declares one (or more) rules to be tested, and then what that rule should do:
+
+    describe auditd do
+      its('lines') { should include %r(-w /etc/ssh/sshd_config) }
+    end
+
+or test that multiple individual rules are defined:
+
+    describe auditd do
+      its('lines') { should include %r(-a always,exit -F arch=.* -S init_module,delete_module -F key=modules) }
+      its('lines') { should include %r(-a always,exit -F arch=.* -S chmod,fchmod,fchmodat -F auid>=1000 -F auid!=-1 -F key=.+) }
+    end
+
+where each test must declare one (or more) rules to be tested.
+
+<br>
+
+## Examples
+
+The following examples show how to use this InSpec audit resource.
+
+### Test if a rule contains a matching element that is identified by a regular expression
+
+For `audit` >= 2.3:
+
+    describe auditd do
+      its('lines') { should include %r(-a always,exit -F arch=.* -S chown.* -F auid>=1000 -F auid!=-1 -F key=perm_mod) }
+    end
+
+### Query the audit daemon status
+
+    describe auditd.status('backlog') do
+      it { should cmp 0 }
+    end
+
+### Query properties of rules targeting specific syscalls or files - uniq is used to handle multiple rules for the same syscall with redundant field values
+
+    describe auditd.syscall('open') do
+      its('action.uniq') { should eq ['always'] }
+      its('list.uniq') { should eq ['exit'] }
+    end
+
+    describe auditd.file('/etc/sudoers') do
+      its('permissions') { should include ['x'] }
+    end
+
+The where accessor can be used to filter on fields. For example:
+
+    describe auditd.syscall('chown').where { arch == "b32" } do
+      its('action') { should eq ['always'] }
+      its('list') { should eq ['exit'] }
+      its('exit') { should include ['-EACCES'] }
+      its('exit') { should include ['-EPERM'] }
+    end
+
+The key filter may be useful in evaluating rules with particular key values:
+
+    describe auditd.where { key == "privileged" } do
+      its('permissions') { should include ['x'] }
+    end
+
+<br>
+
+## Matchers
+
+For a full list of available matchers, please visit our [matchers page](https://www.inspec.io/docs/reference/matchers/).