Chapter 59. Security
scap-security-guide example kickstart files for Red Hat Enterprise Linux 6 are not recommended for use
The Red Hat Enterprise Linux 6 example kickstart files, which are included in the scap-security-guide package for Red Hat Enterprise Linux 7, install the latest version of the scap-security-guide package directly from the upstream repository, which means that this version has not been checked by the Red Hat Quality Engineering team. To work around this problem, use the corrected Red Hat Enterprise Linux 6 example kickstart files from the scap-security-guide package that is included in the current Red Hat Enterprise Linux 6 release, or alternatively, manually change the %post section in the kickstart file. Note that the Red Hat Enterprise Linux 7 example kickstart files are not affected by this problem. (BZ#1378489)
The openscap packages do not install atomic as a dependency
The OpenSCAP suite enables integration of the Security Content Automation Protocol (SCAP) line of standards. The current version adds the ability to scan containers using the
atomic scan
and oscap-docker
commands. However, when you install only the openscap, openscap-utils, and openscap-scanner packages, the atomic package is not installed by default. As a consequence, any container scan command fails with an error message. To work around this problem, install the atomic package by running the yum install atomic
command as root. (BZ#1356547)
CIL
does not have a separate module statement
The new SELinux userspace uses SELinux Common Intermediate Language (CIL) in the module store. CIL treats files as modules and does not have a separate module statement, the module is named after the file name. As a consequence, this can cause confusion when a policy module has a name that is not the same as its base filename, and the
semodule -l
command does not show the module version. Additionaly, semodule -l
does not show disabled modules. To work around this problem, list all modules using the semodule --l=full
command. (BZ#1345825)