-
Notifications
You must be signed in to change notification settings - Fork 685
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SLE15 audit rules mac modification usr share depends on selinux policy packages #10883
Conversation
Skipping CI for Draft Pull Request. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My main concern is that the change of the XCCDF manual file isn't mentioned in the PR description. It gives a false impression that this PR is solely about the single audit rule. Such a big change as XCCDF manual update should be submitted as a separate PR instead.
{{%- if 'sle15' in product -%}} | ||
<criteria operator="AND"> | ||
<criterion test_ref="check_selinux_policy_devel_installed" | ||
comment="Check no selinux-policy-devel package installed" negate="true"/> | ||
<criterion test_ref="check_selinux_policy_targeted_installed" | ||
comment="Check no selinux-policy-targeted package installed" negate="true"/> | ||
</criteria> | ||
{{%- endif -%}} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have you considered creating a platform restriction in the rule.yml instad of modifying the OVAL? What are the reasons for this solution?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The main reason here is that for sle platform, not sure about the others, we need to have some of the selinux-policy packages installed in order the whole rule to be relevant because otherwise even if we have selinux installed with no policies there is nothing to audit
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That doesn't explain why you chose this way, you can get the same result with using platform expressions. Also if you used platforms you would get "notapplicable" results if the package isn't present, and that way you can get more understandable user experience in the HTML report.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So I assume your suggestion to rework it, so the rule is limited by platform clause:
platform: package[selinux-policy-devel] or [selinux-policy-targeted]
,
and add declaration of the relevant packages for all linux flavours?
@@ -22,6 +30,11 @@ | |||
</criteria> | |||
</definition> | |||
|
|||
{{%- if 'sle15' in product -%}} | |||
{{{ oval_test_package_installed(package="selinux-policy-devel", evr=EVR, test_id="check_selinux_policy_devel_installed") }}} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The EVR
variable isn't defined. You probably wanted to set it to None or you can remove the evr=EVR,
completely because it's a parameter with a default value (see the definition of the oval_test_package_installed
macro).
ff68aba
to
c59f17e
Compare
Thanks to @jan-cerny for the tip
{{%- if 'sle15' in product -%}} | ||
<criteria operator="AND"> | ||
<criterion test_ref="check_selinux_policy_devel_installed" | ||
comment="Check no selinux-policy-devel package installed" negate="true"/> | ||
<criterion test_ref="check_selinux_policy_targeted_installed" | ||
comment="Check no selinux-policy-targeted package installed" negate="true"/> | ||
</criteria> | ||
{{%- endif -%}} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That doesn't explain why you chose this way, you can get the same result with using platform expressions. Also if you used platforms you would get "notapplicable" results if the package isn't present, and that way you can get more understandable user experience in the HTML report.
@@ -4,6 +4,14 @@ | |||
mandatory access controls (SELinux) in usr/share/selinux are enabled.") }}} | |||
|
|||
<criteria operator="OR"> | |||
{{%- if 'sle15' in product -%}} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This condition also matches any other string that contains "sle15" as a substring, eg. "sle158", "ssle15". That means it can match unwanted products in future. Normally, you should do product == "sle15"
, or better, product in ["sle15"]
. The latter will allow people do have an easier expansion in future.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the tip changed it in c3a8fb7
Thanks to @jan-cerny for the tip
Code Climate has analyzed commit c3a8fb7 and detected 0 issues on this pull request. The test coverage on the diff in this pull request is 100.0% (50% is the threshold). This pull request will bring the total coverage in the repository to 53.2% (0.0% change). View more on Code Climate. |
8d96a74
into
ComplianceAsCode:master
Description:
Rationale: