Skip to content
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

Differentiate remediation types in has_no_remediation() #87

Open
comps opened this issue Jan 16, 2024 · 3 comments
Open

Differentiate remediation types in has_no_remediation() #87

comps opened this issue Jan 16, 2024 · 3 comments
Assignees

Comments

@comps
Copy link
Contributor

comps commented Jan 16, 2024

Currently, the function looks for Bash remediations only - this may incorrectly waive failing Ansible results that do have a valid Ansible remediation, but no Bash remediation scripts.

Also, the existing Bash-based logic is fairly hacky and manual. Try parsing the datastream XML instead.

@mildas
Copy link
Contributor

mildas commented Mar 27, 2024

For searching Ansible remediation, we could utilize similarly as for Bash # oscap xccdf generate --profile '(all)' fix --fix-type ansible and in output search for rule id. Ansible remediation has its rule id in tags:.

However, this approach will not work for IB as --fix-type blueprint creates you blueprint without any indication what rule is covered by what. For that, XML parsing is needed.

@comps
Copy link
Contributor Author

comps commented Jul 12, 2024

Significant help towards this is e1100f0 done via #155 .

This allows us to directly query bash/ansible/etc. remediations in the datastream XML.

Now we'd need to figure out how has_no_remediation() should work and how / if to parametrize it based on the remediation type being tested (/hardening/oscap vs /hardening/ansible vs ...).

@comps
Copy link
Contributor Author

comps commented Jul 30, 2024

The main reason we need to do this is to fix some false positives on non-Bash remediation technologies.

For example - kickstart / OAA / image-builder hardening should remediate some things that oscap alone cannot, like disk partitions (ie. by including them in an osbuild blueprint), and scans for those hardening types should not auto-waive failures in those rules. Doing so can lead to hiding bugs.

@comps comps self-assigned this Jul 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants