inspec-core 2.3.10 → 2.3.23

data/docs/resources/x509_certificate.md.erb

@@ -1,161 +0,0 @@
----
-title: The x509_certificate Resource
-platform: os
----
-
-# x509_certificate
-
-Use the `x509_certificate` InSpec audit resource to test the fields and validity of an x.509 certificate.
-
-X.509 certificates use public/private key pairs to sign and encrypt documents
-or communications over a network. They may also be used for authentication.
-
-Examples include SSL certificates, S/MIME certificates and VPN authentication
-certificates.
-
-<br>
-
-## Availability
-
-### Installation
-
-This resource is distributed along with InSpec itself. You can use it automatically.
-
-### Version
-
-This resource first became available in v1.18.0 of InSpec.
-
-## Syntax
-
-An `x509_certificate` resource block declares a certificate `key file` to be tested.
-
-    describe x509_certificate('mycertificate.pem') do
-      its('validity_in_days') { should be > 30 }
-    end
-
-<br>
-
-## Properties
-
-### subject.XX
-
-`subject` property makes it easier to access individual subject elements.
-
-    describe x509_certificate('/etc/pki/www.mywebsite.com.pem') do
-      its('subject.CN') { should eq "www.mywebsite.com" }
-    end
-
-### subject_dn (String)
-
-The `subject_dn` string returns the distinguished name of the subject field. It contains several fields separated by forward slashes. The field identifiers are the same ones used by OpenSSL to generate CSR's and certs. Use `subject.XX` instead to access the parsed version.
-
-e.g. `/C=US/L=Seattle/O=Chef Software Inc/OU=Chefs/CN=Richard Nixon`
-
-    describe x509_certificate('/etc/pki/www.mywebsite.com.pem') do
-      its('subject_dn') { should match "CN=www.mywebsite.com" }
-    end
-
-### issuer.XX
-
-`issuer` makes it easier to access individual issuer elements.
-
-    describe x509_certificate('/etc/pki/www.mywebsite.com.pem') do
-      its('issuer.CN') { should eq "Acme Trust CA" }
-    end
-
-### issuer_dn (String)
-
-The `issuer_dn` is the distinguished name from a CA (certificate authority) during the
-certificate signing process. It describes which authority is guaranteeing the
-identity of our certificate.
-
-e.g. `/C=US/L=Seattle/CN=Acme Trust CA/emailAddress=support@acmetrust.org`
-
-    describe x509_certificate('/etc/pki/www.mywebsite.com.pem') do
-      its('issuer_cn') { should match "CN=Acme Trust CA" }
-    end
-
-### public_key (String)
-
-The `public_key` property returns a base64 encoded public key in PEM format.
-
-    describe x509_certificate('/etc/pki/www.mywebsite.com.pem') do
-      its('public_key') { should match "-----BEGIN PUBLIC KEY-----\nblah blah blah..." }
-    end
-
-### key_length (Integer)
-
-The `key_length` property calculates the number of bits in the public key.
-More bits increase security, but at the cost of speed and in extreme cases, compatibility.
-
-    describe x509_certificate('/etc/pki/www.mywebsite.com.pem') do
-      its('key_length') { should be 2048 }
-    end
-
-### signature_algorithm (String)
-
-The `signature_algorithm` property describes which hash function was used by the CA to
-sign the certificate.
-
-    describe x509_certificate('/etc/pki/www.mywebsite.com.pem') do
-      its('signature_algorithm') { should be 'sha256WithRSAEncryption' }
-    end
-
-
-### validity\_in\_days (Float)
-
-The `validity_in_days` property can be used to check that certificates are not in
-danger of expiring soon.
-
-    describe x509_certificate('/etc/pki/www.mywebsite.com.pem') do
-      its('validity_in_days') { should be > 30 }
-    end
-
-### not\_before and not\_after (Time)
-
-The `not_before` and `not_after` properties expose the start and end dates of certificate
-validity. They are exposed as ruby Time class so that date arithmetic can be easily performed.
-
-    describe x509_certificate('/etc/pki/www.mywebsite.com.pem') do
-      its('not_before') { should be <= Time.utc.now }
-      its('not_after')  { should be >= Time.utc.now }
-    end
-
-### serial (Integer)
-
-The `serial` property exposes the serial number of the certificate. The serial number is set by the CA during the signing process and should be unique within that CA.
-
-    describe x509_certificate('/etc/pki/www.mywebsite.com.pem') do
-      its('serial') { should eq 9623283588743302433 }
-    end
-
-### version (Integer)
-
-The `version` property exposes the certificate version.
-
-    describe x509_certificate('/etc/pki/www.mywebsite.com.pem') do
-      its('version') { should eq 2 }
-    end
-
-### extensions (Hash)
-
-The `extensions` hash property is mainly used to determine what the certificate can be used for.
-
-    describe x509_certificate('/etc/pki/www.mywebsite.com.pem') do
-      # Check what extension categories we have
-      its('extensions') { should include 'keyUsage' }
-      its('extensions') { should include 'extendedKeyUsage' }
-      its('extensions') { should include 'subjectAltName' }
-
-      # Check examples of basic 'keyUsage'
-      its('extensions.keyUsage') { should include 'Digital Signature' }
-      its('extensions.keyUsage') { should include 'Non Repudiation' }
-      its('extensions.keyUsage') { should include 'Data Encipherment' }
-
-      # Check examples of newer 'extendedKeyUsage'
-      its('extensions.extendedKeyUsage') { should include 'TLS Web Server Authentication' }
-      its('extensions.extendedKeyUsage') { should include 'Code Signing' }
-
-      # Check examples of 'subjectAltName'
-      its('extensions.subjectAltName') { should include 'email:support@chef.io' }
-    end

