Chapter 58. Security


OpenSCAP rpmverifypackage does not work correctly

The chdir and chroot system calls are called twice by the rpmverifypackage probe. Consequently, an error occurs when the probe is utilized during an OpenSCAP scan with custom Open Vulnerability and Assessment Language (OVAL) content.
To work around this problem, do not use the rpmverifypackage_test OVAL test in your content or use only the content from the scap-security-guide package where rpmverifypackage_test is not used. (BZ#1603347)

dconf databases are not checked by OVAL

OVAL (Open Vulnerability and Assessment Language) checks used in the SCAP Security Guide project are not able to read a dconf binary database, only files used to generate the database. The database is not regenerated automatically, the administrator needs to enter the dconf update command. As a consequence, changes to the database that are not made using files in the /etc/dconf/db/ directory cannot be detected by scanning. This may cause false negatives results.
To work around this problem, run dconf update periodically, for example, using the /etc/crontab configuration file. (BZ#1631378)

SCAP Workbench fails to generate results-based remediations from tailored profiles

The following error occurs when trying to generate results-based remediation roles from a customized profile using the the SCAP Workbench tool:
Error generating remediation role '.../remediation.sh': Exit code of 'oscap' was 1: [output truncated]
To work around this problem, use the oscap command with the --tailoring-file option. (BZ#1533108)

OpenSCAP scanner results contain a lot of SELinux context error messages

The OpenSCAP scanner logs inability to get SELinux context on the ERROR level even in situations where it is not a true error. As a result, OpenSCAP scanner results contain a lot of SELinux context error messages. Both the oscap command-line utility and the SCAP Workbench graphical utility outputs can be hard to read for that reason. (BZ#1640522)

oscap scans use an excessive amount of memory

Result data of Open Vulnerability Assessment Language (OVAL) probes are kept in memory for the whole duration of a scan and the generation of reports is also a memory-intensive process. Consequently, when very large file systems are scanned, the oscap process can take all available memory and be killed by the operating system.
To work around this problem, use tailoring to exclude rules that scan complete file systems and run them separately. Furthermore, do not use the --oval-results option. As a result, if you lower the amount of processed data, scanning of the system should no longer crash because of the excessive use of memory. (BZ#1548949)
Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.