inspec-core 2.3.10 → 2.3.23

data/docs/dev/integration-testing.md

@@ -1,31 +0,0 @@
-# Integration Testing with InSpec
-
-## Introduction
-
-Inspec uses Test Kitchen for its integration testing. Our current testing uses Docker as our backend. You should install and have Docker running befor you run any tests.
-
-### How to run specific integrations
-
-To run a specific integration test use the following:
-
-```bash
-bundle exec rake test:integration[OS_NAME]
-```
-
-Example:
-```bash
-bundle exec rake test:integration[default-ubuntu-1604]
-```
-
-# Inspec Integrations
-
-### Test Kitchen
-
-We run the test/integration/default profile at the end of each integration test in the verify stage. This confirms that our current code is compatible with test kitchen.
-
-### Audit Testing
-
-For Audit cookbook testing InSpec sets up some special hooks. The integration rake command will bundle up the current checkout into a gem which is passed along to test kitchen in the os_prepare cookbook. When this cookbook is ran it will install the local inspec gem. Audit will then use this gem accordingly when running in the post chef-client validators. The .kitchen.yml is setup to export the audit report to a json file which we look for and confirm the structure in the test/integration/default/controls/audit_spec.rb file.
-
-In the validation file we confirm that the file was created from audit and that the structure looks correct. We also validate that the inspec ran with audit is the same that the current branch is using. This validates that audit did not use a older version for some reason.
-

data/docs/dev/plugins.md

