Each time an operating system is installed it needs to be configured – but before the new settings are in place, there is a short period when the system is not configured in line with your policies. In many cases this is not a problem, however in a highly secured environment a misconfigured system poses a threat.
OSCAP-Anaconda-Addon solves this exact problem. It is an add-on for the Anaconda installer that enables administrators to feed security policy into the installation process and ensure that systems are compliant from the very first boot.
The easiest way to use OSCAP-Anaconda-Addon is to pick a Linux distribution which comes with it built-in. Today, the only such distribution is Red Hat Enterprise Linux 7 Update 2. The other option is to create your own compose with the add-on and security policy.
When the plug-in is enabled, a screen will pop-up during installation asking the user to provide a security policy. The add-on then checks for misconfiguration, before installation starts, and notifies the user if anything requires attention – for example a non-compliant partitioning scheme.
The OSCAP Anaconda Addon supports the following modes of Anaconda installer operation:
Fundamentally, there are two modes of operation: attended and unattended. In an attended installation, users are able to select one of the pre-loaded policies, or they can provide a url of the policy to be applied. In an unattended installation, users include a small section in their kickstart file that configures the OSCAP Anaconda Addon.
What happens in both cases is similar. The add-on acts on the remediation instructions of the selected security policy. In the policy file, there can be two types of remediations: special anaconda instructions and generic scripts. Special anaconda instructions can ensure things like partitioning, the set of installed packages, or bootloader options comply with the security policy provided. Everything else is ensured by the generic scripts which are executed after the packages are installed, but before the first boot.
After the first boot, audit results are stored in the /root directory.