data/docs/resources/xinetd_conf.md.erb

@@ -1,166 +0,0 @@
----
-title: About the xinetd_conf Resource
-platform: linux
----
-
-# xinetd_conf
-
-Use the `xinetd_conf` InSpec audit resource to test services under `/etc/xinet.d` on Linux and Unix platforms. xinetd---the extended Internet service daemon---listens on all ports, and then loads the appropriate program based on a request. The `xinetd.conf` file is typically located at `/etc/xinetd.conf` and contains a list of Internet services associated to the ports on which that service will listen. Only enabled services may handle a request; only services that are required by the system should be enabled.
-
-<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 `xinetd_conf` resource block declares settings found in a `xinetd.conf` file for the named service:
-
-    describe xinetd_conf.services('service_name') do
-      it { should be_enabled } # or be_disabled
-      its('setting') { should eq 'value' }
-    end
-
-where
-
-* `'service_name'` is a service located under `/etc/xinet.d`
-* `('setting')` is a setting in the `xinetd.conf` file
-* `should eq 'value'` is the value that is expected
-
-<br>
-
-## Examples
-
-The following examples show how to use this InSpec audit resource.
-
-### Test a socket_type
-
-The network socket type: `dgram` (a datagram-based service), `raw` (a service that requires direct access to an IP address), `stream` (a stream-based service), or `seqpacket` (a service that requires a sequenced packet).
-
-    describe xinetd_conf.services('service_name') do
-       its('socket_types') { should include 'dgram' }
-    end
-
-### Test a service type
-
-The type of service: `INTERNAL` (a service provided by xinetd), `RPC` (an RPC-based service), `TCPMUX` (a service that is started on a well-known TCPMUX port), or `UNLISTED` (a service that is not listed in a standard system file location).
-
-    describe xinetd_conf.services('service_name') do
-       its('type') { should include 'RPC' }
-    end
-
-### Test the telnet service
-
-For example, a `telnet` file under `/etc/xinet.d` contains the following settings:
-
-    service telnet
-    {
-      disable         = yes
-      flags           = REUSE
-      socket_type     = stream
-      wait            = no
-      user            = root
-      server          = /usr/sbin/in.telnetd
-      log_on_failure  += USERID
-    }
-
-Some examples of tests that can be run against that file include:
-
-    describe xinetd_conf.services('telnet') do
-      it { should be_disabled }
-    end
-
-and
-
-    describe xinetd_conf.services('telnet') do
-      its('socket_type') { should include 'stream' }
-    end
-
-and
-
-    describe xinetd_conf.services('telnet') do
-      its('wait') { should eq 'no' }
-    end
-
-All three settings can be tested in the same block as well:
-
-    describe xinetd_conf.services('telnet') do
-      it { should be_disabled }
-      its('socket_type') { should include 'stream' }
-      its('wait') { should eq 'no' }
-    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 service listed under `/etc/xinet.d` is enabled:
-
-    it { should be_enabled }
-
-### ids
-
-The `ids` matcher tests if the named service is located under `/etc/xinet.d`:
-
-    its('ids') { should include 'service_name' }
-
-For example:
-
-    its('ids') { should include 'chargen-stream chargen-dgram'}
-
-### services
-
-The `services` matcher tests if the named service is listed under `/etc/xinet.d`:
-
-    its('services') { should include 'service_name' }
-
-### socket_types
-
-The `socket_types` matcher tests if a service listed under `/etc/xinet.d` is configured to use the named socket type:
-
-    its('socket_types') { should eq 'socket' }
-
-where `socket` is one of `dgram`, `raw`, or `stream`. For a UDP-based service:
-
-    its('socket_types') { should eq 'dgram' }
-
-For a raw socket (such as a service using a non-standard protocol or a service that requires direct access to IP):
-
-    its('socket_types') { should eq 'raw' }
-
-For a TCP-based service:
-
-    its('socket_types') { should eq 'stream' }
-
-### types
-
-The `types` matcher tests the service type:
-
-    its('type') { should eq 'TYPE' }
-
-where `'TYPE'` is `INTERNAL` (for a service provided by xinetd), `RPC` (for a service based on remote procedure call), or `UNLISTED` (for services not under `/etc/services` or `/etc/rpc`).
-
-### wait
-
-The `wait` matcher tests how a service handles incoming connections.
-
-For UDP (`dgram`) socket types the `wait` matcher should test for `yes`:
-
-    its('socket_types') { should eq 'dgram' }
-    its('wait') { should eq 'yes' }
-
-For TCP (`stream`) socket types the `wait` matcher should test for `no`:
-
-    its('socket_types') { should eq 'stream' }
-    its('wait') { should eq 'no' }

