Introduce centralised policy definitions #6499
Conversation
The selections in child profiles will add or remove rules from the parent profile and override the values of XCCDF values.
This will allow us to use the controls in our profiles and will resolve the controls to the rulesduring the build process.
Using special keyword 'all' instead of list of controls in profile.yaml all the controls from given policy will be selected. This is practical for profiles that implement the whole controls catalog.
- Restructure profile classes, so their behavior can be extended by inheritance. - Made ResolvableProfile generic profile that knows the concept of controls, without implementation details. - Introduced ProfileWithInlinePolicies, renamed existing implementation to ProfileWithSeparatePolicies. - Extended the test suite, so it is able to test more implementations in a scalable way.
- Added test for the all-inline case. - Stramlined the inheritance relation of profiles. - Removed _control_to_items as it was not helpful.
- Prevented conversion from control to ID and to control again in _controls_to_items - Removed _policy_to_items - Modified the flow, so now controls are obtained in a list, and then merged to the profile one-by-one.
In this format, the items of policies lists are tuples that consists of a policy ID and control IDs separated by a colon.
and updated the profile accordingly.
Added the ANSSI minimal profile to the list of stable profiles.
Policies, controls and profiles can have a level assigned to them. Low-level controls are supposed to be essential and always be present in a profile, while the higher-level controls may be used only in strict profiles.
NT refers to the outdated version 1.1, whereas BP is for 1.2. There is no need to target 1.1
Don't parse other files than those that end by .yml
ANSSI R5 is about defense in-depth, which is broad topic. Note a few aspect of defense in-depth and add a few related rules.
Add rules to addres one aspect of the requiremnt: - password hashing algorithm - salt size - number of rounds
The selected rule assumes that rsyslog stores its logs in the default path, /var/log/audit
The rule is about enforcing accountability of operations.
In version 1.2, the restriction requirement changed to the /boot directory
The requirement is not totatlly automatable. Discuss and select a few rules for it.
These rules are added by ComplianceAsCode#6483
This rule is required by sshd_set_idle_timeout and must be selected otherwise the OVAL check will always fail.
Co-authored-by: Gabriel Becker <ggasparb@redhat.com>
The profile is under intense development and doesn't make sense keep the stability test for now.
It doesn't make sense to select a value called "default" since it's not defined in the benchmark.
|
Changes identified: Show detailsProfile anssi_nt28_enhanced on rhel7: Recommended tests to execute: |
This is a follow-up to #6089, as the source branch was updated. There are indications that the predecessor PR was misunderstood by reviewers at that time, and this is the most straightforward way of introducing it for reveiw again.
This PR presents a fully-functional PoC of a build system extension that allows to introduce product-agnostic elements to profile definitions.
Right now, profiles are tightly coupled with products. If there are two products that are very similar, respective profiles are almost or entirely identical. This creates following problems:
The centralised policy definition is able to overcome this - products automatically "take" selections from the policy, so it can be the target of interest when working with profile experts, as well as target of bugfixes, when a bug is discovered by a product user. Individual profiles can add product-specific rules outside of the centralised policy if they wish, and profiles can be protected against introduction of unwanted rules using the profile stability tests.
Additional benefit of centralised policies is that it brings together the structure of our content to the structure of policies how they are defined in respective documents - see this example from the ANSSI policy:
Regarding the implementation aspect of the PR:
The
controls/anssi.ymlfile contains ANSSI BP28 requirements stored in YAML format. The file is both machine-readable and human-readable. Each entry in the file represents an ANSSI requirement and contains the hardening level and a list of XCCDF rules mapped to this requirement. It concentrates the most important information into a single file. This form enables easier discussion and PRs on the rules mapping because it follows the logical structure of the original document.The profile definitions leverage the fact that the
controls/anssi.ymlcontains the rules and the profile levels they belong to. The profiles selection list in all 4 ANSSI profile files is replaced by a single statement that selects rules for the profile automatically.The core part of the PR is in
ssg/controls.pyPython module. It contains simple classes Control, Policy and ControlsManager. These classes implement parsing the controls file and contains methods that resolve them to a list of rules. ControlsManager is then used by the build system. There is also a simple unit test intests/unit/ssg-module/test_controls.pywhich tests these classes. There are a few example files used by the unit test intests/unit/ssg-module/data/.The
ssg/build_yaml.pyhas been refactored . Then, there is a new classProfileWithInlinePolicieswhich inhertis from the ResolvableProfile class. It can resolve the controls in the profile selections list, but it can still process the profiles that consist of individual rules. The class replaces its parent it during profile compilationProfileWithInlinePolicies.The build system change is subtle. The order of steps is still the same. Only the
build-scripts/compile_profiles.pyscript which compiles the profiles is changed to use the controls during profile resolution. The compiled profiles still look the same, they contain a resolved list of rules, which means next build steps aren’t changed.To avoid any confusion regarding possible unwanted implications PRs of this scale could introduce wrt content authors or developers, I emphasize that this PR
Its main use case is to assist content development of ANSSI profiles, where the ability to record rationale of rule selections has a high added value.