Automated Reference Assignment: Allow Skippping of Controls

[yuumasato]

Description:

• Add a new key that allows Controls to be skipped from automated "referencing" during build.

Rationale:

• This is useful when a control is added only to select rules that, strictly speaking, are not in the Policy but are required to function properly.
• Fixes strange references in the RHEL9 data stream
  <xccdf-1.2:reference href="https://public.cyber.mil/stigs/downloads/?_dl_facet_stigs=operating-systems%2Cunix-linux">needed_rules</xccdf-1.2:reference>
• This will also be useful for OCP4 STIG control file from Add OCP4 STIG control file and auto-add references  #11593
• Follow up of Use control files to generate references #11594

Review Hints:

• Build content before and after PR and check that STIG needed_rules references are gone.

[github-actions]

Start a new ephemeral environment with changes proposed in this pull request:

Fedora Environment

Oracle Linux 8 Environment

[github-actions]

🤖 A k8s content image for this PR is available at:
ghcr.io/complianceascode/k8scontent:11630

Click here to see how to deploy it

If you alread have Compliance Operator deployed:
utils/build_ds_container.py -i ghcr.io/complianceascode/k8scontent:11630

Otherwise deploy the content and operator together by checking out ComplianceAsCode/compliance-operator and:
CONTENT_IMAGE=ghcr.io/complianceascode/k8scontent:11630 make deploy-local

[yuumasato]

@Mab879 @jan-cerny If the needed_rules reference is actually there by design I can drop the second commit.
I would still like to leverage the skip_reference in OCP4 STIG profile.

[Mab879]

We will need to figure out what we want to do about the missing refs test. Do want to somehow add a exclude list?

[jan-cerny]

I don't have a strong opinion.

I can imagine the situation in which the reference to a dummy control would be useful. Remember that the users don't have access to the control files, they only use the data stream. If they review the profile eg. in HTML guide they will see that all rules have a reference to the STIG policy except this one so they might wonder if the rule is there by mistake. So in that case a reference to the dummy control could be a helpful information.

If you decide to remove it please add a whitelist as Matthew suggested.

[xiaojiey]

/hold for test

[yuumasato]

I don't have a strong opinion.

I can imagine the situation in which the reference to a dummy control would be useful. Remember that the users don't have access to the control files, they only use the data stream. If they review the profile eg. in HTML guide they will see that all rules have a reference to the STIG policy except this one so they might wonder if the rule is there by mistake. So in that case a reference to the dummy control could be a helpful information.

Still, as you mentioned, the user doesn't have access to the control file, only the data stream. So listing a dummy control in the rule can be confusing too.

[yuumasato]

@jan-cerny By the way, these "needed rules" could also be directly selected in rhel9/profiles/stig.profile. What are your thoughts on that?
Some of the OCP4 profiles do that for "needed rules":

content/products/ocp4/profiles/high-rev-4.profile

Lines 50 to 52 in cb599e6

	### This is a helper rule to fetch the required api resource for detecting OCP version
	- version_detect_in_ocp
	- version_detect_in_hypershift

This approach will still trigger "missing references" failures though.
Maybe expecting that all rules in a "referenced" profile have the reference is too much?
And we need to allow for exceptions...

[jan-cerny]

I think adding there the exception list would be great.

Maybe expecting that all rules in a "referenced" profile have the reference is too much?

So for some profile we expect this and we had the test for years. This expectation is easy and consistent.

[yuumasato]

@jan-cerny We have moved the rules that don't support a STIG ID out of the control file into the profile file.
So we don't have the need for the skip_reference key anymore.

If you are not interested in this feature we can close the PR.

I think adding there the exception list would be great.

I gave it some thought and am curious how you would implement this.
The test only looks at the built data stream, it doesn't look at the source, and this okay, it makes sense to me.
I see a few ways this test could have an exception list:

1. By breaking this concept and making the test aware of a product's profile and the source control used by them to check which controls skipped auto-referencing during build.
   I'm not sure it is worth it to add all this product/profile/control parsing logic to this test.
2. By maintaining a matrix of rules per product per profile that can miss a certain reference.
   This approach also seems error prone and will require constant maintenance with profile updates.
3. A plain hard coded list of rules that are okay missing any type of references in any profile/product.
   From what I could check, for RHEL only dconf_db_up_to_date and enable_authselect are extraneous in the control file.
   This may lead to errors where listed rules may be missing valid references.

[jan-cerny]

It would have to be a hardcoded list of tuples (rule, product, profile).

I assume that these rules are an exception and not something that should be there on a large scale.

[yuumasato]

@jan-cerny I'm sorry but I won't have the time to pursue this. I'm closing the PR, feel free to reuse the commit.