data/docs/resources/xml.md.erb

@@ -1,95 +0,0 @@
----
-title: About the xml Resource
-platform: os
----
-
-# xml
-
-Use the `xml` InSpec audit resource to test data in an XML file.
-
-<br>
-
-## Availability
-
-### Installation
-
-This resource is distributed along with InSpec itself. You can use it automatically.
-
-### Version
-
-This resource first became available in v1.37.6 of InSpec.
-
-## Syntax
-
-An `xml` resource block declares the data to be tested. Assume the following XML file:
-
-    <root>
-      <name>hello</name>
-      <meta>
-        <creator>John Doe</creator>
-      </meta>
-      <array>
-        <element>one</element>
-        <element>two</element>
-      </array>
-      <array>
-        <element value="one"></element>
-        <element value="two"></element>
-      </array>
-    </root>
-
-This file can be queried for elements using:
-
-    describe xml('/path/to/name.xml') do
-      its('root/name') { should eq ['hello'] }
-      its('root/meta/creator') { should eq ['John Doe'] }
-      its('root/array[2]/element') { should eq ['two'] }
-    end
-
-This file can be queried for attributes using:
-
-    describe xml('/path/to/name.xml') do
-      its('root/array[2]/element/@value') { should eq ['one', 'two'] }
-      its('root/array[2]/element/attribute::value') { should eq ['one', 'two'] }
-      its('root/array[2]/element[2]/attribute::value') { should eq ['two'] }
-    end
-
-where
-
-* `root/name` and `root/array[2]/element/@value` is an XPath expression
-* `should eq ['foo']` tests a value of `root/name` as read from an XML file versus the value declared in the test
-
-In the above example, you see the use of `@` and `attribute::` which are both methods of fetching attributes.
-
-In the event the path contains an element which contains periods, the alternate syntax can be used:
-
-    its(['root/name.with.a.period']) { should cmp 'so_many_dots' }
-
-<br>
-
-## Examples
-
-The following examples show how to use this InSpec audit resource.
-
-### Test an AppPool's presence in an applicationHost.config file or the default site under applicationHost.sites
-
-    describe xml('applicationHost.config') do
-      # using the alternate syntax as described above because of the . in the key name
-      its(['configuration/system.applicationHost/applicationPools/add@name']) { should contain('my_pool') }
-    end
-
-    describe xml('applicationHost.sites') do
-      its('site[@name="Default Web Site"]/application/virtualDirectory/@path') { should eq ['/'] }
-    end
-
-<br>
-
-## Matchers
-
-For a full list of available matchers, please visit our [matchers page](https://www.inspec.io/docs/reference/matchers/).
-
-### name
-
-The `name` matcher tests the value of `name` as read from a JSON file versus the value declared in the test:
-
-    its('name') { should eq 'foo' }

data/docs/resources/yaml.md.erb

@@ -1,79 +0,0 @@
----
-title: About the yaml Resource
-platform: os
----
-
-# yaml
-
-Use the `yaml` InSpec audit resource to test configuration data in a Yaml file.
-
-<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 `yaml` resource block declares the configuration data to be tested. Assume the following Yaml file:
-
-    name: foo
-    array:
-      - zero
-      - one
-
-This file can be queried using:
-
-    describe yaml('filename.yml') do
-      its('name') { should eq 'foo' }
-      its(['array', 1]) { should eq 'one' }
-    end
-
-where
-
-* `name` is a configuration setting in a Yaml file
-* `should eq 'foo'` tests a value of `name` as read from a Yaml file versus the value declared in the test
-
-Like the `json` resource, the `yaml` resource can read a file, run a command, or accept content inline:
-
-    describe yaml('config.yaml') do
-      its(['driver', 'name']) { should eq 'vagrant' }
-    end
-
-    describe yaml({ command: 'retrieve_data.py --yaml' }) do
-      its('state') { should eq 'open' }
-    end
-
-    describe yaml({ content: "\"key1: value1\nkey2: value2\"" }) do
-      its('key2') { should cmp 'value2' }
-    end
-
-<br>
-
-## Examples
-
-The following examples show how to use this InSpec audit resource.
-
-### Test a kitchen.yml file driver
-
-    describe yaml('.kitchen.yaml') do
-      its(['driver','name']) { should eq('vagrant') }
-    end
-
-<br>
-
-## Matchers
-
-For a full list of available matchers, please visit our [matchers page](https://www.inspec.io/docs/reference/matchers/).
-
-### name
-
-The `name` matcher tests the value of `name` as read from a Yaml file versus the value declared in the test:
-
-    its('name') { should eq 'foo' }