The extensions for the Anaconda installer (called add-ons) are represented in the kickstart through special %addon sections that start with a unique name for the add-on. In case of the OSCAP Anaconda add-on, the header of the section starts with the following line: %addon org_fedora_oscap that includes the unique name of the add-on constructed from the reversed domain name (org_fedora) and the name of the add-on (oscap). The section ends with the %end line and all the lines in between are passed to the add-on to process and store. For the OSCAP add-on we have decided to use simple key-value pairs to set parameters.
At this moment the OSCAP Anaconda add-on understands the following keys (depending on the content type used):
content-type
Type of the content given by one of the datastream, archive, rpm or scap-security-guide values.
content-url
URL of the content (so far only http, https, and ftp URLs are supported).
datastream-id
ID of the data stream from a datastream collection referenced by content-url.
xccdf-id
ID of the benchmark that should be used.
content-path (deprecated alias: xccdf-path)
path to the datastream or the XCCDF file that should be used, given as a relative path in the archive.
profile
ID of the profile that should be applied (or default if the default profile should be used).
fingerprint
MD5, SHA1 or SHA2 fingerprint/hash/checksum of the content refered by the content-url.
tailoring-path
Path of the tailoring file that should be used, given as a relative path in the archive.
The special scap-security-guide content-type means that the scap-security-guide content should be used and no additional parameters need to be passed with it. The scap-security-guide content/package has to be available in the compose. In the future, more URL types will be supported (e.g. pointing to a USB device) as well as some more keys and values will be processed (e.g. cpe-path and certificates for specifying path to a CPE dictionary and a file with a certificate chain, respectivelly).
A typical %addon section for the OSCAP addon may then look like this:
%addon org_fedora_oscap
content-type = datastream
content-url = http://www.example.com/scap/testing_ds.xml
datastream-id = scap_example.com_datastream_testing
xccdf-id = scap_example.com_cref_xccdf.xml
profile = xccdf_example.com_profile_my_profile
fingerprint = 240f2f18222faa98856c3b4fc50c4195
%end
The key-value pairs are whitespace-agnostic and the values may optionally be enclosed in single or double quotes.
Although basically any SCAP content may be used in combination with the OSCAP addon and applied to the newly installed system, there are some types of rules that should be taken into account even before the actual installation of the system. Thus the addon understands and processes special <fix> elements that can be added to the XCCDF rules and that are identified by the special value of their system attribute set to urn:redhat:anaconda:pre as they are fixes intended for the Anaconda installer and the pre-installation phase.
Rules that need to be taken into account before the system is even installed include any rule restricting partitioning in some way, e.g. Create a separate partition or logical volume for /tmp. While it is not impossible to do that after installation (especially in this most trivial case), it is much more comfortable and practical to apply such restrictions in the installation process. For this reason the OSCAP add-on defines special command-like fix rules, inspired by kickstart file syntax, that may be added to the XCCDF rules which targret partitioning. Such rules are parsed and processed, and then the add-on doesn’t allow installation of a system that doesn’t follow them. The full specification of a partitioning rule is: part MOUNTPOINT [––mountoptions=OPT1[,OPT2[,OTP3…]]] which states that for the given MOUNTPOINT there has to be a separate partition or logical volume and should be mounted with the options OPT1, OPT2, etc. The whole <fix> element may then look something like this:
<fix reboot=”false” disruption=”high” system=”urn:redhat:anaconda:pre”>
part /tmp ––mountoptions=”nodev,noauto”
</fix>
Another part of the installation process is the creation of the root account for the installed system. And since the strength of the root password may be critical for the system, some rules may specify e.g. it’s minimal length. While the password may be changed even when the system is already installed and the root account exists, without changing or at least retyping it there is no way to check it’s length because only the hash of the password is stored. For these reasons the OSCAP add-on understands the following type of fix rules: passwd ––minlen=N specifying the minimal length of the root password. Currently it only shows a warning because there is no support for enforcing parametrized minimal password length in the Anaconda installer, but that should be fixed in the future.
The XCCDF rules may also require that some packages must or must not be installed. While such requirements may be fulfilled even after the system installation, it is better to deal with this directly in the system installation process as it may take much less time (in case of the forbidden packages) or make the packages (or more precisely their tools, etc.) ready and running even during the first boot of the newly installed system. The packaging rules look like this:
package [––add=iptables[ ––add=selinux-policy[ …]]] [––remove=telnet[ ––remove=dhcpd[…]]]
specifying which packages should be added to/removed from the installation transaction. However, using ––remove=PACKAGE doesn’t guarantee that the package definitely will not installed, as it may be added back to the transaction as a dependency of some other package.
Last set of rules supported by the OSCAP add-on, for now, are the boot loader rules. Typically, password protection of the boot loader is required. Thus, the add-on also understands the following content of a special <fix> element: bootloader ––passwd which means that the boot loader should be protected with a password. Since in the current version of the Anaconda installer, there is no way to enable and enter a boot loader password, the addon just displays a warning if there is no such password set (although it may be set via kickstart).
