inspec-core 2.3.10 → 2.3.23

data/docs/resources/audit_policy.md.erb

@@ -1,57 +0,0 @@
----
-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>
-
-## Availability
-
-### Installation
-
-This resource is distributed along with InSpec itself. You can use it automatically.
-
-### Version
-
-This resource first became available in v1.0.0 of InSpec.
-
-## 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,89 +0,0 @@
----
-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>
-
-## Availability
-
-### Installation
-
-This resource is distributed along with InSpec itself. You can use it automatically.
-
-### Version
-
-This resource first became available in v1.38.8 of InSpec.
-
-## 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/).

data/docs/resources/auditd_conf.md.erb

@@ -1,78 +0,0 @@
----
-title: About the auditd_conf Resource
-platform: linux
----
-
-# auditd_conf
-
-Use the `auditd_conf` InSpec audit resource to test the configuration settings for the audit daemon. This file is typically located under `/etc/audit/auditd.conf'` on Unix and Linux platforms.
-
-<br>
-
-## Availability
-
-### Installation
-
-This resource is distributed along with InSpec itself. You can use it automatically.
-
-### Version
-
-This resource first became available in v1.0.0 of InSpec.
-
-## Syntax
-
-A `auditd_conf` resource block declares configuration settings that should be tested:
-
-    describe auditd_conf('path') do
-      its('keyword') { should cmp 'value' }
-    end
-
-where
-
-* `'keyword'` is a configuration setting defined in the `auditd.conf` configuration file
-* `('path')` is the non-default path to the `auditd.conf` configuration file
-* `{ should cmp 'value' }` is the value that is expected
-
-<br>
-
-## Properties
-
-This matcher will match any property listed in the `auditd.conf` configuration file. Property names and expected values are case-insensitive:
-
-* `admin_space_left`, `admin_space_left_action`, `action_mail_acct`, `disk_error_action`, `disk_full_action`, `flush`, `freq`, `log_file`, `log_format`, `max_log_file`, `max_log_file_action`, `num_logs`, `space_left`, `space_left_action`
-
-## Property Examples
-
-The following examples show how to use this InSpec audit resource.
-
-### Test the auditd.conf file
-
-    describe auditd_conf do
-      its('log_file') { should cmp '/full/path/to/file' }
-      its('log_format') { should cmp 'raw' }
-      its('flush') { should cmp 'none' }
-      its('freq') { should cmp 1 }
-      its('num_logs') { should cmp 0 }
-      its('max_log_file') { should cmp 6 }
-      its('max_log_file_action') { should cmp 'email' }
-      its('space_left') { should cmp 2 }
-      its('action_mail_acct') { should cmp 'root' }
-      its('space_left_action') { should cmp 'email' }
-      its('admin_space_left') { should cmp 1 }
-      its('admin_space_left_action') { should cmp 'halt' }
-      its('disk_full_action') { should cmp 'halt' }
-      its('disk_error_action') { should cmp 'halt' }
-    end
-
-<br>
-
-## Matchers
-
-For a full list of available matchers, please visit our [matchers page](https://www.inspec.io/docs/reference/matchers/).
-
-### `cmp`
-
-The `cmp` matcher compares values across types.
-
-    its('freq') { should cmp 1 }
-

data/docs/resources/bash.md.erb

@@ -1,85 +0,0 @@
----
-title: About the bash Resource
-platform: linux
----
-
-# bash
-
-Use the `bash` InSpec audit resource to test an arbitrary command that is run on the system using a Bash script.
-
-<br>
-
-## Availability
-
-### Installation
-
-This resource is distributed along with InSpec itself. You can use it automatically.
-
-### Version
-
-This resource first became available in v1.0.0 of InSpec.
-
-## Syntax
-
-A `command` resource block declares a command to be run, one (or more) expected outputs, and the location to which that output is sent:
-
-    describe bash('command') do
-      it { should exist }
-      its('property') { should eq 'expected value' }
-    end
-
-where
-
-* `'command'` must specify a command to be run
-* `'property'` is one of `exit_status`, `stderr`, or `stdout`
-* `'expected value'` tests the output of the command run on the system versus the expected output stated in the test
-
-For example:
-
-    describe bash('ls -al /') do
-      its('stdout') { should match /bin/ }
-      its('stderr') { should eq '' }
-      its('exit_status') { should eq 0 }
-    end
-
-<br>
-
-## Properties
-
-* `exit_status`, `stderr`, `stdout`
-
-<br>
-
-## Property Examples
-
-### exit_status
-
-The `exit_status` property tests the exit status for the command:
-
-    its('exit_status') { should eq 0 }
-
-### stderr
-
-The `stderr` property tests results of the command as returned in standard error (stderr):
-
-    its('stderr') { should eq '' }
-
-### stdout
-
-The `stdout` property tests results of the command as returned in standard output (stdout).
-
-    its('stdout') { should match /bin/ }
-
-<br>
-
-## Matchers
-
-For a full list of available matchers, please visit our [matchers page](https://www.inspec.io/docs/reference/matchers/).
-
-### exist
-
-If an absolute path is provided, the `exist` matcher tests if the command exists on the filesystem at the specified location. Otherwise, the `exist` matcher tests if the command is found in the PATH.
-
-    it { should exist }
-
-

data/docs/resources/bond.md.erb

@@ -1,100 +0,0 @@
----
-title: About the bond Resource
-platform: linux
----
-
-# bond
-
-Use the `bond` InSpec audit resource to test a logical, bonded network interface (i.e. "two or more network interfaces aggregated into a single, logical network interface"). On Linux platforms, any value in the `/proc/net/bonding` directory may be tested.
-
-<br>
-
-## Availability
-
-### Installation
-
-This resource is distributed along with InSpec itself. You can use it automatically.
-
-### Version
-
-This resource first became available in v1.0.0 of InSpec.
-
-## Syntax
-
-A `bond` resource block declares a bonded network interface, and then specifies the properties of that bonded network interface to be tested:
-
-    describe bond('name') do
-      it { should exist }
-    end
-
-where
-
-* `'name'` is the name of the bonded network interface
-* `{ should exist }` is a valid matcher for this resource
-
-<br>
-
-## Property Examples
-
-The following examples show how to use this InSpec audit resource.
-
-### content
-
-The `content` matcher tests if contents in the file that defines the bonded network interface match the value specified in the test. The values of the `content` matcher are arbitrary.
-
-    its('content') { should match('value') }
-
-### interfaces
-
-The `interfaces` matcher tests if the named secondary interfaces are available.
-
-    its('interfaces') { should eq ['eth0', 'eth1', ...] }
-
-### mode
-
-The `mode` matcher tests the Bonding Mode.
-
-    its('mode') { should eq 'IEEE 802.3ad Dynamic link aggregation' }
-
-### params
-
-The `params` matcher tests arbitrary parameters for the bonded network interface.
-
-    its('params') { should eq 'value' }
-
-### Test if eth0 is a secondary interface for bond0
-
-    describe bond('bond0') do
-      it { should exist }
-      it { should have_interface 'eth0' }
-    end
-
-### Test parameters for bond0
-
-    describe bond('bond0') do
-      its('mode') { should eq 'IEEE 802.3ad Dynamic link aggregation' }
-      its('Transmit Hash Policy') { should eq 'layer3+4 (1)' }
-      its('MII Status') { should eq 'up' }
-      its('MII Polling Interval (ms)') { should eq '100' }
-      its('Up Delay (ms)') { should eq '0' }
-      its('Down Delay (ms)') { should eq '0' }
-    end
-
-<br>
-
-## Matchers
-
-For a full list of available matchers, please visit our [matchers page](https://www.inspec.io/docs/reference/matchers/).
-
-### exist
-
-The `exist` matcher tests if the bonded network interface is available:
-
-    it { should exist }
-
-### have_interface
-
-The `have_interface` matcher tests if the bonded network interface has one (or more) secondary interfaces:
-
-    it { should have_interface }
-

data/docs/resources/bridge.md.erb

@@ -1,67 +0,0 @@
----
-title: About the bridge Resource
-platform: linux
----
-
-# bridge
-
-Use the `bridge` InSpec audit resource to test basic network bridge properties, such as name, if an interface is defined, and the associations for any defined interface.
-
-<br>
-
-## Availability
-
-### Installation
-
-This resource is distributed along with InSpec itself. You can use it automatically.
-
-### Version
-
-This resource first became available in v1.0.0 of InSpec.
-
-## Syntax
-
-A `bridge` resource block declares the bridge to be tested and what interface it should be associated with:
-
-    describe bridge('br0') do
-      it { should exist }
-      it { should have_interface 'eth0' }
-    end
-
-<br>
-
-## Properties
-
-* On Linux platforms, any value in the `/sys/class/net/{interface}/bridge` directory may be tested
-* On the Windows platform, the `Get-NetAdapter` cmdlet is associated with the `Get-NetAdapterBinding` cmdlet and returns the `ComponentID ms_bridge` value as a JSON object
-
-<br>
-
-## Property Examples
-
-### interfaces
-
-The `interfaces` property tests if the named interface is present:
-
-    its('interfaces') { should eq 'foo' }
-    its('interfaces') { should eq 'bar' }
-    its('interfaces') { should include('foo') }
-
-<br>
-
-## Matchers
-
-For a full list of available matchers, please visit our [matchers page](https://www.inspec.io/docs/reference/matchers/).
-
-### exist
-
-The `exist` matcher tests if the network bridge is available:
-
-    it { should exist }
-
-### have_interface
-
-The `have_interface` matcher tests if the named interface is defined for the network bridge:
-
-    it { should have_interface 'eth0' }
-