Local OpenSCAP Testing
Overview
When attempting to remediate OpenSCAP findings it is less than optimal to have to commit code and wait for all of the pipeline steps before scanning and subsequent failure. Instead, wouldn't it be great if you could perform OpenSCAP scans in a local container and quickly iterate before pushing your changes?
What You'll Need
- Your application image based on UBI
How To
Attach to your UBI image from Iron Bank
docker run -ti --rm --entrypoint=bash --user 0 <my-ubi-based-image>
Install the necessary tools
dnf install -y openscap-scanner bzip2 wget unzip
-or-
microdnf install -y openscap-scanner bzip2 wget unzip
Download and unzip the same STIG version in use by Iron Bank pipelines
wget https://github.com/ComplianceAsCode/content/releases/download/v0.1.61/scap-security-guide-0.1.61-oval-5.10.zip && \
unzip scap-security-guide-0.1.61-oval-5.10.zip
Execute oscap against all rules, or a single rule
All rules
oscap xccdf eval \
--verbose ERROR \
--fetch-remote-resources \
--profile "xccdf_org.ssgproject.content_profile_stig" \
--results compliance_output_report.xml \
--report report.html \
"scap-security-guide-0.1.61-oval-5.10/ssg-rhel9-ds.xml"
A single rule
oscap xccdf eval \
--verbose ERROR \
--fetch-remote-resources \
--profile "xccdf_org.ssgproject.content_profile_stig" \
--rule xccdf_org.ssgproject.content_rule_file_ownership_binary_dirs \
"scap-security-guide-0.1.61-oval-5.10/ssg-rhel9-ds.xml"
Scan results will show Pass or Fail.
Note
If you encounter certificate errors running either of the above commands, you may need to remove any port forwards from your docker run command.
Remediation Scripts
Most oscap findings will have remediation scripts in the ssg-rhel9-ds.xml with a system key value of urn:xccdf:fix:script:sh but I often find it easier to search within the HTML here: https://static.open-scap.org/ssg-guides/ssg-rhel9-guide-index.html.
Normally I will use a slightly altered version of the remediation script to find the files triggering the finding, and then examine those file for ownership and/or permission issues so I can better understand how my Dockerfile instructions resulted in oscap findings.
- Did I chmod 777 when I shouldn't have?
- Did I chown system libs for a user other than root?
- Did I lay down files from a tarball without examining what ownership and permission settings I was inheriting?
Permissions
RPMS If you want to see what permissions an rpm is going to bring you can do this either from macOS (brew install rpm) or a UBI9 container where we see the auth_pam_tool will have the SUID set so other users can run that file as root:
❯ rpm -qpivl mariadb-server.rpm | grep -i auth_pam_tool
warning: mariadb-server.rpm: Header V4 DSA/SHA1 Signature, key ID 1bb943db: NOKEY
lrwxrwxrwx 1 root root 66 Feb 10 17:53 /usr/lib/.build-id/16/8ed39e2ad2311e19a9b830624517cf680d9ab5 -> ../../../../usr/lib64/mysql/plugin/auth_pam_tool_dir/auth_pam_tool
drwx------ 2 root root 0 Feb 10 17:50 /usr/lib64/mysql/plugin/auth_pam_tool_dir
-rwsr-xr-x 1 root root 12472 Feb 10 17:52 /usr/lib64/mysql/plugin/auth_pam_tool_dir/auth_pam_tool
As a reminder:
SUID is a special file permission for executable files which enables other users to run the file with effective permissions of the file owner. Instead of the normal x which represents execute permissions, you will see an s (to indicate SUID) special permission for the user.
SGID is a special file permission that also applies to executable files and enables other users to inherit the effective GID of file group owner. Likewise, rather than the usual x which represents execute permissions, you will see an s (to indicate SGID) special permission for group user.