ComplianceAsCode
Add custom OVAL for partition_for_tmp to check for tmp.mount service.
Description:
- Create custom OVAL check for
/tmppartition. This enables the check to comply with checking oftmp.mountservice status.
Rationale:
- Reference: https://www.stigviewer.com/stig/red_hat_enterprise_linux_7/2020-09-03/finding/V-204496
Questions:
- I'm not entirely sure if we need such check. I suspect that
partition_testis enough which comes from themounttemplate. What do you think?
Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all
Changes identified: Rules: partition_for_tmp
Show details
Rule partition_for_tmp: OVAL check is newly added.
Recommended tests to execute: build_product rhel8 tests/test_suite.py rule --libvirt qemu:///system test-suite-vm --remediate-using bash --datastream build/ssg-rhel8-ds.xml partition_for_tmp
I would make the check for tmp.mount service a new rule.
If there is a second way to have /tmp in a separate partition. Which one would be the remediated state of this rule?
Also, the tmp.mount service doesn't play well with current rules for partition options. With the systemd.mount the options are defined in the Unit file.
I would make the check for
tmp.mountservice a new rule.
I tried to use the service enabled template, but tmp.mount is kind of a special service and doesn't fit with our existent template. Also it's an OR condition between these two items, I don't know how it would be handled as two separate rules.
I tried to use the service enabled template, but
tmp.mountis kind of a special service and doesn't fit with our existent template.
Yeah, some different configuration is required in a unit file.
Also it's an
ORcondition between these two items, I don't know how it would be handled as two separate rules.
Handling ORs in a profile is tricky, the choice of what path to take is not easy automate.
Checking that either condition is satisfied is fine in a rule. But when it comes to fixing it, what should the rule do fstab or tmp.mount?
I think the way these situations were dealt with in the past was by making the profiles opinionated. The profile author, or SME, makes the default choice, and leads the profile that way.
Ideally, it would be easy to tailor the profile to the other choices, or have pre-defined tailorings (or other profiles). But I don't know how that would be done without getting too complex.
@ggbecker Any updates?
Not really, I don't know if this fix is correct and if it makes sense.
@ggbecker Let's summarize what we already know.
Before this change the rule used the mount template which uses OVAL partition test which reads data from /proc/mounts.
The STIG rule allows 2 options: enabled tmp.mount service or a separate partition defined in /etc/fstab.
If you don't have any of these, you won't find any /tmp entry in /proc/mounts so the OVAL partition test will fail.
If you enable tmp.mount systemd unit, a /tmp entry will appear in /proc/mounts so the OVAL partition test will pass.
If you instead create a separate partition, a /tmp entry will also appear in /proc/mounts so the OVAL partition test will pass.
That means that the partition test covers both situation required by the rule. I have checked that on a RHEL 7 VM.
It seems that the OVAL partition check in mount template is sufficient for the rule.
@ggbecker @yuumasato What else do we need to know?
@ggbecker: PR needs rebase.
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
![openshift-ci[bot] avatar](https://avatars.githubusercontent.com/in/91280?v=4 "Published by a pub.dev verified publisher"){kind=small}
@ggbecker: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:
| Test name | Commit | Details | Required | Rerun command |
|---|---|---|---|---|
| ci/prow/e2e-aws-ocp4-cis | 2a2467fcda420fc375ede758c78f4ff185002a07 | link | /test e2e-aws-ocp4-cis |
|
| ci/prow/e2e-aws-ocp4-moderate | 2a2467fcda420fc375ede758c78f4ff185002a07 | link | /test e2e-aws-ocp4-moderate |
|
| ci/prow/e2e-aws-rhcos4-e8 | 2a2467fcda420fc375ede758c78f4ff185002a07 | link | /test e2e-aws-rhcos4-e8 |
|
| ci/prow/e2e-aws-rhcos4-moderate | 2a2467fcda420fc375ede758c78f4ff185002a07 | link | /test e2e-aws-rhcos4-moderate |
|
| ci/prow/e2e-aws-ocp4-cis-node | 2a2467fcda420fc375ede758c78f4ff185002a07 | link | /test e2e-aws-ocp4-cis-node |
|
| ci/prow/e2e-aws-ocp4-high | 2a2467fcda420fc375ede758c78f4ff185002a07 | link | true | /test e2e-aws-ocp4-high |
| ci/prow/e2e-aws-ocp4-high-node | 2a2467fcda420fc375ede758c78f4ff185002a07 | link | true | /test e2e-aws-ocp4-high-node |
| ci/prow/e2e-aws-rhcos4-high | 2a2467fcda420fc375ede758c78f4ff185002a07 | link | true | /test e2e-aws-rhcos4-high |
| ci/prow/e2e-aws-ocp4-stig-node | 2a2467fcda420fc375ede758c78f4ff185002a07 | link | true | /test e2e-aws-ocp4-stig-node |
| ci/prow/e2e-aws-ocp4-stig | 2a2467fcda420fc375ede758c78f4ff185002a07 | link | true | /test e2e-aws-ocp4-stig |
Full PR test history. Your PR dashboard.
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.