Este conteúdo não está disponível no idioma selecionado.
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]
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)