@@ -1,323 +0,0 @@
-# Developing InSpec Plugins for the v2 plugin API
-
-## Introduction
-
-### Inspiration
-
-The software design of the InSpec Plugin v2 API is deeply inspired by the Vagrant plugin v2 system.  While the InSpec Plugin v2 system is an independent implementation, acknowledgements are due to the Hashicorp team for such a well-thought-out design.
-
-### Note About versions
-
-"v2" refers to the second major version of the Plugin API.  It doesn't refer to the InSpec release number.
-
-### Design Goals
-
-* Load-on-demand. Improve `inspec` startup time by making plugins load heavy libraries only if they are being used.
-* Independent velocity. Enable passionate community members to contribute at their own pace by shifting core development into plugin development
-* Increase dogfooding. Convert internal components into plugins to reduce core complexity and allow testing in isolation
-
-### Design Anti-goals
-
-* Don't implement resources in plugins; use resource packs for that.
-
-## How Plugins are Located and Loaded
-
-### Plugins are usually gems
-
-The normal distribution and installation method is via gems, handled by the `inspec plugin` command.
-
-`inspec plugin install inspec-myplugin` will fetch `inspec-myplugin` from rubygems.org, and install it and its gemspec dependencies under the user's `.inspec` directory.  You may also provide a local gemfile.  For local development, however, path-to-source is usually most convenient.
-
-For more on the `plugin` CLI command, run `inspec plugin help`.
-
-### Plugins may also be found by path to a source tree
-
-For local development or site-specific installations, you can also 'install' a plugin by path using `inspec plugin`, or edit `~/.inspec/plugins.json` directly to add a plugin.
-
-### The plugins.json file
-
-InSpec stores its list of known plugins in a file, `~/.inspec/plugins.json`. The purpose of this file is avoid having to do a gem path filesystem scan to locate plugins.  When you install, update, or uninstall a plugin using `inspec plugin`, InSpec updates this file.
-
-You can tell inspec to use a different config directory using the INSPEC_CONFIG_DIR environment variable.
-
-Top-level entries in the JSON file:
-
- * `plugins_config_version` - must have the value "1.0.0". Reserved for future format changes.
- * `plugins` - an Array of Hashes, each containing information about plugins that are expected to be installed
-
-Each plugin entry may have the following keys:
-
- * `name` - Required.  String name of the plugin.  Internal machine name of the plugin. Must match `plugin_name` DSL call (see Plugin class below).
- * `installation_type` - Optional, default "gem".  Selects a loading mechanism, may be either "path" or "gem"
- * `installation_path` - Required if installation_type is "path".  A `require` will be attempted against this path.  It may be absolute or relative; InSpec adds both the process current working directory as well as the InSpec installation root to the load path.
-
-TODO: keys for gem installations
-
-Putting this all together, here is a plugins.json file from the InSpec test suite:
-
-```json
-{
-  "plugins_config_version" : "1.0.0",
-  "plugins": [
-    {
-      "name": "inspec-meaning-of-life",
-      "installation_type": "path",
-      "installation_path": "test/unit/mock/plugins/meaning_of_life_path_mode/inspec-meaning-of-life"
-    }
-  ]
-}
-```
-
-## Plugin Parts
-
-### A Typical Plugin File Layout
-
-```
-inspec-my-plugin.gemspec
-lib/
-  inspec-my-plugin.rb  # Entry point
-  inspec-my-plugin/
-    cli.rb             # An implementation file
-    plugin.rb          # Plugin definition file
-    heavyweight.rb     # A support file
-```
-
-Generally, except for the entry point, you may name these files anything you like; however, the above example is the typical convention.
-
-### Gemspec and Plugin Dependencies
-
-This is a normal Gem specification file. When you release your plugin as a gem, you can declare dependencies here, and InSpec will automatically install them along with your plugin.
-
-If you are using a path-based install, InSpec will not manage your dependencies.
-
-### Entry Point
-
-The entry point is the file that will be `require`d at load time (*not* activation time; see Plugin Lifecycle, below).  You should load the bare minimum here - only the plugin definition file. Do not load any plugin dependencies in this file.
-
-```ruby
-# lib/inspec-my-plugin.rb
-require_relative 'inspec-my-plugin/plugin'
-```
-
-### Plugin Definition File
-
-The plugin definition file uses the plugin DSL to declare a small amount of metadata, followed by as many activation hooks as your plugin needs.
-
-While you may use any valid Ruby module name, we encourage you to namespace your plugin under `InspecPlugins::YOUR_PLUGIN`.
-
-```ruby
-# lib/inspec-my-plugin/plugin.rb
-module InspecPlugins
-  module MyPlugin
-    # Class name doesn't matter, but this is a reasonable default name
-    class PluginDefinition < Inspec.plugin(2)
-
-      # Metadata
-      # Must match entry in plugins.json
-      plugin_name :'inspec-my-plugin'
-
-      # Activation hooks (CliCommand as an example)
-      cli_command :'my-command' do
-        require_relative 'cli'
-        InspecPlugins::MyPlugin::CliCommand
-      end
-
-    end
-  end
-end
-```
-
-Note that the block passed to `cli_command` is not executed when the plugin definition is loaded.  It will only be executed if inspec decides it needs to activate that plugin component.
-
-Every activation hook is expected to return a `Class` which will be used in post-activation or execution phases. The behavior, duck typing, and superclass of that Class vary depending on the plugin type; see below for details.
-
-### Implementation Files
-
-Inside the implementation files, you should be sure to do three things:
-
-1. Load any heavyweight libraries your plugin needs
-2. Create a class (which you will return from the activator hook)
-3. Within the class, implement your functionality, as dictated by the plugin type API
-
-```ruby
-# lib/inspec-my-plugin/cli.rb
-
-# Load enormous dependencies
-require_relative 'heavyweight'
-
-module InspecPlugin::MyPlugin
-  # Class name doesn't matter, but this is a reasonable default name
-  class CliCommand < Inspec.plugin(2, :cli_command) # Note two-arg form
-    # Implement API or use DSL as dictated by cli_command plugin type
-    # ...
-  end
-end
-```
-
-## Plugin Lifecycle
-
-All queries regarding plugin state should be directed to `Inspec::Plugin::V2::Registry.instance`, a singleton object.
-
-```ruby
-registry = Inspec::Plugin::V2::Registry.instance
-plugin_status = registry[:'inspec-meaning-of-life']
-```
-
-### Discovery (Known Plugins)
-
-If a plugin is mentioned in `plugins.json` or is a plugin distributed with InSpec itself, it is *known*.  You can get its status, a `Inspec::Plugin::V2::Status` object.
-
-Reading the plugins.json file is handled by the Loader when Loader.new is called; at that point the registry should know about plugins.
-
-### Loading
-
-Next, we load plugins.  Loading means that we `require` the entry point determined from the plugins.json. Your plugin definition file will thus execute.
-
-If things go right, the Status now has a bunch of Activators, each with a block that has not yet executed.
-
-If things go wrong, have a look at `status.load_exception`.
-
-### Activation and Execution
-
-Depending on the plugin type, activation may be triggered by a number of different events. For example, CliCommand plugin types are activated when their activation name is mentioned in the command line arguments.
-
-After activation, code for that aspect of the plugin is loaded and ready to execute. Execution may be triggered by a number of different events. For example, the CliCommand plugin types are implicitly executed by Thor when `Inspec::CLI` calls `start()`.
-
-Refer to the sections below for details about activation and execution timing.
-
-## Implementing a CLI Command Plugin
-
-The CliCommand plugin_type allows you to extend the InSpec command line interface by adding a namespace of new commands. InSpec is based on [Thor](http://whatisthor.com/) ([docs](https://www.rubydoc.info/github/wycats/thor/Thor)), and the plugin system exposes Thor directly.
-
-CliCommand can do things like:
-
-```bash
-# A namespaced custom command with options
-you@machine$ inspec sweeten add --kind sugar --teaspoons 2
-# A namespaced custom command with short options
-you@machine$ inspec sweeten add -k agave
-# Mix global and namespace options
-you@machine$ inspec --debug sweeten add -k aspartame
-# Namespace included in help
-you@machine$ inspec help
-Commands:
-  inspec archive PATH      # archive a profile to tar.gz (default) or zip
-  inspec sweeten ...       # Add spoonfuls til the medicine goes down
-# Detailed help
-[cwolfe@lodi inspec-plugins]$ inspec help sweeten
-Commands:
-  inspec sweeten add [opts]       # Adds sweetener to your beverage
-  inspec sweeten count            # Reports on teaspoons in your beverage, always bad news
-```
-
-Currently, it cannot create a direct (non-namespaced) command, such as `inspec mycommand` with no subcommands.
-
-### Declare your plugin activators
-
-In your `plugin.rb`, include one or more `cli_command` activation blocks.  The activation block name will be matched against the command line arguments; if the name is present, your activator will fire (in which case it should load any needed libraries) and should return your implementation class.
-
-#### CliCommand Activator Example
-
-```ruby
-
-# In plugin.rb
-module InspecPlugins::Sweeten
-  class Plugin < Inspec.plugin(2)
-    # ... other plugin stuff
-
-    cli_command :sweeten do
-      require_relative 'cli.rb'
-      InspecPlugins::Sweeten::CliCommand
-    end
-  end
-end
-```
-
-Like any activator, the block above will only be called if needed. For CliCommand plugins, the plugin system naively scans through ARGV, looking for the activation name as a whole element.  Multiple CliCommand activations may occur if several different names match, though each activation will only occur once.
-
-```bash
-you@machine $ inspec sweeten ... # Your CliCommand implementation is activated and executed
-you@machine $ inspec exec ... # Your CliCommand implementation is not activated
-```
-
-Execution occurs implicitly via `Thor.start()`, which is handled by `bin/inspec`. Keep reading.
-
-You should also be aware of one other activation event: if the CLI is invoked as `inspec help`, *all* CliCommand plugins will activate (but will not be executed). This is so that each plugin's help information can be registered with Thor.
-
-### Implementation class for CLI Commands
-
-In your `cli.rb`, you should begin by requesting the superclass from `Inspec.plugin`:
-
-```ruby
-module InspecPlugins::Sweeten
-  class CliCommand < Inspec.plugin(2, :cli_command)
-    # ...
-  end
-end
-```
-
-The Inspec plugin v2 system promises the following:
-
-* The superclass will be an (indirect) subclass of Thor
-* The plugin system will handle registering the subcommand with Thor for you
-* The plugin system will handle setup of the subcommand help message for you
-
-### Implementing your command
-
-Within your `cli.rb`, you need to do two things:
-
-* Inform Inspec of your subcommand's usage and description, so the `help` commands will work properly
-* Implement your subcommands and options using the Thor DSL
-
-See also: [Thor homepage](http://whatisthor.com/) and [Thor docs](https://www.rubydoc.info/github/wycats/thor/Thor).
-
-#### Call subcommand_desc
-
-Within your implementation, make a call like this:
-
-```ruby
-# Class declaration as above
-subcommand_desc 'sweeten ...', 'Add spoonfuls til the medicine goes down'
-```
-
-The first argument is the usage message; it will be displayed whenever you execute `inspec help`, or when Thor tries to parse a malformed `inspec sweeten ...` command.
-
-The second is the command groups description, and is displayed with `inspec help`.
-
-Both arguments are free-form Strings intended for humans; the usage message should begin with your subcommand name to prevent user confusion.
-
-If you neglect to call this DSL method, Thor will not register your command.
-
-#### Adding Subcommands
-
-The minimum needed for a command is a call to `desc` to set the help message, and a method definition named after the command.
-
-```ruby
-desc 'Reports on teaspoons in your beverage, always bad news'
-def count
-  # Someone has executed `inspec sweeten count` - do whatever that entails
-  case beverage_type
-  when :soda
-    puts 12
-  when :tea_two_lumps
-    puts 2
-  end
-end
-```
-
-There is a great deal more you can do with Thor, especially concerning handling options. Refer to the Thor docs for more examples and details.
-
-#### Using no_command
-
-One common surprise seen with Thor is that every public instance method of your CliCommand implementation class is expected to be a CLI command definition. Thor will issue a warning if it encounters a public method definition without a `desc` call preceding it.  Two ways around this include:
-
-* Make your helper methods private
-* Enclose your non-command methods in a no_command block (a feature of Thor just for this circumstance)
-
-```ruby
-no_command do
-  def beverage_type
-    @bevvy
-  end
-end
-```

data/docs/dsl_inspec.md

@@ -1,354 +0,0 @@
----
-title: InSpec DSL
----
-
-# InSpec DSL
-
-InSpec is a run-time framework and rule language used to specify compliance, security, and policy requirements. It includes a collection of resources that help you write auditing controls quickly and easily. The syntax used by both open source and |chef compliance| auditing is the same. The open source |InSpec resource| framework is compatible with |chef compliance|.
-
-The InSpec DSL is a Ruby DSL for writing audit controls, which includes audit resources that you can invoke.
-
-The following sections describe the syntax and show some simple examples of using the InSpec resources.
-
-## Syntax
-
-The following resource tests |ssh| server configuration. For example, a simple control may described as:
-
-```ruby
-describe sshd_config do
-  its('Port') { should cmp 22 }
-end
-```
-
-In various use cases like implementing IT compliance across different departments, it becomes handy to extend the control with metadata. Each control may define an additional ``impact``, ``title`` or ``desc``. An example looks like:
-
-```ruby
-control 'sshd-8' do
-  impact 0.6
-  title 'Server: Configure the service port'
-  desc 'Always specify which port the SSH server should listen.'
-  desc 'rationale', 'This ensures that there are no unexpected settings'
-  tag 'ssh','sshd','openssh-server'
-  tag cce: 'CCE-27072-8'
-  ref 'NSA-RH6-STIG - Section 3.5.2.1', url: 'https://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf'
-
-  describe sshd_config do
-    its('Port') { should cmp 22 }
-  end
-end
-```
-
-where
-
-* `'sshd-8'` is the name of the control
-* `impact`, `title`, and `desc` define metadata that fully describes the importance of the control, its purpose, with a succinct and complete description
-* `desc` when given only one argument it sets the default description. When given 2 arguments (see: `'rationale'`) it will use the first argument as a header when rendering in Automate
-* `impact` is an float that measures the importance of the compliance results and must be a value between `0.0` and `1.0`. The value ranges are:
-  * `0.0 to <0.4` these are controls with minor criticality
-  * `0.4 to <0.7` these are controls with major criticality
-  * `0.7 to 1.0` these are critical controls
-* `tag` is optional meta-information with with key or key-value pairs
-* `ref` is a reference to an external document
-* `describe` is a block that contains at least one test. A `control` block must contain at least one `describe` block, but may contain as many as required
-* `sshd_config` is an InSpec resource. For the full list of InSpec resources, see InSpec resource documentation
-* `its('Port')` is the matcher; `{ should eq '22' }` is the test. A `describe` block must contain at least one matcher, but may contain as many as required
-
-## Advanced concepts
-
-With InSpec it is possible to check if at least one of a collection of checks is true. For example: If a setting is configured in two different locations, you may want to test if either configuration A or configuration B have been set. This is accomplished via `describe.one`. It defines a block of tests with at least one valid check.
-
-```ruby
-describe.one do
-  describe ConfigurationA do
-    its('setting_1') { should eq true }
-  end
-
-  describe ConfigurationB do
-    its('setting_2') { should eq true }
-  end
-end
-```
-
-### Sensitive resources
-
-In some scenarios, you may be writing checks involving resources with sensitive content (e.g. a file resource). In the case of failures, it may be desired to suppress output. This can be done by adding the `:sensitive` flag to the resource definition
-
-```ruby
-describe file('/tmp/mysecretfile'), :sensitive do
-  its('content') { should match /secret_info/ }
-end
-```
-
-## Examples
-
-The following examples show simple compliance tests using a single `control` block.
-
-## Test System Event Log
-
-The following test shows how to audit machines running Windows 2012 R2 that password complexity is enabled:
-
-```ruby
-control 'windows-account-102' do
-  impact 1.0
-  title 'Windows Password Complexity is Enabled'
-  desc 'Password must meet complexity requirement'
-  describe security_policy do
-    its('PasswordComplexity') { should cmp 1 }
-  end
-end
-```
-
-## Test if PostgreSQL passwords are empty
-
-The following test shows how to audit machines running PostgreSQL to ensure that passwords are not empty.
-
-```ruby
-control 'postgres-7' do
-  impact 1.0
-  title "Don't allow empty passwords"
-  describe postgres_session('user', 'pass').query("SELECT * FROM pg_shadow WHERE passwd IS NULL;") do
-    its('output') { should cmp '' }
-  end
-end
-```
-
-## Test if MySQL passwords are in ENV
-
-The following test shows how to audit machines running MySQL to ensure that passwords are not stored in `ENV`:
-
-```ruby
-control 'mysql-3' do
-  impact 1.0
-  title 'Do not store your MySQL password in your ENV'
-  desc '
-    Storing credentials in your ENV may easily expose
-    them to an attacker. Prevent this at all costs.
-  '
-  describe command('env') do
-    its('stdout') { should_not match /^MYSQL_PWD=/ }
-  end
-end
-```
-
-## Test if `/etc/ssh` is a Directory
-
-The following test shows how to audit machines to ensure that `/etc/ssh` is a directory:
-
-```ruby
-control 'basic-1' do
-  impact 1.0
-  title '/etc/ssh should be a directory'
-  desc '
-    In order for OpenSSH to function correctly, its
-    configuration path must be a folder.
-  '
-  describe file('/etc/ssh') do
-    it { should be_directory }
-  end
-end
-```
-
-## Test if Apache running
-
-The following test shows how to audit machines to ensure that Apache is enabled and running:
-
-```ruby
-control 'apache-1' do
-  impact 0.3
-  title 'Apache2 should be configured and running'
-  describe service(apache.service) do
-    it { should be_enabled }
-    it { should be_running }
-  end
-end
-```
-
-## Test if insecure packages are installed
-
-The following test shows how to audit machines for insecure packages:
-
-```ruby
-control 'cis-os-services-5.1.3' do
-  impact 0.7
-  title '5.1.3 Ensure rsh client is not installed'
-  describe package('rsh') do
-    it { should_not be_installed }
-  end
-  describe package('rsh-redone-client') do
-    it { should_not be_installed }
-  end
-end
-```
-
-## Test Windows Registry Keys
-
-The following test shows how to audit machines to ensure Safe DLL Search Mode is enabled:
-
-```ruby
-control 'windows-base-101' do
-  impact 1.0
-  title 'Safe DLL Search Mode is Enabled'
-  desc '
-    @link: https://msdn.microsoft.com/en-us/library/ms682586(v=vs.85).aspx
-  '
-  describe registry_key('HKLM\\System\\CurrentControlSet\\Control\\Session Manager') do
-    it { should exist }
-    it { should_not have_property_value('SafeDllSearchMode', :type_dword, '0') }
-  end
-end
-```
-
-## Exclude specific test
-
-This shows how to allow skipping certain tests if conditions are not met, by using `only_if`.
-In this example the test will not be performed if `redis-cli` command does not exist, because for example package on remote host was not installed.
-
-```ruby
-control 'nutcracker-connect-redis-001' do
-  impact 1.0
-  title 'Check if nutcracker can pass commands to redis'
-  desc 'execute redis-cli set key command, to check connectivity of the service'
-
-  only_if { command('redis-cli').exist? }
-
-  describe command('redis-cli SET test_inspec "HELLO"') do
-    its('stdout') { should match /OK/ }
-  end
-end
-```
-
-Mixing this with other conditionals (like checking existence of the files etc.) can help to test different test paths using InSpec. This way you can skip certain tests which would 100% fail due to the way servers are prepared, but you know that the same test suites are reused later in different circumstances by different teams.
-
-## Additional metadata for controls
-
-The following example illustrates various ways to add tags and references to `control`
-
-```ruby
-control 'ssh-1' do
-  impact 1.0
-
-  title 'Allow only SSH Protocol 2'
-  desc '
-    Only SSH protocol version 2 connections should be permitted.
-    The default setting in /etc/ssh/sshd_config is correct, and can be
-    verified by ensuring that the following line appears: Protocol 2
-  '
-
-  tag 'production','development'
-  tag 'ssh','sshd','openssh-server'
-
-  tag cce: 'CCE-27072-8'
-  tag disa: 'RHEL-06-000227'
-
-  tag remediation: 'stig_rhel6/recipes/sshd-config.rb'
-  tag remediation: 'https://supermarket.chef.io/cookbooks/ssh-hardening'
-
-  ref 'NSA-RH6-STIG - Section 3.5.2.1', url: 'https://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf'
-  ref 'http://people.redhat.com/swells/scap-security-guide/RHEL/6/output/ssg-centos6-guide-C2S.html'
-
-  describe ssh_config do
-    its('Protocol') { should cmp 2 }
-  end
-end
-```
-
-# Using Ruby in InSpec
-
-The InSpec DSL is a Ruby based language. This allows you to be flexible with
-Ruby code in controls:
-
-```ruby
-json_obj = json('/file.json')
-json_obj['keys'].each do |value|
-  ..
-end
-```
-
-Ruby allows a lot of freedoms, but should be limited in controls so that they
-remain portable and easy to understand. Please see our [profile style guide](./style).
-
-Core and custom resources are written as regular Ruby classes which inherit from
-`Inspec.resource`.
-
-
-## Interactive Debugging with Pry
-
-Here's a sample InSpec control that users Ruby variables to instantiate
-an InSpec resource once and use the content in multiple tests.
-
-```ruby
-control 'check-perl' do
-  impact 0.3
-  title 'Check perl compiled options and permissions'
-  perl_out = command('perl -V')
-  #require 'pry'; binding.pry;
-  describe perl_out do
-    its('exit_status') { should eq 0 }
-    its('stdout') { should match /USE_64_BIT_ALL/ }
-    its('stdout') { should match /useposix=true/ }
-    its('stdout') { should match /-fstack-protector/ }
-  end
-
-  # extract an array of include directories
-  perl_inc = perl_out.stdout.partition('@INC:').last.strip.split("\n")
-  # ensure include directories are only writable by 'owner'
-  perl_inc.each do |path|
-    describe directory(path.strip) do
-      it { should_not be_writable.by 'group' }
-      it { should_not be_writable.by 'other' }
-    end
-  end
-end
-```
-
-An **advanced** but very useful Ruby tip. In the previous example, I
-commented out the `require 'pry'; binding.pry;` line. If you remove the
-`#` prefix and run the control, the execution will stop at that line and
-give you a `pry` shell. Use that to troubleshoot, print variables, see
-methods available, etc. For the above example:
-
-```ruby
-[1] pry> perl_out.exit_status
-=> 0
-[2] pry> perl_out.stderr
-=> ""
-[3] pry> ls perl_out
-Inspec::Plugins::Resource#methods: inspect
-Inspec::Resources::Cmd#methods: command  exist?  exit_status  result  stderr  stdout  to_s
-Inspec::Resource::Registry::Command#methods: inspec
-instance variables: @__backend_runner__  @__resource_name__  @command  @result
-[4] pry> perl_out.stdout.partition('@INC:').last.strip.split("\n")
-=> ["/Library/Perl/5.18/darwin-thread-multi-2level",
- "    /Library/Perl/5.18",
-...REDACTED...
-[5] pry> exit    # or abort
-```
-
-You can use `pry` inside both the controls DSL and resources. Similarly,
-for dev and test, you can use `inspec shell` which is based on `pry`,
-for example:
-
-```ruby
-$ inspec shell
-Welcome to the interactive InSpec Shell
-To find out how to use it, type: help
-
-inspec> command('ls /home/gordon/git/inspec/docs').stdout
-=> "ctl_inspec.rst\ndsl_inspec.rst\ndsl_resource.rst\n"
-inspec> command('ls').stdout.split("\n")
-=> ["ctl_inspec.rst", "dsl_inspec.rst", "dsl_resource.rst"]
-
-inspec> help command
-Name: command
-
-Description:
-Use the command InSpec audit resource to test an arbitrary command that is run on the system.
-
-Example:
-describe command('ls -al /') do
-  it { should exist }
-  its('stdout') { should match /bin/ }
-  its('stderr') { should eq '' }
-  its('exit_status') { should eq 0 }
-end
-```