security-specs (original) (raw)

Tunable Options

A number of tunable options are provided in the Bandit config. It was originally foreseen that these would be useful in configuring Bandit’s runtime behavior. In all practical scenarios however, these options are redundant and remain at the default setting.

Our proposed strategy is to remove these unnecessary config options and rely on sensible values provided by the Bandit authors.

Plugin Options

This section represents the largest block of configuration data and thus the largest pain point for adopters. It contains a lengthy set of configuration options for all available test plugins, without these options many plugins will malfunction or fail to run at all. The usefulness of many plugins is also directly dependent upon the data provided in this section of the config (e.g. the blacklist plugins) and as such this data should be considered part of the plugins functionality.

Our proposed strategy is to modify the plugin system to provide sensible defaults for all configurable test plugins, directly in the plugin code. This data can then be overridden in an external configuration only when desirable. This removes the need for any configuration data when default functioning is sufficient, and this should be in the majority of cases.

To accomplish this, the test plugin system will be modified to use classes for each plugin instead of the function that is currently used. Each class will provide one or more testing methods, equivalent to the current testing functions, and one method to return a default configuration shared by all testing methods provided by that class. In the default case, this configuration data will be sent back to each test method, or it may be overridden by an external configuration if present.

In addition to removing the need for a configuration file this approach has two advantages. Firstly, it allows external plugins from third parties to provide configuration data along with their plugins without the need to edit a central default config file shipped by the Bandit project. Secondly, it allows for a config generation tool to auto-discover all available plugins and create a default configuration file by simply invoking the config method on each discovered plugin class, or on some desirable subset of these.

Profiles

This section is the primary concern for gate adopters, it is here that they may select the set of plugin tests that they wish to run on their project. It is nearly always configured as part of the initial Bandit setup.

Our proposed strategy is to provide a number of new mechanisms to indicate the desired set of tests to run, deprecating the current situation. Firstly, we allow profiles to be configured in their own individual files that use a much simpler layout than than the current single config file. Secondly, we will permit the specification of test sets directly from the command line interface of Bandit.

The first option will allow manual users of Bandit to easily create and re-use various test profiles that they might need to use frequently.

The second option will permit gate adopters to list their desired test set as part of the Bandit command invocation given within their existing tox.ini file. This has precedent and matches closely to the way PEP8 tests are currently configured.

To further improve upon the current state of affairs, again borrowing from hacking/flake8/pep8, Bandit will support a canonical numbering system for test plugins. These numeric names may be used anywhere that the usual descriptive, but often unwieldy, full test names would be used.

An example canonical scheme may look like the following

B1xx - blacklisted functions B2xx - blacklisted imports B3xx - injections …

A Note On Blacklists

As implied from the example scheme given above, each blacklisted module and import now will also be assigned a unique identifier. The intention here is to aid in configuration of these lengthy blacklists. So while blacklisted modules and methods will share common logic, individual items will be distinguishable as if they were separate tests when configuring Bandit.

Assignee(s)

The Bandit core team will lead the development of these changes.

Primary assignee:

tkelsey tmcpeak

Milestones

Target Milestone for completion:

Mitaka 3

Work Items

• Strip out miscellaneous options from Bandit config

• Add a separate text formatter that includes terminal output colors, removing the need for these to be configurable.

• Add support for external profile files.

• Convert plugins to classes which implement one or more tests and provide a config generation function.

• Assign canonical numbers to each plugin, including blacklist modules and imports.

• Add support for test selection via the CLI.

• Update the config generator to output default configs.

• Delete the config file bundled with Bandit.

Problem description

Currently the Anchor CSR validation functionality is all located in the Anchor package. This prevents the validation functionality from being easily imported and used by other projects. Therefore, the validation functionality should be split out into a module under anchor, so it can be imported by other projects. This will provide a simple API to the validation functionality, that can be used by both Anchor and other projects.

This will enable re-use of the CSR validation functionality in other projects, such as the proposed CA/RA Killick, or in Barbican.

Secondly, the code that performs validation of a CSR aborts when one of the validators fails - this works ok for Anchor, but the validation engine can be extended to provide added value for other services by running all validators and returning a dictionary, giving the result of each validator that was run.

Proposed change

Break out the code that iterates over the validators from certificate_ops.py into a new file ‘validation.py’. Extend this to return a dictionary giving the validator name and its return value, or throw an exception if an error occured.

Modify certificate_ops.py to work with the new validation.py and dictionary return, while catching any exceptions thrown.

Fix the tests to work with this new functionality.

Implementation

doug-chivers

Dependencies

Anchor

References

N/A

Problem description

A detailed description of the problem.

Proposed change

Here is where you cover the change you propose to make in detail. How do you propose to solve this problem?

If this is one part of a larger effort make it clear where this piece ends. In other words, what’s the scope of this effort?

Include which OpenStack security project this will apply to (OpenStack Security Guide, OpenStack Security Notes, Bandit, etc). Also include where in the OpenStack security project tree hierarchy this will reside.

Implementation

Dependencies

• Include specific references to specs and/or blueprints in openstack-manuals, or in other projects, that this one either depends on or is related to.

• Does this feature require any new library dependencies or code otherwise not included in OpenStack? Or does it depend on a specific version of library?

References

Please add any useful references here. You are not required to have any reference. Moreover, this specification should still make sense when your references are unavailable. Examples of what you could include are:

• Links to mailing list or IRC discussions

• Links to notes from a summit session

• Links to relevant research, if appropriate

• Related specifications as appropriate

• Anything else you feel it is worthwhile to refer to