Update on Gentoo hardening guideHEADmaster

3 files changed, 2239 insertions, 1965 deletions

diff --git a/xml/SCAP/Makefile b/xml/SCAP/Makefile
index 208cd01..ad08a66 100644
--- a/xml/SCAP/Makefile
+++ b/xml/SCAP/Makefile
@@ -1,17 +1,12 @@
-location = "dev.gentoo.org:public_html/docs/security_benchmarks"
+gentoo: report-gentoo-xccdf.html guide-gentoo-xccdf.html remediate-gentoo-xccdf.sh gentoo-ds.xml
 
-all: report-gentoo-xccdf.html guide-gentoo-xccdf.html remediate-gentoo-xccdf.sh guide-gentoo-xccdf.docbook gentoo-ds.xml
-
-really_all: all report-gentoo-oval.xml
+all_gentoo: gentoo report-gentoo-oval.xml
 
 report-gentoo-xccdf.html: gentoo-cpe.xml gentoo-xccdf.xml gentoo-oval.xml prep
 	-pushd ~/tmp; oscap xccdf eval --cpe gentoo-cpe.xml --profile xccdf_org.gentoo.dev.swift_profile_default-oval --results results-gentoo-xccdf.xml --oval-results --check-engine-results --report report-gentoo-xccdf.html gentoo-xccdf.xml; popd
 
 guide-gentoo-xccdf.html: gentoo-cpe.xml gentoo-xccdf.xml gentoo-oval.xml prep
-	-pushd ~/tmp; oscap xccdf generate guide --profile xccdf_org.gentoo.dev.swift_profile_default-oval --output guide-gentoo-xccdf.html gentoo-xccdf.xml; popd
-
-guide-gentoo-xccdf.docbook: gentoo-cpe.xml gentoo-xccdf.xml gentoo-oval.xml prep
-	-pushd ~/tmp; oscap xccdf generate guide --profile xccdf_org.gentoo.dev.swift_profile_default-oval --format docbook --output guide-gentoo-xccdf.docbook gentoo-xccdf.xml; popd
+	-pushd ~/tmp; oscap xccdf generate guide --profile xccdf_org.gentoo.dev.swift_profile_default --output guide-gentoo-xccdf.html gentoo-xccdf.xml; popd
 
 remediate-gentoo-xccdf.sh: prep
 	-pushd ~/tmp; oscap xccdf generate fix --output remediate-gentoo-xccdf.sh results-gentoo-xccdf.xml chmod 0644 remediate-gentoo-xccdf.sh; popd
@@ -33,7 +28,4 @@ prep:
 	-sed -i "s|@@VERSION@@|`date +%Y%m%d`|g" ~/tmp/gentoo-xccdf.xml
 	-sed -i "s|@@DATE@@|`date +%Y-%m-%d`|g" ~/tmp/gentoo-xccdf.xml
 
-upload:
-	-pushd ~/tmp; scp gentoo-cpe.xml gentoo-xccdf.xml gentoo-oval.xml gentoo-ds.xml guide-gentoo-xccdf.html report-gentoo-oval.html report-gentoo-xccdf.html $(location)/; popd;
-
-.PHONY: all prep upload really_all
+.PHONY: gentoo prep all_gentoo
diff --git a/xml/SCAP/gentoo-oval.xml b/xml/SCAP/gentoo-oval.xml
index 427e5c1..c4a9da5 100644
--- a/xml/SCAP/gentoo-oval.xml
+++ b/xml/SCAP/gentoo-oval.xml
@@ -612,6 +612,22 @@
     </criteria>
   </definition>
 
+  <definition id="oval:org.gentoo.dev.swift:def:37" version="1" class="compliance">
+    <metadata>
+      <title>The / file system is mounted with the nodev option</title>
+      <affected family="unix">
+        <platform>Gentoo Linux</platform>
+      </affected>
+      <description>
+        This definition tests whether the / partition is mounted with the nodev 
+        mount option.
+      </description>
+    </metadata>
+    <criteria operator="AND">
+      <criterion test_ref="oval:org.gentoo.dev.swift:tst:41" comment="The / file system is mounted with nodev mount option" />
+    </criteria>
+  </definition>
+
 </definitions>
 
 <tests>
@@ -946,6 +962,15 @@
     <unix-def:state state_ref="oval:org.gentoo.dev.swift:ste:17" />
   </unix-def:file_test>
 
+  <lin-def:partition_test id="oval:org.gentoo.dev.swift:tst:41"
+    version="1" check="all" check_existence="all_exist"
+    comment="Tests that / is mounted with nodev option">
+    <!-- / partition -->
+    <lin-def:object object_ref="oval:org.gentoo.dev.swift:obj:29" />
+    <!-- "nodev" mount option -->
+    <lin-def:state state_ref="oval:org.gentoo.dev.swift:ste:2" />
+  </lin-def:partition_test>
+
 </tests>
 
 <objects>
@@ -1117,6 +1142,11 @@
     <unix-def:filename xsi:nil="true"/>
   </unix-def:file_object>
 
+  <lin-def:partition_object id="oval:org.gentoo.dev.swift:obj:29"
+    version="1" comment="The / partition">
+    <lin-def:mount_point>/</lin-def:mount_point>
+  </lin-def:partition_object>
+
 </objects>
 
 <states>
diff --git a/xml/SCAP/gentoo-xccdf.xml b/xml/SCAP/gentoo-xccdf.xml
index aa85c1e..35ea6c0 100644
--- a/xml/SCAP/gentoo-xccdf.xml
+++ b/xml/SCAP/gentoo-xccdf.xml
@@ -1,2018 +1,2270 @@
 <?xml version="1.0" encoding="UTF-8"?>
 <Benchmark xmlns="http://checklists.nist.gov/xccdf/1.2" xmlns:h="http://www.w3.org/1999/xhtml" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" id="xccdf_org.gentoo.dev.swift_benchmark_gentoo-@@VERSION@@-1" xsi:schemaLocation="http://checklists.nist.gov/xccdf/1.2 xccdf-1.2.xsd" resolved="0">
-  <status date="@@DATE@@">draft</status>
-  <title>Gentoo Security Benchmark</title>
-  <description>
-    This benchmarks helps people in improving their system configuration to be
-    more resilient against attacks and vulnerabilities.
-  </description>
-  <platform idref="cpe:/o:gentoo:linux"/>
-  <version>@@VERSION@@</version>
-  <model system="urn:xccdf:scoring:default" />
-  <model system="urn:xccdf:scoring:flat" />
-  <model system="urn:xccdf:scoring:flat-unweighted" />
-  <Profile id="xccdf_org.gentoo.dev.swift_profile_intensive" extends="xccdf_org.gentoo.dev.swift_profile_default">
-    <title>Intensive validation profile</title>
-    <description>
-      This profile extends the default server profile by including tests that 
-      are more intensive to run on a system. Tests such as full file system
-      scans to find world-writable files or directories have an otherwise too
-      large impact on the performance of a server. Tests include scripted
-      validationn.
-    </description>
-    <!-- Make sure all world-writable directories have the sticky bit set -->
-    <select idref="xccdf_org.gentoo.dev.swift_rule_worldwritedir-stickybit" selected="true" />
-  </Profile>
-  <Profile id="xccdf_org.gentoo.dev.swift_profile_intensive-oval" extends="xccdf_org.gentoo.dev.swift_profile_default-oval">
-    <title>Intensive validation profile (non-scripted)</title>
-    <description>
-      This profile extends the default server profile by including tests that 
-      are more intensive to run on a system. Tests such as full file system
-      scans to find world-writable files or directories have an otherwise too
-      large impact on the performance of a server. Tests do not include
-      scripted validation.
-    </description>
-    <!-- Make sure all world-writable directories have the sticky bit set -->
-    <select idref="xccdf_org.gentoo.dev.swift_rule_worldwritedir-stickybit" selected="true" />
-  </Profile>
-  <Profile id="xccdf_org.gentoo.dev.swift_profile_default-oval">
-    <title>Default server setup settings (non-scripted)</title>
-    <description>
-      In this profile, we verify common settings for Gentoo Linux
-      configurations. The tests that are enabled in this profile can be ran
-      without visibly impacting the performance of the system. No scripted
-      checks are executed.
-    </description>
-    <!-- The /tmp location is a separate file system -->
-    <select idref="xccdf_org.gentoo.dev.swift_rule_partition-tmp" selected="true" />
-    <!-- The /var location is a separate file system -->
-    <select idref="xccdf_org.gentoo.dev.swift_rule_partition-var" selected="true" />
-    <!-- The /var/log location is a separate file system -->
-    <select idref="xccdf_org.gentoo.dev.swift_rule_partition-varlog" selected="true" />
-    <!-- The /var/log/audit location is a separate file system -->
-    <select idref="xccdf_org.gentoo.dev.swift_rule_partition-varlogaudit" selected="true" />
-    <!-- The /home location is a separate file system -->
-    <select idref="xccdf_org.gentoo.dev.swift_rule_partition-home" selected="true" />
-    <!-- The /var/tmp location is a separate file system -->
-    <select idref="xccdf_org.gentoo.dev.swift_rule_partition-vartmp" selected="true" />
-    <!-- The /var partition is mounted with nodev -->
-    <select idref="xccdf_org.gentoo.dev.swift_rule_partition-var-nodev" selected="true" />
-    <!-- The /var/log partition is mounted with nodev -->
-    <select idref="xccdf_org.gentoo.dev.swift_rule_partition-varlog-nodev" selected="true" />
-    <!-- The /var/log/audit partition is mounted with nodev -->
-    <select idref="xccdf_org.gentoo.dev.swift_rule_partition-varlogaudit-nodev" selected="true" />
-    <!-- The /home partition is moounted with nodev -->
-    <select idref="xccdf_org.gentoo.dev.swift_rule_partition-home-nodev" selected="true" />
-    <!-- The /tmp partition is mounted with nodev -->
-    <select idref="xccdf_org.gentoo.dev.swift_rule_partition-tmp-nodev" selected="true" />
-    <!-- The /tmp partition is mounted with nosuid -->
-    <select idref="xccdf_org.gentoo.dev.swift_rule_partition-tmp-nosuid" selected="true" />
-    <!-- The /home partition is mounted with nosuid -->
-    <select idref="xccdf_org.gentoo.dev.swift_rule_partition-home-nosuid" selected="true" />
-    <!-- The /dev/shm partition is mounted with nosuid -->
-    <select idref="xccdf_org.gentoo.dev.swift_rule_partition-devshm-nosuid" selected="true" />
-    <!-- The /tmp partition is mounted with noexec -->
-    <select idref="xccdf_org.gentoo.dev.swift_rule_partition-tmp-noexec" selected="true" />
-     <!-- The /dev/shm partition is mounted with noexec -->
-    <select idref="xccdf_org.gentoo.dev.swift_rule_partition-devshm-noexec" selected="true" />
-    <!-- Kernel quota support must be enabled -->
-    <select idref="xccdf_org.gentoo.dev.swift_rule_kernel-quota" selected="true" />
-    <!-- /var is mounted with usrquota or grpquota -->
-    <select idref="xccdf_org.gentoo.dev.swift_rule_var-quota" selected="true" />
-    <!-- /home is mounted with usrquota or grpquota -->
-    <select idref="xccdf_org.gentoo.dev.swift_rule_home-quota" selected="true" />
-    <!-- No telnetd process is running -->
-    <select idref="xccdf_org.gentoo.dev.swift_rule_telnetd-notrunning" selected="true" />
-    <!-- No ftpd process is running -->
-    <select idref="xccdf_org.gentoo.dev.swift_rule_ftpd-notrunning" selected="true" />
-    <!-- sulogin is used as shell for single user boot (definition /etc/rc.conf) -->
-    <select idref="xccdf_org.gentoo.dev.swift_rule_rcconf-sulogin" selected="true" />
-    <!-- sulogin is used as shell for single user boot (definition /etc/inittab) -->
-    <select idref="xccdf_org.gentoo.dev.swift_rule_inittab-sulogin" selected="true" />
-    <!-- Verify that /etc/hosts.allow exists -->
-    <select idref="xccdf_org.gentoo.dev.swift_rule_hostsallow-exists" selected="true" />
-    <!-- Verify that /etc/at/at.allow exists -->
-    <select idref="xccdf_org.gentoo.dev.swift_rule_atallow-exists" selected="true" />
-    <!-- Make sure USE=pam is set -->
-    <select idref="xccdf_org.gentoo.dev.swift_rule_USE-pam" selected="true" />
-    <!-- Make sure USE=tcpd is set -->
-    <select idref="xccdf_org.gentoo.dev.swift_rule_USE-tcpd" selected="true" />
-    <!-- Make sure USE=ssl is set -->
-    <select idref="xccdf_org.gentoo.dev.swift_rule_USE-ssl" selected="true" />
-    <!-- Make sure FEATURES=webrsync-gpg is set -->
-    <select idref="xccdf_org.gentoo.dev.swift_rule_FEATURES-webrsync-gpg" selected="true" />
-    <!-- Make sure PORTAGE_GPG_DIR is set -->
-    <select idref="xccdf_org.gentoo.dev.swift_rule_PORTAGE_GPG_DIR-nonempty" selected="true" />
-    <!-- Make sure /etc/securetty only contains console and tty's -->
-    <select idref="xccdf_org.gentoo.dev.swift_rule_securetty-limitentries" selected="true" />
-    <!-- Make sure /proc is mounted with hidepid=1 or hidepid=2 -->
-    <select idref="xccdf_org.gentoo.dev.swift_rule_proc-hidepid" selected="true" />
-    <!-- Make sure /boot/grub/grub.conf (if it exists) has a password entry with md5 hash -->
-    <select idref="xccdf_org.gentoo.dev.swift_rule_grubconf-password-md5" selected="true" />
-    <!-- Make sure /etc/lilo.conf (if it exists) has a password entry -->
-    <select idref="xccdf_org.gentoo.dev.swift_rule_liloconf-password" selected="true" />
-  </Profile>
-  <Profile id="xccdf_org.gentoo.dev.swift_profile_default" extends="xccdf_org.gentoo.dev.swift_profile_default-oval">
-    <title>Default server setup settings</title>
-    <description>
-      In this profile, common settings for Gentoo Linux configurations are validated. 
-      The tests can be ran without visibly impacting the performance of the system, and
-      also includes the scripted evaluation checks (SCE).
-    </description>
-    <!-- The hardened toolchain must be installated and used -->
-    <select idref="xccdf_org.gentoo.dev.swift_rule_installation-toolchain-hardened" selected="true" />
-  </Profile>
-  <Group id="xccdf_org.gentoo.dev.swift_group_intro">
-    <title>Introduction</title>
-    <description>
-      <h:p>
-      Since years, Gentoo Linux has a Gentoo Security Handbook
-      which provides a good insight in secure system
-      configuration for a Gentoo systems. Although this is important, an
-      improved method for describing and tuning a systems' security state has
-      emerged: SCAP, or the <h:em>Security Content Automation Protocol</h:em>.
-      </h:p>
-      <h:p>
-      As such, this benchmark is an update on the security
-      handbook, including both the in-depth explanation of settings as well as
-      the means to validate if a system complies with this or not. Now, during
-      the development of this benchmark document, not include all
-      information from the Gentoo Security Handbook is included as some of the
-      settings are specific to a service that is not all that default on a
-      Gentoo Linux system or sufficiently separate that can benefit other
-      distributions as well. Although these settings are important as well, it is
-      best done in separate benchmarks for those services instead.
-      </h:p>
-      <h:p>
-      Where applicable, this benchmark will refer to a different hardening guide
-      for specific purposes (such as the Hardening OpenSSH benchmark).
-      </h:p>
-    </description>
-    <reference href="http://www.gentoo.org/doc/en/security/security-handbook.xml">Gentoo
-    Security Handbook</reference>
-    <Group id="xccdf_org.gentoo.dev.swift_group_intro-security">
-      <title>This is no security policy</title>
-      <description>
-        <h:p>
-        It is <h:em>very important</h:em> to realize that this document is not a
-        policy. There is no obligation to follow this to make a secure system
-        nor should everything in this document be agreed upon. This document is
-        a set of common best practices with the explanation (why is it a best practice)
-        and method (how to implement the best practice).
-        </h:p>
-        <h:p>
-        The purpose of this document is to guide readers in their quest to hardening
-        their systems.  It will provide pointers that could help in deciding
-        particular configuration settings and will do this hopefully using
-        sufficient background information to allow readers to make a good choice.
-	</h:p>
-	<h:p>
-        Readers might find settings they don't agree with. That's fine, but
-        if there is disagreement about <h:em>why</h:em> it is documented, we would
-        like to hear it so we can update the guide accordingly.
-	</h:p>
-      </description>
-    </Group>
-    <Group id="xccdf_org.gentoo.dev.swift_group_intro-scap">
-      <title>A little more about SCAP and OVAL</title>
-      <description>
-        <h:p>
-        Within SCAP, NIST has defined some new standards of which XCCDF and OVAL
-        are notably important in light of this guide.
-	</h:p>
-        <h:ul>
-          <h:li>
-            XCCDF (Extensible Configuration Checklist Description Format) is
-            a specification language for writing security checklists and benchmarks
-          </h:li>
-          <h:li>
-            OVAL (Open Vulnerability and Assessment Language) is a standard to describe
-            and validate system settings
-          </h:li>
-        </h:ul>
-        <h:p>
-        Thanks to the OVAL and XCCDF standards, a security engineer can now describe
-        how the state of a system should be configured, how this can be checked
-        automatically and even report on these settings. Furthermore, within the
-        description, the engineer can make "profiles" of different states (such as
-        a profile for a workstation, server (generic), webserver, LDAP server,
-        ...) and reusing the states (rules) identified in a more global scope.
-	</h:p>
-      </description>
-    </Group>
-    <Group id="xccdf_org.gentoo.dev.swift_group_intro-using">
-      <title>Using this guide</title>
-      <description>
-        <h:p>
-        This guide is generated from SCAP content (more specifically, the XCCDF document)
-        using <h:b>openscap</h:b>, a free software implementation for handling SCAP content.
-        Within Gentoo, the package <h:code>app-forensics/openscap</h:code> provides the tools,
-        and the following command is used to generate the HTML output:
-	</h:p>
-        <h:pre>
+<status date="@@DATE@@">draft</status>
+<title>Gentoo Security Benchmark</title>
+<description>
+This benchmarks helps people in improving their system configuration to be
+more resilient against attacks and vulnerabilities.
+</description>
+<platform idref="cpe:/o:gentoo:linux"/>
+<version>@@VERSION@@</version>
+<model system="urn:xccdf:scoring:default" />
+<model system="urn:xccdf:scoring:flat" />
+<model system="urn:xccdf:scoring:flat-unweighted" />
+
+<!--
+  Profiles
+-->
+
+<Profile id="xccdf_org.gentoo.dev.swift_profile_intensive" extends="xccdf_org.gentoo.dev.swift_profile_default">
+<title>Intensive validation profile</title>
+<description>
+This profile extends the default server profile by including tests that 
+are more intensive to run on a system. Tests such as full file system
+scans to find world-writable files or directories have an otherwise too
+large impact on the performance of a server. Tests include scripted
+validationn.
+</description>
+<!-- Make sure all world-writable directories have the sticky bit set -->
+<select idref="xccdf_org.gentoo.dev.swift_rule_worldwritedir-stickybit" selected="true" />
+</Profile>
+
+<Profile id="xccdf_org.gentoo.dev.swift_profile_intensive-oval" extends="xccdf_org.gentoo.dev.swift_profile_default-oval">
+<title>Intensive validation profile (non-scripted)</title>
+<description>
+This profile extends the default server profile by including tests that 
+are more intensive to run on a system. Tests such as full file system
+scans to find world-writable files or directories have an otherwise too
+large impact on the performance of a server. Tests do not include
+scripted validation.
+</description>
+<!-- Make sure all world-writable directories have the sticky bit set -->
+<select idref="xccdf_org.gentoo.dev.swift_rule_worldwritedir-stickybit" selected="true" />
+</Profile>
+
+<Profile id="xccdf_org.gentoo.dev.swift_profile_default-oval">
+<title>Default server setup settings (non-scripted)</title>
+<description>
+In this profile, we verify common settings for Gentoo Linux
+configurations. The tests that are enabled in this profile can be ran
+without visibly impacting the performance of the system. No scripted
+checks are executed.
+</description>
+<!-- The /tmp location is a separate file system -->
+<select idref="xccdf_org.gentoo.dev.swift_rule_partition-tmp" selected="true" />
+<!-- The /var location is a separate file system -->
+<select idref="xccdf_org.gentoo.dev.swift_rule_partition-var" selected="true" />
+<!-- The /var/log location is a separate file system -->
+<select idref="xccdf_org.gentoo.dev.swift_rule_partition-varlog" selected="true" />
+<!-- The /var/log/audit location is a separate file system -->
+<select idref="xccdf_org.gentoo.dev.swift_rule_partition-varlogaudit" selected="true" />
+<!-- The /home location is a separate file system -->
+<select idref="xccdf_org.gentoo.dev.swift_rule_partition-home" selected="true" />
+<!-- The /var/tmp location is a separate file system -->
+<select idref="xccdf_org.gentoo.dev.swift_rule_partition-vartmp" selected="true" />
+<!-- The / partition is mounted with nodev -->
+<select idref="xccdf_org.gentoo.dev.swift_rule_partition-root-nodev" selected="true" />
+<!-- The /var partition is mounted with nodev -->
+<select idref="xccdf_org.gentoo.dev.swift_rule_partition-var-nodev" selected="true" />
+<!-- The /var/log partition is mounted with nodev -->
+<select idref="xccdf_org.gentoo.dev.swift_rule_partition-varlog-nodev" selected="true" />
+<!-- The /var/log/audit partition is mounted with nodev -->
+<select idref="xccdf_org.gentoo.dev.swift_rule_partition-varlogaudit-nodev" selected="true" />
+<!-- The /home partition is moounted with nodev -->
+<select idref="xccdf_org.gentoo.dev.swift_rule_partition-home-nodev" selected="true" />
+<!-- The /tmp partition is mounted with nodev -->
+<select idref="xccdf_org.gentoo.dev.swift_rule_partition-tmp-nodev" selected="true" />
+<!-- The /tmp partition is mounted with nosuid -->
+<select idref="xccdf_org.gentoo.dev.swift_rule_partition-tmp-nosuid" selected="true" />
+<!-- The /home partition is mounted with nosuid -->
+<select idref="xccdf_org.gentoo.dev.swift_rule_partition-home-nosuid" selected="true" />
+<!-- The /dev/shm partition is mounted with nosuid -->
+<select idref="xccdf_org.gentoo.dev.swift_rule_partition-devshm-nosuid" selected="true" />
+<!-- The /tmp partition is mounted with noexec -->
+<select idref="xccdf_org.gentoo.dev.swift_rule_partition-tmp-noexec" selected="true" />
+<!-- The /dev/shm partition is mounted with noexec -->
+<select idref="xccdf_org.gentoo.dev.swift_rule_partition-devshm-noexec" selected="true" />
+<!-- Kernel quota support must be enabled -->
+<select idref="xccdf_org.gentoo.dev.swift_rule_kernel-quota" selected="true" />
+<!-- /var is mounted with usrquota or grpquota -->
+<select idref="xccdf_org.gentoo.dev.swift_rule_var-quota" selected="true" />
+<!-- /home is mounted with usrquota or grpquota -->
+<select idref="xccdf_org.gentoo.dev.swift_rule_home-quota" selected="true" />
+<!-- No telnetd process is running -->
+<select idref="xccdf_org.gentoo.dev.swift_rule_telnetd-notrunning" selected="true" />
+<!-- No ftpd process is running -->
+<select idref="xccdf_org.gentoo.dev.swift_rule_ftpd-notrunning" selected="true" />
+<!-- sulogin is used as shell for single user boot (definition /etc/rc.conf) -->
+<select idref="xccdf_org.gentoo.dev.swift_rule_rcconf-sulogin" selected="true" />
+<!-- sulogin is used as shell for single user boot (definition /etc/inittab) -->
+<select idref="xccdf_org.gentoo.dev.swift_rule_inittab-sulogin" selected="true" />
+<!-- Verify that /etc/hosts.allow exists -->
+<select idref="xccdf_org.gentoo.dev.swift_rule_hostsallow-exists" selected="true" />
+<!-- Verify that /etc/at/at.allow exists -->
+<select idref="xccdf_org.gentoo.dev.swift_rule_atallow-exists" selected="true" />
+<!-- Make sure USE=pam is set -->
+<select idref="xccdf_org.gentoo.dev.swift_rule_USE-pam" selected="true" />
+<!-- Make sure USE=tcpd is set -->
+<select idref="xccdf_org.gentoo.dev.swift_rule_USE-tcpd" selected="true" />
+<!-- Make sure USE=ssl is set -->
+<select idref="xccdf_org.gentoo.dev.swift_rule_USE-ssl" selected="true" />
+<!-- Make sure FEATURES=webrsync-gpg is set -->
+<select idref="xccdf_org.gentoo.dev.swift_rule_FEATURES-webrsync-gpg" selected="true" />
+<!-- Make sure PORTAGE_GPG_DIR is set -->
+<select idref="xccdf_org.gentoo.dev.swift_rule_PORTAGE_GPG_DIR-nonempty" selected="true" />
+<!-- Make sure /etc/securetty only contains console and tty's -->
+<select idref="xccdf_org.gentoo.dev.swift_rule_securetty-limitentries" selected="true" />
+<!-- Make sure /proc is mounted with hidepid=1 or hidepid=2 -->
+<select idref="xccdf_org.gentoo.dev.swift_rule_proc-hidepid" selected="true" />
+<!-- Make sure /boot/grub/grub.conf (if it exists) has a password entry with md5 hash -->
+<select idref="xccdf_org.gentoo.dev.swift_rule_grubconf-password-md5" selected="true" />
+<!-- Make sure /etc/lilo.conf (if it exists) has a password entry -->
+<select idref="xccdf_org.gentoo.dev.swift_rule_liloconf-password" selected="true" />
+</Profile>
+
+<Profile id="xccdf_org.gentoo.dev.swift_profile_default" extends="xccdf_org.gentoo.dev.swift_profile_default-oval">
+<title>Default server setup settings</title>
+<description>
+In this profile, common settings for Gentoo Linux configurations are validated. 
+The tests can be ran without visibly impacting the performance of the system, and
+also includes the scripted evaluation checks (SCE).
+</description>
+<!-- The hardened toolchain must be installated and used -->
+<select idref="xccdf_org.gentoo.dev.swift_rule_installation-toolchain-hardened" selected="true" />
+</Profile>
+
+<!--
+  Benchmark instructions
+-->
+
+<!-- INTRODUCTION -->
+
+<Group id="xccdf_org.gentoo.dev.swift_group_intro">
+<title>Introduction</title>
+<description>
+<h:p>
+In the past, Gentoo Linux has had a Gentoo Security Handbook
+which provides a good insight in securing a Gentoo system.
+In order to move this to a next level, we started developing a security
+benchmark using SCAP, or the <h:em>Security Content Automation Protocol</h:em>.
+</h:p>
+<h:p>
+Using the SCAP suite, we not only document the various security rules and hardening
+entries for a Gentoo Linux system, but we also allow the benchmark to be interpreted
+by SCAP compliant tools, which can validate an existing system configuration against
+the rules that are documented in the SCAP document.
+</h:p>
+<h:p>
+This particular benchmark is an update on the security handbook, including both the
+in-depth explanation of settings as well as the means to validate if a system complies
+with this or not. Now, during the development of this benchmark document, not all
+information from the Gentoo Security Handbook is included:
+</h:p>
+<h:ul>
+<h:li>
+Some of the settings are specific to a service that is not default (or extremely popular)
+on a Gentoo Linux system
+</h:li>
+<h:li>
+Some of the settings are particular to a service that is not specific to Gentoo. Such
+settings are best put inside a service-specific benchmark so it is replayable and usable
+by non-Gentoo systems as well.
+</h:li>
+</h:ul>
+<h:p>
+Although these settings are important as well, it is best done in
+separate benchmarks for those services instead. As a result, a number of benchmarks will be
+authored and maintained alongside this one.
+</h:p>
+</description>
+
+<Group id="xccdf_org.gentoo.dev.swift_group_intro-security">
+<title>This is no security policy</title>
+<description>
+<h:p>
+It is <h:em>very important</h:em> to realize that this document is not a
+policy. There is no obligation to follow this to make a secure system
+nor should everything in this document be agreed upon. This document is
+a set of common best practices with the explanation (why is it a best practice)
+and method (how to implement the best practice).
+</h:p>
+<h:p>
+The purpose of this document is to guide readers in their quest to hardening
+their systems.  It will provide pointers that could help in deciding
+particular configuration settings and will do this hopefully using
+sufficient background information to allow readers to make a good choice.
+</h:p>
+<h:p>
+Readers might find settings they don't agree with. That's fine and perfectly
+understandable. Security depends a lot on the environment, use case of the system,
+user base and more. If the same security settings would be applicable to all users,
+then those settings would be made default (or perhaps even hardcoded) a long time ago.
+</h:p>
+</description>
+</Group>
+
+<Group id="xccdf_org.gentoo.dev.swift_group_intro-scap">
+<title>A little more about SCAP and OVAL</title>
+<description>
+<h:p>
+Within SCAP, NIST has defined some new standards of which XCCDF and OVAL
+are notably important in light of this guide.
+</h:p>
+<h:ul>
+<h:li>
+XCCDF (Extensible Configuration Checklist Description Format) is
+a specification language for writing security checklists and benchmarks
+</h:li>
+<h:li>
+OVAL (Open Vulnerability and Assessment Language) is a standard to describe
+and validate system settings
+</h:li>
+</h:ul>
+<h:p>
+Thanks to the OVAL and XCCDF standards, a security engineer can now describe
+how the state of a system should be configured, how this can be checked
+automatically and even report on these settings. Furthermore, within the
+description, the engineer can make "profiles" of different states (such as
+a profile for a workstation, server (generic), webserver, LDAP server,
+...) and reusing the states (rules) identified in a more global scope.
+</h:p>
+</description>
+</Group>
+
+<Group id="xccdf_org.gentoo.dev.swift_group_intro-using">
+<title>Using this guide</title>
+<description>
+<h:p>
+This guide is generated from SCAP content (more specifically, the XCCDF document)
+using <h:b>openscap</h:b>, a free software implementation for handling SCAP content.
+Within Gentoo, the package <h:code>app-forensics/openscap</h:code> provides the tools,
+and the following command is used to generate the HTML output:
+</h:p>
+<h:pre>
 # <h:b>oscap xccdf generate guide gentoo-xccdf.xml &gt; output.html</h:b></h:pre>
-	<h:p>
-        Secondly, together with this XCCDF XML, an OVAL XML file is made available.
-        The two files combined allow OVAL interpreters to automatically validate
-        various settings as documented in the benchmark.
-	</h:p>
-	<h:p>
-	Finally, if certain tests are not available in OVAL yet, scripts are provided
-	that can be executed through the SCE (Script Check Engine) support in openscap.
-	As scripts are not guaranteed to have no impact on the system (or leave traces),
-	<h:code>-oval</h:code> profiles are available that only enable the OVAL (and not SCE)
-	checks.
-	</h:p>
-	<h:p>
-        To validate the tests, the following commands can be used:
-	</h:p>
-        <h:pre>
+<h:p>
+Secondly, together with this XCCDF XML, an OVAL XML file is made available.
+The two files combined allow OVAL interpreters to automatically validate
+various settings as documented in the benchmark.
+</h:p>
+<h:p>
+Finally, if certain tests are not available in OVAL yet, scripts are provided
+that can be executed through the SCE (Script Check Engine) support in openscap.
+As scripts are not guaranteed to have no impact on the system (or leave traces),
+<h:code>-oval</h:code> profiles are available that only enable the OVAL (and not SCE)
+checks.
+</h:p>
+<h:p>
+To validate the tests, the following commands can be used:
+</h:p>
+<h:pre>
 # <h:b>export PROFILE="xccdf_org.gentoo.dev.swift_profile_default"</h:b>
 # <h:b>oscap xccdf eval --profile ${PROFILE} gentoo-xccdf.xml</h:b></h:pre>
-	<h:p>
-        To generate a full report in HTML as well, use the next command:
-	</h:p>
-        <h:pre>
+<h:p>
+To generate a full report in HTML as well, use the next command:
+</h:p>
+<h:pre>
 # <h:b>oscap xccdf eval --profile ${PROFILE} --results xccdf-results.xml \
-  --report report.html gentoo-xccdf.xml</h:b></h:pre>
-	<h:p>
-        Finally, this benchmark will suggest some settings that do not reflect the
-        will of the reader. That is perfectly fine - even more, some settings might even
-        raise eyebrows left and right. This document will explain the reasoning behind
-        the settings but deviations are always possible. If that is the case,
-        disable the rules in the XCCDF document or, better yet, create a new profile
-        and only refer to the tests that are required.
-	</h:p>
-      </description>
-    </Group>
-    <Group id="xccdf_org.gentoo.dev.swift_group_intro-profiles">
-      <title>Available XCCDF Profiles</title>
-      <description>
-        <h:p>
-        As mentioned earlier, the XCCDF document supports multiple profiles. For the time
-        being, two profiles are defined:
-	</h:p>
-        <h:ul>
-          <h:li>
-            The <h:em>default</h:em> profile (xccdf_org.gentoo.dev.swift_profile_default) contains
-            tests that are quick to validate
-          </h:li>
-	  <h:li>
-	    The <h:em>default-oval</h:em> profile (xccdf_org.gentoo.dev.swift_profile_default-oval)
-	    is like the default one, but does not call any other checker than OVAL
-	    (so no scripts).
-	  </h:li>
-          <h:li>
-            The <h:em>intensive</h:em> profile (xccdf_org.gentoo.dev.swift_profile_intensive)
-            contains all tests, including those that take a while (for instance because they
-            perform full file system scans)
-          </h:li>
-	  <h:li>
-	    The <h:em>intensive-oval</h:em> profile (xccdf_org.gentoo.dev.swift_profile_intensive-oval)
-	    is like the intensive one, but does not call any other checker than OVAL
-	    (so no scripts).
-	  </h:li>
-        </h:ul>
-	<h:p>
-        Substitute the profile information in the commands above with the required profile.
-	</h:p>
-      </description>
-    </Group>
-    <Group id="xccdf_org.gentoo.dev.swift_group_intro-weights">
-      <title>About the rule weights</title>
-      <description>
-        <h:p>
-        Within this guide, weights are assigned to tests to give some importance to
-        the rule (higher weight is more important) as well as a severity.
-	</h:p>
-	<h:p>
-        The severity is one of the following:
-	</h:p>
-        <h:ul>
-          <h:li>
-            <h:em>high</h:em> constitutes a grave or critical problem. A rule with this severity
-            <h:em>MUST</h:em> be tackled as it detected a misconfiguration that is easily
-            exploitable and could lead to full system compromise.
-          </h:li>
-          <h:li>
-            <h:em>medium</h:em> reflects a fairly serious problem. A rule with this severity
-            <h:em>SHOULD</h:em> be tackled as it detected a misconfiguration that is easily
-            exploitable.
-          </h:li>
-          <h:li>
-            <h:em>low</h:em> reflects a non-serious problem. A rule with this severity
-            has detected a misconfiguration but its influence on the overall system security
-            is minor (if other compliance rules are followed).
-          </h:li>
-          <h:li>
-            <h:em>info</h:em> reflects an informational rule. Failure to comply with this rule
-            does not mean failure to comply with the document itself.
-          </h:li>
-        </h:ul>
-	<h:p>
-        It is important to understand though that rules with a low severity can still lead to 
-        grave security problems if they are not met. Chaining of vulnerabilities or
-        misconfiguration can still lead to full system compromise.
-	</h:p>
-	<h:p>
-        For this reason, weights are added to rules as well. A higher weight has a more
-        severe potential impact.
-	</h:p>
-	<h:p>
-        Weights are the CVSS (or CCSS) score that is thought to be the case for a misconfiguration.
-        They are calculated by NVD's CVSS calculator. Each rule is scored individually; a 
-        "chain" of misconfigurations might lead to a significantly higher issue, but this would
-        make it very hard to make proper scoring. 
-	</h:p>
-	<h:p>
-        As an example, take the rule that says <h:code>/var</h:code> has to be on its own
-        partition. The metrics we fill in in the calculator are currently based on the risk
-        that the root file system is filled (no more free space), which can halt the system.
-	</h:p>
-        <h:ul>
-          <h:li>
-            The <h:em>related exploit range</h:em> (access vector) is "Local", because this is
-            by itself not exploitable remotely - unless of course certain services are running
-            that can fill up <h:code>/var</h:code>, but such assumptions are not taken.
-          </h:li>
-          <h:li>
-            The <h:em>attack complexity</h:em> (access complexity) is "Low", as all that is
-            needed is a local account and we can find the necessary ways to fill up
-            <h:code>/var</h:code>.
-          </h:li>
-          <h:li>
-            The <h:em>level of authentication needed</h:em> (authentication) is "Single"
-            as the attacker needs one authentication step (local access) to exploit.
-          </h:li>
-          <h:li>
-            The <h:em>confidentiality impact</h:em> is "None" (no data leakage)
-          </h:li>
-          <h:li>
-            The <h:em>integrity impact</h:em> is "None" (no data manipulation)
-          </h:li>
-          <h:li>
-            The <h:em>availability impact</h:em> is "Complete" (system crash or halt).
-          </h:li>
-        </h:ul>
-	<h:p>
-        This results in the CVSS base score of 4.6. The environmental score metrics and
-        temporal score metrics are ignored as those are too specific for environments
-        and organizations.
-	</h:p>
-      </description>
-      <reference href="https://nvd.nist.gov/cvss.cfm?calculator&amp;version=2">NVD CVSS calculator</reference>
-      <reference href="http://csrc.nist.gov/publications/nistir/ir7502/nistir-7502_CCSS.pdf">The Common Configuration Scoring System (PDF)</reference>
-    </Group>
-  </Group>
-  <Group id="xccdf_org.gentoo.dev.swift_group_preinstallation">
-    <title>Before starting</title>
-    <description>
-      Before starting to deploy Gentoo Linux and start hardening it, it is wise
-      to take a step back and think about what to accomplish. Setting
-      up a more secured Gentoo Linux isn't a goal, but a means to reach
-      something. Most likely the system will become a Gentoo Linux powered server.
-      What is this server for? Where will it be hosted? What services are scheduled to run
-      on this operating system? Etc.
-    </description>
-    <Group id="xccdf_org.gentoo.dev.swift_group_preinstallation-architecturing">
-      <title>Infrastructure architecturing</title>
-      <description>
-        <h:p>
-        When considering the entire IT architecture, many architecturing
-        frameworks exist to write down and further design infrastructure.
-        There are very elaborate ones, like TOGAF (The Open Group Architecture
-        Framework), but smaller ones exist as well.
-	</h:p>
-	<h:p>
-        A well written and maintained infrastructure architecture helps to 
-        position new services or consider the impact of changes on existing
-        components.
-	</h:p>
-	<h:p>
-        Security is about reducing risks, not about harassing people or making
-        work for a system administrator harder. And reducing risks also means
-        that a clear eye needs to be kept on the architecture and all its
-        components. If there is no knowledge as to what is being integrated, where
-        it is going to be installed or why, then hardening by itself will probably not
-        do much to the secure state of the system.
-	</h:p>
-      </description>
-    </Group>
-    <Group id="xccdf_org.gentoo.dev.swift_group_preinstallation-requirements">
-      <title>Mapping requirements</title>
-      <description>
-        <h:p>
-        When designing a service, we need to take both functional and
-        non-functional requirements into account. That does sound like
-        overshooting for a simple server installation, but it is not. Is
-        auditing considered? Where should the audit logs be sent to? What
-        about authentication? Centrally managed, or manually set? And the server,
-        will it only host a particular service, or will it provide several services?
-	</h:p>
-	<h:p>
-        When hosting multiple services on the same server, make sure that the
-        server is positioned within the network on an acceptable segment. It is
-        not safe to host central LDAP infrastructure on the same system as
-        a web server that is facing the Internet.
-	</h:p>
-      </description>
-      <reference href="https://www.ibm.com/developerworks/rational/library/4706.html">IBM DeveloperWorks article on "Capturing Architectural Requirements"</reference>
-    </Group>
-    <Group id="xccdf_org.gentoo.dev.swift_group_preinstallation-nonsoftware">
-      <title>Non-software security concerns</title>
-      <description>
-        From the next chapter onwards, the focus will be on the software side
-        hardening. There are of course also non-software concerns that need to be
-        taken care of.
-      </description>
-      <reference href="https://www.rfc-editor.org/info/rfc2196">Site Security Handbook (RFC2196)</reference>
-      <Group id="xccdf_org.gentoo.dev.swift_group_preinstallation-nonsoftware-physical">
-        <title>Physical security</title>
-        <description>
-	  <h:p>
-          Make sure that the system is only accessible (physically) by trusted
-          people. Fully hardening a system, only to have a malicious person
-          take out the harddisk and run away with the confidential data is not
-          something fun to experience.
-	  </h:p>
-	  <h:p>
-          When physical security cannot be guaranteed (like with laptops), make
-          sure that theft of the device only results in the loss of the hardware
-          and not of the data and software on it (take backups!), and also that the
-          data on it cannot be read by unauthorized people.
-	  </h:p>
-        </description>
-        <reference
-        href="http://www.sans.org/reading_room/whitepapers/awareness/data-center-physical-security-checklist_416">Data Center Physical Security Checklist (SANS, PDF)</reference>
-      </Group>
-      <Group id="xccdf_org.gentoo.dev.swift_group_preinstallation-nonsoftware-policies">
-        <title>Policies and contractual agreements</title>
-        <description>
-	  <h:p>
-          Create or validate the security policies in the organization. This is
-          not only as a stick (against internal people who might want to abuse
-          their powers) but also to document and describe why certain decisions
-          are made (both architecturally as otherwise).
-	  </h:p>
-	  <h:p>
-          Make sure that the reasoning for the guidelines is clear. If the policies ever
-          need to be adjusted towards new environments or concepts (like "bring your own
-          device") having the reasons for the (old) guidelines documented will make it much
-          easier to write new ones.
-	  </h:p>
-        </description>
-        <reference
-        href="http://www.sans.org/reading_room/whitepapers/policyissues/technical-writing-security-policies-easy-steps_492">Technical Writing for IT Security Policies in Five Easy Steps (SANS, PDF)</reference>
-        <reference
-        href="https://www.sans.org/security-resources/policies/">Information Security Policy Templates (SANS)</reference>
-      </Group>
-    </Group>
-  </Group>
-  <Group id="xccdf_org.gentoo.dev.swift_group_installation">
-    <title>Installation configuration</title>
-    <description>
-      Gentoo Linux allows us to update various parts of the system after installation,
-      but it might be interesting to consider the following aspects during (or before)
-      installation to not risk a huge migration project later.
-    </description>
-    <Group id="xccdf_org.gentoo.dev.swift_group_installation-storage">
-      <title>Storage configuration</title>
-      <description>
-        Storage is of utmost importance in any environment. It needs to be
-        sufficiently fast (performance), but also secure and
-        manageable while remaining flexible to handle future changes.
-      </description>
-      <Group id="xccdf_org.gentoo.dev.swift_group_installation-storage-partitioning">
-        <title>Partitioning</title>
-        <description>
-          Know which locations in the file system structure need to be on a 
-          different partition or logical volume. Separate locations allow for a
-          more distinct segregation (for instance, no hard links between different
-          file systems) and low-level protection (file system corruption impact,
-          but also putting the right data on the right storage media).
-        </description>
-        <reference href="http://www.pathname.com/fhs/">Filesystem Hierarchy
-        Standard</reference>
-        <Group id="xccdf_org.gentoo.dev.swift_group_installation-storage-partitioning-separate">
-          <title>Separate file systems for important locations</title>
-          <description>
-	    <h:p>
-            Having a separate file system for important locations has several advantages, but
-            those advantages need to be weighted against the disadvantages of separate file
-            systems.
-	    </h:p>
-	    <h:p>
-            These disadvantages are:
-	    </h:p>
-            <h:ul>
-              <h:li>
-                Separate file systems mean that better disk space control is needed
-                (governing free space). A file system that is given too much free space
-                means that disk space is being wasted, but a file system that is not given
-                enough free disk space will need to be grown quickly - if possibile. This
-                also means that creating a proper partitioning setup with many different
-                partitions (file systems) will take some time and calculations; many users
-                have no good idea how much space they need to make available for a file system.
-              </h:li>
-              <h:li>
-                Some file system locations need to be available early in the boot process.
-                If those locations reside on different file systems, special precautions need
-                to be taken to make those file systems available when the system is booted
-                (such as creating an initial ram file system).
-              </h:li>
-            </h:ul>
-	    <h:p>
-            The advantages on the other hand:
-	    </h:p>
-            <h:ul>
-              <h:li>
-                A sudden disk space growth will eventually be stopped by the limits of the
-                file system. If a non-critical file system is full, the impact on the overall
-                system is limited. Without separate file systems, a full file system might 
-                jeopardise the availability of the entire system.
-              </h:li>
-              <h:li>
-                Specific mount options can be enabled on the file systems that improve the
-                security of the file system (permissions) as well as performance. Such mount
-                options include ownership details, allowing (or disallowing) setuid binaries,
-                device files and more.
-              </h:li>
-              <h:li>
-                Different file systems can be hosted on different devices (or even on network
-                shares), allowing administrators to pick the most efficient storage device
-                for a particular file system.
-              </h:li>
-            </h:ul>
-	    <h:p>
-            Considering these pros and cons, it is recommended to have at least the following
-            file system locations to be on a different file system:
-	    </h:p>
-            <h:ul>
-              <h:li>
-                <h:code>/tmp</h:code> as this is a world-writable location and requires
-                specific mount options. When possible, this location can be made a 
-                <h:em>tmpfs</h:em> file system. This is to protect the root file system
-                from being flooded.
-              </h:li>
-              <h:li>
-                <h:code>/var</h:code> as this contains variable data (and thus is prone
-                to grow extensively depending on the installed services). This is to protect
-                the root file system from being flooded.
-              </h:li>
-              <h:li>
-                <h:code>/var/log</h:code> as this contains logging data (and thus is prone
-                to grow extensively depending on the services). This is to protect the 
-                <h:code>/var</h:code> file system from being flooded, as this might impact
-                various services (like databases, web servers, etc.).
-              </h:li>
-              <h:li>
-                <h:code>/var/log/audit</h:code> as this contains (potentially sensitive)
-                logging data. Some services refuse to continue if the audit target location
-                is full. Having the location separate from <h:code>/var/log</h:code> protects
-                the audit file system when <h:code>/var/log</h:code> would be flooded.
-              </h:li>
-              <h:li>
-                <h:code>/home</h:code> as this is completely under the control of end users.
-                It needs to be mounted with more secure settings (more about that later) and
-                should be separate both to protect the root file system, but also to allow
-                the <h:code>/home</h:code> location to be either shared or used elsewhere.
-              </h:li>
-              <h:li>
-                <h:code>/var/tmp</h:code> which is a "second" <h:code>/tmp</h:code> location,
-                but where the content is preserved after a reboot. Still, it is world-writable
-                and requires specific mount options, and should be on a different file system
-                to prevent <h:code>/var</h:code> to be flooded which might impact the
-                availability of services.
-              </h:li>
-            </h:ul>
-          </description>
-          <Rule id="xccdf_org.gentoo.dev.swift_rule_partition-tmp" selected="false" severity="medium" weight="4.6">
-            <title>/tmp is a separate file system</title>
-            <fixtext>
-              Create a file system for <h:code>/tmp</h:code>; make sure it is added in
-              the <h:code>/etc/fstab</h:code> file and reboot the system.
-            </fixtext>
-            <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
-              <check-content-ref name="oval:org.gentoo.dev.swift:def:5" href="gentoo-oval.xml" />
-            </check>
-          </Rule>
-          <Rule id="xccdf_org.gentoo.dev.swift_rule_partition-var" selected="false" severity="medium" weight="4.6">
-            <title>/var is a separate file system</title>
-            <fixtext>
-              Create a file system for <h:code>/var</h:code>; make sure it is added in
-              the <h:code>/etc/fstab</h:code> file and reboot the system.
-            </fixtext>
-            <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
-              <check-content-ref name="oval:org.gentoo.dev.swift:def:6" href="gentoo-oval.xml" />
-            </check>
-          </Rule>
-          <Rule id="xccdf_org.gentoo.dev.swift_rule_partition-varlog" selected="false" severity="low" weight="2.1">
-            <title>/var/log is a separate file system</title>
-            <fixtext>
-              Create a file system for <h:code>/var/log</h:code>; make sure it is added in
-              the <h:code>/etc/fstab</h:code> file and reboot the system.
-            </fixtext>
-            <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
-              <check-content-ref name="oval:org.gentoo.dev.swift:def:7" href="gentoo-oval.xml" />
-            </check>
-          </Rule>
-          <Rule id="xccdf_org.gentoo.dev.swift_rule_partition-varlogaudit" selected="false" severity="low" weight="2.1">
-            <title>/var/log/audit is a separate file system</title>
-            <fixtext>
-              Create a file system for <h:code>/var/log/audit</h:code>; make sure it is added in
-              the <h:code>/etc/fstab</h:code> file and reboot the system.
-            </fixtext>
-            <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
-              <check-content-ref name="oval:org.gentoo.dev.swift:def:8" href="gentoo-oval.xml" />
-            </check>
-          </Rule>
-          <Rule id="xccdf_org.gentoo.dev.swift_rule_partition-home" selected="false" severity="medium" weight="4.6">
-            <title>/home is a separate file system</title>
-            <fixtext>
-              Create a file system for <h:code>/home</h:code>; make sure it is added in
-              the <h:code>/etc/fstab</h:code> file and reboot the system.
-            </fixtext>
-            <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
-              <check-content-ref name="oval:org.gentoo.dev.swift:def:2" href="gentoo-oval.xml" />
-            </check>
-          </Rule>
-          <Rule id="xccdf_org.gentoo.dev.swift_rule_partition-vartmp" selected="false" severity="low" weight="2.1">
-            <title>/var/tmp is a separate file system</title>
-            <fixtext>
-              Create a file system for <h:code>/var/tmp</h:code>; make sure it is added in
-              the <h:code>/etc/fstab</h:code> file and reboot the system.
-            </fixtext>
-            <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
-              <check-content-ref name="oval:org.gentoo.dev.swift:def:17" href="gentoo-oval.xml" />
-            </check>
-          </Rule>
-        </Group>
-      </Group>
-    </Group>
-    <Group id="xccdf_org.gentoo.dev.swift_group_installation-toolchain">
-      <title>Use a Hardened Toolchain</title>
-      <description>
-        <h:p>
-        When Gentoo is installed, use the hardened stages and hardened toolchain.
-        The hardened toolchain includes additional security patches, such as
-        support for non-executable program stacks and buffer overflow detection.
-	</h:p>
-        <h:ul>
-          <h:li>
-            <h:em>Position Independent Executables (PIE)</h:em> and <h:em>Position Independent
-            Code (PIC)</h:em> implements a memory hardening approach where the application
-            (or library), when loaded to memory, does not have hard requirements where in
-            memory it is loaded. Together with ASLR this makes it more difficult for exploits
-            to know at which memory region certain data will be available.
-          </h:li>
-          <h:li>
-            <h:em>Stack Smashing Protection (SSP)</h:em> adds markers outside buffer areas
-            to detect buffer overflow attacks, killing the application rather than effectively
-            having the overflow succeed.
-          </h:li>
-        </h:ul>
-	<h:p>
-        During installation, make sure that the <h:em>default</h:em> hardened
-        toolchain is selected, not one of the <h:code>-hardenedno*</h:code> as
-        those are toolchains where specific settings are disabled. The
-        <h:code>-vanilla</h:code> one is a toolchain with no hardened patches.
-	</h:p>
-        <h:pre>
-# <h:b>gcc-config -l</h:b>
- [1] x86_64-pc-linux-gnu-4.4.5 *
- [2] x86_64-pc-linux-gnu-4.4.5-hardenednopie
- [3] x86_64-pc-linux-gnu-4.4.5-hardenednopie.gcc-config-ref
- [4] x86_64-pc-linux-gnu-4.4.5-hardenednopiessp
- [5] x86_64-pc-linux-gnu-4.4.5-hardenednossp
- [6] x86_64-pc-linux-gnu-4.4.5-vanilla</h:pre>
-      </description>
-      <Rule id="xccdf_org.gentoo.dev.swift_rule_installation-toolchain-hardened" selected="false" severity="low" weight="0.0">
-        <title>The hardened toolchain is used</title>
-        <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_installation-toolchain-hardened">
-          Use a hardened Gentoo profile and select the default compiler (not vanilla
-          nor any of the hardenedno* ones).
-        </fixtext>
-        <check system="http://open-scap.org/page/SCE">
-          <check-import import-name="stdout" />
-          <check-content-ref href="bin/gentoo-sce_installation-toolchain-hardened.sh" />
-        </check>
-      </Rule>
-    </Group> <!-- installation-toolchain -->
-  </Group> <!-- installation -->
-  <Group id="xccdf_org.gentoo.dev.swift_group_system">
-    <title>System settings</title>
-    <description>
-      Within this chapter, the (recommended) settings that can be adjusted relatively easily
-      are presented, even when a Gentoo installation has already been performed. This is the
-      bulk of the security settings.
-    </description>
-    <Group id="xccdf_org.gentoo.dev.swift_group_system-fs">
-      <title>File system related settings</title>
-      <description>
-        Servers and systems are about manipulating data. In this chapter, the security settings
-        for file systems are explained.
-      </description>
-      <Group id="xccdf_org.gentoo.dev.swift_group_system-fs-mountoptions">
-        <title>Using no* mount options for the file systems</title>
-        <description>
-	  <h:p>
-          Non-root file systems should be mounted with the <h:em>nodev</h:em> mount option.
-          This mount option ensures that device files are not allowed on these file systems
-          (and if they are there, they are ignored by the Linux kernel for any device
-          operation).
-	  </h:p>
-	  <h:p>
-          Having device files on non-root file systems could allow unauthorized people access
-          to sensitive data (for instance when having a readable raw disk device files) or
-          even manipulate the system.
-	  </h:p>
-	  <h:p>
-          The privilege to create special device files (beyond regular sockets) such as
-          character and block device files is handled through the CAP_MKNOD capability
-          which is not granted to regular users. As such, the risk is when more privileged
-          users or processes are tricked to create such device files.
-	  </h:p>
-	  <h:p>
-          This setting is appropriate for file systems such as (non-exhaustive list):
-	  </h:p>
-          <h:ul>
-            <h:li>
-              <h:code>/var</h:code> (as it is recommended to be a separate file system)
-            </h:li>
-            <h:li>
-              <h:code>/var/log</h:code> (as it is recommended to be a separate file system)
-            </h:li>
-            <h:li>
-              <h:code>/var/log/audit</h:code> (as it is recommended to be a separate file system)
-            </h:li>
-            <h:li>
-              <h:code>/home</h:code> (as it is recommended to be a separate file system)
-            </h:li>
-            <h:li>
-              <h:code>/tmp</h:code> (as it is recommended to be a separate file system)
-            </h:li>
-          </h:ul>
-	  <h:p>
-          Specific file systems should also be mounted with the <h:em>nosuid</h:em> mount
-          option. This prevents setuid binaries to run as a different user when hosted
-          on this file system. As there are several locations where setuid binaries might
-          be needed, this only affects particular file systems:
-	  </h:p>
-          <h:ul>
-            <h:li>
-              The <h:code>/tmp</h:code> file system should not be used for setuid binaries
-              as this is a world-writable location and often target storage for attacks.
-            </h:li>
-            <h:li>
-              The <h:code>/home</h:code> file system should not be used for setuid binaries
-              as this is the home location for non-root users.
-            </h:li>
-            <h:li>
-              The <h:code>/dev/shm</h:code> file system should not be used for any binaries
-              (shared memory region).
-            </h:li>
-          </h:ul>
-	  <h:p>
-          Specific file systems should also be mounted with the <h:em>noexec</h:em> mount
-          option. This prevents some automated attacks to execute certain payload (exploits)
-          from these locations.
-	  </h:p>
-	  <h:p>
-          This is just one of the many "layers" though, as executing payload can still be
-          done using different methods. For instance, scripts can be invoked through the
-          shell itself (rather than directly) and in the past, binaries could even be
-          executed through the <h:code>ld-linux.so</h:code> binary (although this has
-          been fixed).
-	  </h:p>
-	  <h:p>
-          File systems for which <h:em>noexec</h:em> is recommended are:
-	  </h:p>
-          <h:ul>
-            <h:li>
-              The <h:code>/tmp</h:code> file system as it is a popular target to store exploit
-              code in.
-            </h:li>
-            <h:li>
-              The <h:code>/dev/shm</h:code> file system as it is meant as a shared memory
-              location and is becoming a popular target to store exploit code in.
-            </h:li>
-          </h:ul>
-        </description>
-        <!-- CVSS2 AV:L/Au:M/C:C/I:C/A:C (high complexity as device node needs
-             to be created first and is then only exploitable after local access.
-             Multiple authentication (one to create device file, one to log on)
-        -->
-        <Rule id="xccdf_org.gentoo.dev.swift_rule_partition-var-nodev" selected="false" severity="low" weight="5.9">
-          <title>/var is mounted with nodev</title>
-          <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_partition-var-nodev">Mount /var with nodev mount option</fixtext>
-          <fix id="xccdf_org.gentoo.dev.swift_fix_partition-var-nodev"
-            system="urn:xccdf:fix:system:commands"
-            platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false">
+--report report.html gentoo-xccdf.xml</h:b></h:pre>
+</description>
+</Group>
+
+<Group id="xccdf_org.gentoo.dev.swift_group_intro-profiles">
+<title>Available XCCDF Profiles</title>
+<description>
+<h:p>
+As mentioned earlier, this XCCDF document supports multiple profiles. For the time
+being, two profiles are defined:
+</h:p>
+<h:ul>
+<h:li>
+The <h:em>default</h:em> profile (xccdf_org.gentoo.dev.swift_profile_default) contains
+tests that are quick to validate
+</h:li>
+<h:li>
+The <h:em>default-oval</h:em> profile (xccdf_org.gentoo.dev.swift_profile_default-oval)
+is like the default one, but does not call any other checker than OVAL
+(so no scripts).
+</h:li>
+<h:li>
+The <h:em>intensive</h:em> profile (xccdf_org.gentoo.dev.swift_profile_intensive)
+contains all tests, including those that take a while (for instance because they
+perform full file system scans)
+</h:li>
+<h:li>
+The <h:em>intensive-oval</h:em> profile (xccdf_org.gentoo.dev.swift_profile_intensive-oval)
+is like the intensive one, but does not call any other checker than OVAL
+(so no scripts).
+</h:li>
+</h:ul>
+<h:p>
+Substitute the profile information in the commands above with the required profile.
+</h:p>
+</description>
+</Group>
+
+<Group id="xccdf_org.gentoo.dev.swift_group_intro-weights">
+<title>About the rule weights</title>
+<description>
+<h:p>
+Within this guide, weights are assigned to tests to give some importance to
+the rule (higher weight is more important) as well as a severity.
+</h:p>
+<h:p>
+The severity is one of the following:
+</h:p>
+<h:ul>
+<h:li>
+<h:em>high</h:em> constitutes a grave or critical problem. A rule with this severity
+<h:em>MUST</h:em> be tackled as it detected a misconfiguration that is easily
+exploitable and could lead to full system compromise.
+</h:li>
+<h:li>
+<h:em>medium</h:em> reflects a fairly serious problem. A rule with this severity
+<h:em>SHOULD</h:em> be tackled as it detected a misconfiguration that is easily
+exploitable.
+</h:li>
+<h:li>
+<h:em>low</h:em> reflects a non-serious problem. A rule with this severity
+has detected a misconfiguration but its influence on the overall system security
+is minor (if other compliance rules are followed).
+</h:li>
+<h:li>
+<h:em>info</h:em> reflects an informational rule. Failure to comply with this rule
+does not mean failure to comply with the document itself.
+</h:li>
+</h:ul>
+<h:p>
+It is important to understand though that rules with a low severity can still lead to 
+grave security problems if they are not met. Chaining of vulnerabilities or
+misconfiguration can still lead to full system compromise.
+</h:p>
+<h:p>
+For this reason, weights are added to rules as well. A higher weight has a more
+severe potential impact.
+</h:p>
+<h:p>
+Weights are the CVSS (or CCSS) score that is thought to be the case for a misconfiguration.
+They are calculated by NVD's CVSS calculator. Each rule is scored individually; a 
+"chain" of misconfigurations might lead to a significantly higher issue, but this would
+make it very hard to make proper scoring. 
+</h:p>
+<h:p>
+As an example, take the rule that says <h:code>/var</h:code> has to be on its own
+partition. The metrics we fill in in the calculator are currently based on the risk
+that the root file system is filled (no more free space), which can halt the system.
+</h:p>
+<h:ul>
+<h:li>
+The <h:em>related exploit range</h:em> (access vector) is "Local", because this is
+by itself not exploitable remotely - unless of course certain services are running
+that can fill up <h:code>/var</h:code>, but such assumptions are not taken.
+</h:li>
+<h:li>
+The <h:em>attack complexity</h:em> (access complexity) is "Low", as all that is
+needed is a local account and we can find the necessary ways to fill up
+<h:code>/var</h:code>.
+</h:li>
+<h:li>
+The <h:em>level of authentication needed</h:em> (authentication) is "Single"
+as the attacker needs one authentication step (local access) to exploit.
+</h:li>
+<h:li>
+The <h:em>confidentiality impact</h:em> is "None" (no data leakage)
+</h:li>
+<h:li>
+The <h:em>integrity impact</h:em> is "None" (no data manipulation)
+</h:li>
+<h:li>
+The <h:em>availability impact</h:em> is "Complete" (system crash or halt).
+</h:li>
+</h:ul>
+<h:p>
+This results in the CVSS base score of 4.6. The environmental score metrics and
+temporal score metrics are ignored as those are too specific for environments
+and organizations.
+</h:p>
+</description>
+<reference href="https://nvd.nist.gov/cvss.cfm?calculator&amp;version=2">NVD CVSS calculator</reference>
+<reference href="http://csrc.nist.gov/publications/nistir/ir7502/nistir-7502_CCSS.pdf">The Common Configuration Scoring System (PDF)</reference>
+</Group>
+
+<Group id="xccdf_org.gentoo.dev.swift_group_intro-resources">
+<title>Additional resources</title>
+<description>
+From the next chapter onwards, the focus will be on the software side
+hardening. For more information about other related security areas, please take a look
+at the following resources.
+</description>
+<reference href="https://www.rfc-editor.org/info/rfc2196">Site Security Handbook (RFC2196)</reference>
+<reference href="http://www.sans.org/reading_room/whitepapers/awareness/data-center-physical-security-checklist_416">Data Center Physical Security Checklist (SANS, PDF)</reference>
+<reference href="http://www.sans.org/reading_room/whitepapers/policyissues/technical-writing-security-policies-easy-steps_492">Technical Writing for IT Security Policies in Five Easy Steps (SANS, PDF)</reference>
+<reference href="https://www.sans.org/security-resources/policies/">Information Security Policy Templates (SANS)</reference>
+</Group>
+</Group>
+
+<!-- INSTALLATION -->
+
+<Group id="xccdf_org.gentoo.dev.swift_group_installation">
+<title>Installation related settings</title>
+<description>
+<h:p>
+Gentoo Linux allows us to update various parts of the system after installation,
+but it might be interesting to consider some aspects during (or before)
+installation as it might require a huge migration afterwards.
+</h:p>
+<h:p>
+The Gentoo Linux installation is structured as follows:
+</h:p>
+<h:ol>
+<h:li>The disks, partitions or other storage is prepared to host the Gentoo Linux OS</h:li>
+<h:li>The base Gentoo installation (a minimal install called a "stage3") is extracted on the system</h:li>
+<h:li>Boot-critical configuration entries, such as file system information and Portage configuration are set up</h:li>
+<h:li>A Linux kernel is compiled and installed, together with a boot loader</h:li>
+<h:li>Basic accounts are created to allow a log on to the system after boot</h:li>
+</h:ol>
+<h:p>
+In the following sections, the best practices for a secure system are described related to these installation specific entries.
+</h:p>
+</description>
+<reference href="https://wiki.gentoo.org/wiki/Handbook:Main_Page">Gentoo Linux Handbook</reference>
+
+<Group id="xccdf_org.gentoo.dev.swift_group_installation-hardware">
+<title>Hardware selection</title>
+<description>
+<h:p>
+TODO
+</h:p>
+</description>
+
+<Group id="xccdf_org.gentoo.dev.swift_group_installation-hardware-tpm">
+<title>Trusted Platform Module</title>
+<description>
+<h:p>
+TODO
+</h:p>
+</description>
+</Group>
+
+</Group>
+
+<Group id="xccdf_org.gentoo.dev.swift_group_installation-storage">
+<title>Storage and file systems</title>
+<description>
+<h:p>
+Storage devices, and the file systems on them, are one of the basic parts of any operating system.
+The file systems provide not only structured access to the data, but also metadata about the files
+and directories, including access control related information.
+</h:p>
+<h:p>
+When securing a system, we need to look at: 
+</h:p>
+<h:ul>
+<h:li>Partition and file system structure</h:li>
+<h:li>File system tuning</h:li>
+</h:ul>
+<h:p>
+The file system structure (or partition layout as it is also often called) is a very important
+step in the design of any operating system deployment. Within Gentoo Linux' Handbook, an entire
+chapter is written just on this particular matter. The structure needs to support the purpose of
+the system.
+</h:p>
+<h:p>
+For instance, for a database server, the file system on which the database files are stored is
+usually separate from the operating system file system, and often even has its dedicated back
+end storage (different disks) in order to be sufficiently high performing. The location of the
+log files (and audit logs) is separate from operating system and database files so that an overflow
+in the logs does not harm the database itself or the operating system.
+</h:p>
+<h:p>
+And database servers are just one example. LDAP servers, mail servers, shell servers, workstations,
+... all have their own specific file system structure and best practices.
+</h:p>
+</description>
+<reference href="http://www.pathname.com/fhs/">Filesystem Hierarchy Standard</reference>
+
+<Group id="xccdf_org.gentoo.dev.swift_group_installation-storage-separatepartitions">
+<title>Separate file systems for important locations</title>
+<description>
+<h:p>
+Separate file systems for important locations is an important basic security measure, but it does have
+its consequences. Depending on the purpose of the system and the financial freedom while designing the
+server structure, some concessions might need to be made.
+</h:p>
+<h:p>
+The main disadvantages of a separate file system for a location are:
+</h:p>
+<h:ul>
+<h:li>
+Separate file systems mean that better disk space control is needed
+(governing free space). A file system that is given too much free space
+means that disk space is being wasted, but a file system that is not given
+enough free disk space will need to be grown quickly - if possibile. This
+also means that creating a proper partitioning setup with many different
+partitions (file systems) will take some time and calculations; many users
+have no good idea how much space they need to make available for a file system.
+</h:li>
+<h:li>
+Some file system locations need to be available early in the boot process.
+If those locations reside on different file systems, special precautions need
+to be taken to make those file systems available when the system is booted
+(such as creating an initial ram file system).
+</h:li>
+</h:ul>
+<h:p>
+The advantages on the other hand:
+</h:p>
+<h:ul>
+<h:li>
+A sudden disk space growth will eventually be stopped by the limits of the
+file system. If a non-critical file system is full, the impact on the overall
+system is limited. Without separate file systems, a full file system might 
+jeopardise the availability of the entire system.
+</h:li>
+<h:li>
+Specific mount options can be enabled on the file systems that improve the
+security of the file system (permissions) as well as performance. Such mount
+options include ownership details, allowing (or disallowing) setuid binaries,
+device files and more.
+</h:li>
+<h:li>
+Different file systems can be hosted on different devices (or even on network
+shares), allowing administrators to pick the most efficient storage device
+for a particular file system.
+</h:li>
+</h:ul>
+<h:p>
+Considering these pros and cons, it is recommended to have at least the following
+file system locations be on a different file system:
+</h:p>
+<h:ul>
+<h:li>
+<h:code>/tmp</h:code> as this is a world-writable location and requires
+specific mount options. When possible, this location can be made a 
+<h:em>tmpfs</h:em> file system. This is to protect the root file system
+from being flooded.
+</h:li>
+<h:li>
+<h:code>/var</h:code> as this contains variable data (and thus is prone
+to grow extensively depending on the installed services). This is to protect
+the root file system from being flooded.
+</h:li>
+<h:li>
+<h:code>/var/log</h:code> as this contains logging data (and thus is prone
+to grow extensively depending on the services). This is to protect the 
+<h:code>/var</h:code> file system from being flooded, as this might impact
+various services (like databases, web servers, etc.).
+</h:li>
+<h:li>
+<h:code>/var/log/audit</h:code> as this contains (potentially sensitive)
+logging data. Some services refuse to continue if the audit target location
+is full. Having the location separate from <h:code>/var/log</h:code> protects
+the audit file system when <h:code>/var/log</h:code> would be flooded.
+</h:li>
+<h:li>
+<h:code>/home</h:code> as this is completely under the control of end users.
+It needs to be mounted with more secure settings (more about that later) and
+should be separate both to protect the root file system, but also to allow
+the <h:code>/home</h:code> location to be either shared or used elsewhere.
+</h:li>
+<h:li>
+<h:code>/var/tmp</h:code> which is a "second" <h:code>/tmp</h:code> location,
+but where the content is preserved after a reboot. Still, it is world-writable
+and requires specific mount options, and should be on a different file system
+to prevent <h:code>/var</h:code> to be flooded which might impact the
+availability of services.
+</h:li>
+</h:ul>
+</description>
+
+<Rule id="xccdf_org.gentoo.dev.swift_rule_partition-tmp" selected="false" severity="medium" weight="4.6">
+<title>/tmp is a separate file system</title>
+<fixtext>
+Create a file system for <h:code>/tmp</h:code>; make sure it is added in
+the <h:code>/etc/fstab</h:code> file and reboot the system.
+</fixtext>
+<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
+<check-content-ref name="oval:org.gentoo.dev.swift:def:5" href="gentoo-oval.xml" />
+</check>
+</Rule>
+
+<Rule id="xccdf_org.gentoo.dev.swift_rule_partition-var" selected="false" severity="medium" weight="4.6">
+<title>/var is a separate file system</title>
+<fixtext>
+Create a file system for <h:code>/var</h:code>; make sure it is added in
+the <h:code>/etc/fstab</h:code> file and reboot the system.
+</fixtext>
+<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
+<check-content-ref name="oval:org.gentoo.dev.swift:def:6" href="gentoo-oval.xml" />
+</check>
+</Rule>
+
+<Rule id="xccdf_org.gentoo.dev.swift_rule_partition-varlog" selected="false" severity="low" weight="2.1">
+<title>/var/log is a separate file system</title>
+<fixtext>
+Create a file system for <h:code>/var/log</h:code>; make sure it is added in
+the <h:code>/etc/fstab</h:code> file and reboot the system.
+</fixtext>
+<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
+<check-content-ref name="oval:org.gentoo.dev.swift:def:7" href="gentoo-oval.xml" />
+</check>
+</Rule>
+
+<Rule id="xccdf_org.gentoo.dev.swift_rule_partition-varlogaudit" selected="false" severity="low" weight="2.1">
+<title>/var/log/audit is a separate file system</title>
+<fixtext>
+Create a file system for <h:code>/var/log/audit</h:code>; make sure it is added in
+the <h:code>/etc/fstab</h:code> file and reboot the system.
+</fixtext>
+<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
+<check-content-ref name="oval:org.gentoo.dev.swift:def:8" href="gentoo-oval.xml" />
+</check>
+</Rule>
+
+<Rule id="xccdf_org.gentoo.dev.swift_rule_partition-home" selected="false" severity="medium" weight="4.6">
+<title>/home is a separate file system</title>
+<fixtext>
+Create a file system for <h:code>/home</h:code>; make sure it is added in
+the <h:code>/etc/fstab</h:code> file and reboot the system.
+</fixtext>
+<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
+<check-content-ref name="oval:org.gentoo.dev.swift:def:2" href="gentoo-oval.xml" />
+</check>
+</Rule>
+
+<Rule id="xccdf_org.gentoo.dev.swift_rule_partition-vartmp" selected="false" severity="low" weight="2.1">
+<title>/var/tmp is a separate file system</title>
+<fixtext>
+Create a file system for <h:code>/var/tmp</h:code>; make sure it is added in
+the <h:code>/etc/fstab</h:code> file and reboot the system.
+</fixtext>
+<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
+<check-content-ref name="oval:org.gentoo.dev.swift:def:17" href="gentoo-oval.xml" />
+</check>
+</Rule>
+</Group>
+
+<Group id="xccdf_org.gentoo.dev.swift_group_installation-storage-mountoptions">
+<title>File system mount options</title>
+<description>
+<h:p>
+There are a number of mount options which can improve system security significantly.
+</h:p>
+<!-- nodev -->
+<h:p>
+A first important setting is the <h:tt>nodev</h:tt> mount option.
+This mount option ensures that device files are not allowed on these file systems
+(and if they are there, they are ignored by the Linux kernel for any device
+operation). Having device files on the wrong file systems could allow unauthorized
+people access to sensitive data (for instance when having a readable raw disk device
+files) or even manipulate the system.
+</h:p>
+<h:p>
+The privilege to create special device files (beyond regular sockets) such as
+character and block device files is handled through the CAP_MKNOD capability
+which is not granted to regular users. As such, the risk is when more privileged
+users or processes are tricked into creating such device files, or by having different
+locations with device files accessible (such as removable media).
+</h:p>
+<h:p>
+Given that, on Gentoo Linux, device files are situated inside a <h:em>devtmpfs</h:em>
+file system, most mount points can be configured with the <h:tt>nodev</h:tt> mount
+option.
+</h:p>
+<h:ul>
+<h:li>
+<h:code>/</h:code> (as the root file system)
+</h:li>
+<h:li>
+<h:code>/var</h:code> (as it is recommended to be a separate file system)
+</h:li>
+<h:li>
+<h:code>/var/log</h:code> (as it is recommended to be a separate file system)
+</h:li>
+<h:li>
+<h:code>/var/log/audit</h:code> (as it is recommended to be a separate file system)
+</h:li>
+<h:li>
+<h:code>/home</h:code> (as it is recommended to be a separate file system)
+</h:li>
+<h:li>
+<h:code>/tmp</h:code> (as it is recommended to be a separate file system)
+</h:li>
+</h:ul>
+<!-- nosuid -->
+<h:p>
+A second important mount option is the <h:tt>nosuid</h:tt> one. This prevents setuid binaries
+to effectively run as a different user when hosted on this file system. In other words, it is as
+if there is no setuid bit set on these binaries. When SELinux is enabled, this will also prevent any
+domain transition for executables on this file system. When using capabilities, the <h:tt>nosuid</h:tt>
+option also influences the <h:tt>CAP_SETUID</h:tt> and <h:tt>CAP_SETGID</h:tt> capabilities.
+</h:p>
+<h:p>
+As there are several locations where setuid binaries (or related capabilities) might be needed
+(or where SELinux domain transitions are still wanted), this is only recommended for a specific
+set of file systems:
+</h:p>
+<h:ul>
+<h:li>
+The <h:code>/tmp</h:code> file system should not be used for setuid binaries
+as this is a world-writable location and often target storage for attacks.
+</h:li>
+<h:li>
+The <h:code>/home</h:code> file system should not be used for setuid binaries
+as this is the home location for non-root users.
+</h:li>
+<h:li>
+The <h:code>/dev/shm</h:code> file system should not be used for any binaries
+(shared memory region).
+</h:li>
+</h:ul>
+<!-- noexec -->
+<h:p>
+Specific file systems should also be mounted with the <h:tt>noexec</h:tt> mount
+option. This prevents some automated attacks to execute certain payload (exploits)
+from these locations.
+</h:p>
+<h:p>
+This is just one of the many "layers" though, as executing payload can still be
+done using different methods. For instance, scripts can be invoked through the
+shell itself (rather than directly) and in the past, binaries could even be
+executed through the <h:code>ld-linux.so</h:code> binary (although this has
+been fixed).
+</h:p>
+<h:p>
+File systems for which <h:tt>noexec</h:tt> is recommended are:
+</h:p>
+<h:ul>
+<h:li>
+The <h:code>/tmp</h:code> file system as it is a popular target to store exploit
+code in.
+</h:li>
+<h:li>
+The <h:code>/dev/shm</h:code> file system as it is meant as a shared memory
+location and is becoming a popular target to store exploit code in.
+</h:li>
+</h:ul>
+</description>
+<warning>
+This section uses mount options as the means to configure the mount points. However, mount options are not the
+only way of tuning these settings - many file systems support the same through commands such as <h:tt>tune2fs</h:tt>.
+</warning>
+
+<!-- CVSS2 AV:L/Au:M/C:C/I:C/A:C (high complexity as device node needs
+to be created first and is then only exploitable after local access.
+Multiple authentication (one to create device file, one to log on)
+-->
+<Rule id="xccdf_org.gentoo.dev.swift_rule_partition-root-nodev" selected="false" severity="low" weight="5.9">
+<title>/ is mounted with nodev</title>
+<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_partition-root-nodev">Mount / with nodev mount option</fixtext>
+<fix id="xccdf_org.gentoo.dev.swift_fix_partition-root-nodev"
+system="urn:xccdf:fix:system:commands"
+platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false">
+mount -o remount,nodev /
+</fix>
+<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
+<check-content-ref name="oval:org.gentoo.dev.swift:def:37" href="gentoo-oval.xml" />
+</check>
+</Rule>
+
+<Rule id="xccdf_org.gentoo.dev.swift_rule_partition-var-nodev" selected="false" severity="low" weight="5.9">
+<title>/var is mounted with nodev</title>
+<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_partition-var-nodev">Mount /var with nodev mount option</fixtext>
+<fix id="xccdf_org.gentoo.dev.swift_fix_partition-var-nodev"
+system="urn:xccdf:fix:system:commands"
+platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false">
 mount -o remount,nodev /var
-          </fix>
-          <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
-            <check-content-ref name="oval:org.gentoo.dev.swift:def:9" href="gentoo-oval.xml" />
-          </check>
-        </Rule>
-        <Rule id="xccdf_org.gentoo.dev.swift_rule_partition-varlog-nodev" selected="false" severity="low" weight="5.9">
-          <title>/var/log is mounted with nodev</title>
-          <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_partition-varlog-nodev">Mount /var/log with nodev mount option</fixtext>
-          <fix id="xccdf_org.gentoo.dev.swift_fix_partition-varlog-nodev"
-            system="urn:xccdf:fix:system:commands"
-            platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false">
+</fix>
+<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
+<check-content-ref name="oval:org.gentoo.dev.swift:def:9" href="gentoo-oval.xml" />
+</check>
+</Rule>
+
+<Rule id="xccdf_org.gentoo.dev.swift_rule_partition-varlog-nodev" selected="false" severity="low" weight="5.9">
+<title>/var/log is mounted with nodev</title>
+<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_partition-varlog-nodev">Mount /var/log with nodev mount option</fixtext>
+<fix id="xccdf_org.gentoo.dev.swift_fix_partition-varlog-nodev"
+system="urn:xccdf:fix:system:commands"
+platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false">
 mount -o remount,nodev /var/log
-          </fix>
-          <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
-            <check-content-ref name="oval:org.gentoo.dev.swift:def:10" href="gentoo-oval.xml" />
-          </check>
-        </Rule>
-        <Rule id="xccdf_org.gentoo.dev.swift_rule_partition-varlogaudit-nodev" selected="false" severity="low" weight="5.9">
-          <title>/var/log/audit is mounted with nodev</title>
-          <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_partition-varlogaudit-nodev">Mount /var/log/audit with nodev mount option</fixtext>
-          <fix id="xccdf_org.gentoo.dev.swift_fix_partition-varlogaudit-nodev"
-            system="urn:xccdf:fix:system:commands"
-            platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false">
+</fix>
+<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
+<check-content-ref name="oval:org.gentoo.dev.swift:def:10" href="gentoo-oval.xml" />
+</check>
+</Rule>
+
+<Rule id="xccdf_org.gentoo.dev.swift_rule_partition-varlogaudit-nodev" selected="false" severity="low" weight="5.9">
+<title>/var/log/audit is mounted with nodev</title>
+<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_partition-varlogaudit-nodev">Mount /var/log/audit with nodev mount option</fixtext>
+<fix id="xccdf_org.gentoo.dev.swift_fix_partition-varlogaudit-nodev"
+system="urn:xccdf:fix:system:commands"
+platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false">
 mount -o remount,nodev /var/log/audit
-          </fix>
-          <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
-            <check-content-ref name="oval:org.gentoo.dev.swift:def:11" href="gentoo-oval.xml" />
-          </check>
-        </Rule>
-        <Rule id="xccdf_org.gentoo.dev.swift_rule_partition-home-nodev" selected="false" severity="low" weight="5.9">
-          <title>/home is mounted with nodev</title>
-          <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_partition-home-nodev">Mount /home with nodev mount option</fixtext>
-          <fix id="xccdf_org.gentoo.dev.swift_fix_partition-home-nodev"
-            system="urn:xccdf:fix:system:commands"
-            platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false">
+</fix>
+<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
+<check-content-ref name="oval:org.gentoo.dev.swift:def:11" href="gentoo-oval.xml" />
+</check>
+</Rule>
+
+<Rule id="xccdf_org.gentoo.dev.swift_rule_partition-home-nodev" selected="false" severity="low" weight="5.9">
+<title>/home is mounted with nodev</title>
+<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_partition-home-nodev">Mount /home with nodev mount option</fixtext>
+<fix id="xccdf_org.gentoo.dev.swift_fix_partition-home-nodev"
+system="urn:xccdf:fix:system:commands"
+platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false">
 mount -o remount,nodev /home
-          </fix>
-          <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
-            <check-content-ref name="oval:org.gentoo.dev.swift:def:4" href="gentoo-oval.xml" />
-          </check>
-        </Rule>
-        <!-- Higher severity due to more best practices and world writeable,
-             also more likely that exploit of process is done towards /tmp -->
-        <Rule id="xccdf_org.gentoo.dev.swift_rule_partition-tmp-nodev" selected="false" severity="medium" weight="5.9">
-          <title>/tmp is mounted with nodev</title>
-          <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_partition-tmp-nodev">Mount /tmp with nodev mount option</fixtext>
-          <fix id="xccdf_org.gentoo.dev.swift_fix_partition-tmp-nodev"
-            system="urn:xccdf:fix:system:commands"
-            platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false">
+</fix>
+<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
+<check-content-ref name="oval:org.gentoo.dev.swift:def:4" href="gentoo-oval.xml" />
+</check>
+</Rule>
+
+<!-- Higher severity due to more best practices and world writeable, also more likely that exploit of process is done towards /tmp -->
+<Rule id="xccdf_org.gentoo.dev.swift_rule_partition-tmp-nodev" selected="false" severity="medium" weight="5.9">
+<title>/tmp is mounted with nodev</title>
+<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_partition-tmp-nodev">Mount /tmp with nodev mount option</fixtext>
+<fix id="xccdf_org.gentoo.dev.swift_fix_partition-tmp-nodev"
+system="urn:xccdf:fix:system:commands"
+platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false">
 mount -o remount,nodev /tmp
-          </fix>
-          <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
-            <check-content-ref name="oval:org.gentoo.dev.swift:def:12" href="gentoo-oval.xml" />
-          </check>
-        </Rule>
-        <Rule id="xccdf_org.gentoo.dev.swift_rule_partition-tmp-nosuid" selected="false" severity="medium" weight="5.9">
-          <title>/tmp is mounted with nosuid</title>
-          <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_partition-tmp-nosuid">Mount /tmp with nosuid mount option</fixtext>
-          <fix id="xccdf_org.gentoo.dev.swift_fix_partition-tmp-nosuid"
-            system="urn:xccdf:fix:system:commands"
-            platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false">
+</fix>
+<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
+<check-content-ref name="oval:org.gentoo.dev.swift:def:12" href="gentoo-oval.xml" />
+</check>
+</Rule>
+
+<Rule id="xccdf_org.gentoo.dev.swift_rule_partition-tmp-nosuid" selected="false" severity="medium" weight="5.9">
+<title>/tmp is mounted with nosuid</title>
+<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_partition-tmp-nosuid">Mount /tmp with nosuid mount option</fixtext>
+<fix id="xccdf_org.gentoo.dev.swift_fix_partition-tmp-nosuid"
+system="urn:xccdf:fix:system:commands"
+platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false">
 mount -o remount,nosuid /tmp
-          </fix>
-          <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
-            <check-content-ref name="oval:org.gentoo.dev.swift:def:13" href="gentoo-oval.xml" />
-          </check>
-        </Rule>
-        <Rule id="xccdf_org.gentoo.dev.swift_rule_partition-home-nosuid" selected="false" severity="low" weight="5.9">
-          <title>/home is mounted with nosuid</title>
-          <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_partition-home-nosuid">Mount /home with nosuid mount option</fixtext>
-          <fix id="xccdf_org.gentoo.dev.swift_fix_partition-home-nosuid"
-            system="urn:xccdf:fix:system:commands"
-            platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false">
+</fix>
+<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
+<check-content-ref name="oval:org.gentoo.dev.swift:def:13" href="gentoo-oval.xml" />
+</check>
+</Rule>
+
+<Rule id="xccdf_org.gentoo.dev.swift_rule_partition-home-nosuid" selected="false" severity="low" weight="5.9">
+<title>/home is mounted with nosuid</title>
+<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_partition-home-nosuid">Mount /home with nosuid mount option</fixtext>
+<fix id="xccdf_org.gentoo.dev.swift_fix_partition-home-nosuid"
+system="urn:xccdf:fix:system:commands"
+platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false">
 mount -o remount,nosuid /home
-          </fix>
-          <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
-            <check-content-ref name="oval:org.gentoo.dev.swift:def:3" href="gentoo-oval.xml" />
-          </check>
-        </Rule>
-        <Rule id="xccdf_org.gentoo.dev.swift_rule_partition-devshm-nosuid" selected="false" severity="medium" weight="5.9">
-          <title>/dev/shm is mounted with nosuid</title>
-          <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_partition-devshm-nosuid">Mount /dev/shm with nosuid mount option</fixtext>
-          <fix id="xccdf_org.gentoo.dev.swift_fix_partition-devshm-nosuid"
-            system="urn:xccdf:fix:system:commands"
-            platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false">
+</fix>
+<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
+<check-content-ref name="oval:org.gentoo.dev.swift:def:3" href="gentoo-oval.xml" />
+</check>
+</Rule>
+
+<Rule id="xccdf_org.gentoo.dev.swift_rule_partition-devshm-nosuid" selected="false" severity="medium" weight="5.9">
+<title>/dev/shm is mounted with nosuid</title>
+<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_partition-devshm-nosuid">Mount /dev/shm with nosuid mount option</fixtext>
+<fix id="xccdf_org.gentoo.dev.swift_fix_partition-devshm-nosuid"
+system="urn:xccdf:fix:system:commands"
+platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false">
 mount -o remount,nosuid /dev/shm
-          </fix>
-          <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
-            <check-content-ref name="oval:org.gentoo.dev.swift:def:14" href="gentoo-oval.xml" />
-          </check>
-        </Rule>
-        <!-- Weight is 0 as this is a means to exploit, not exploitable by
-             itself -->
-        <Rule id="xccdf_org.gentoo.dev.swift_rule_partition-tmp-noexec" selected="false" severity="medium" weight="0.0">
-          <title>/tmp is mounted with noexec</title>
-          <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_partition-tmp-noexec">Mount /tmp with noexec mount option</fixtext>
-          <fix id="xccdf_org.gentoo.dev.swift_fix_partition-tmp-noexec"
-            system="urn:xccdf:fix:system:commands"
-            platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false">
+</fix>
+<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
+<check-content-ref name="oval:org.gentoo.dev.swift:def:14" href="gentoo-oval.xml" />
+</check>
+</Rule>
+
+<!-- Weight is 0 as this is a means to exploit, not exploitable by itself -->
+<Rule id="xccdf_org.gentoo.dev.swift_rule_partition-tmp-noexec" selected="false" severity="medium" weight="0.0">
+<title>/tmp is mounted with noexec</title>
+<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_partition-tmp-noexec">Mount /tmp with noexec mount option</fixtext>
+<fix id="xccdf_org.gentoo.dev.swift_fix_partition-tmp-noexec"
+system="urn:xccdf:fix:system:commands"
+platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false">
 mount -o remount,noexec /tmp
-          </fix>
-          <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
-            <check-content-ref name="oval:org.gentoo.dev.swift:def:15" href="gentoo-oval.xml" />
-          </check>
-        </Rule>
-        <Rule id="xccdf_org.gentoo.dev.swift_rule_partition-devshm-noexec" selected="false" severity="medium" weight="0.0">
-          <title>/dev/shm is mounted with noexec</title>
-          <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_partition-devshm-noexec">Mount /dev/shm with nosuid mount option</fixtext>
-          <fix id="xccdf_org.gentoo.dev.swift_fix_partition-devshm-noexec"
-            system="urn:xccdf:fix:system:commands"
-            platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false">
+</fix>
+<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
+<check-content-ref name="oval:org.gentoo.dev.swift:def:15" href="gentoo-oval.xml" />
+</check>
+</Rule>
+
+<Rule id="xccdf_org.gentoo.dev.swift_rule_partition-devshm-noexec" selected="false" severity="medium" weight="0.0">
+<title>/dev/shm is mounted with noexec</title>
+<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_partition-devshm-noexec">Mount /dev/shm with nosuid mount option</fixtext>
+<fix id="xccdf_org.gentoo.dev.swift_fix_partition-devshm-noexec"
+system="urn:xccdf:fix:system:commands"
+platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false">
 mount -o remount,noexec /dev/shm
-          </fix>
-          <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
-            <check-content-ref name="oval:org.gentoo.dev.swift:def:16" href="gentoo-oval.xml" />
-          </check>
-        </Rule>
-      </Group> <!-- system-fs-mountoptions -->
-      <Group id="xccdf_org.gentoo.dev.swift_group_system-fs-quotas">
-        <title>Disk quota support</title>
-        <description>
-	  <h:p>
-          Most file systems support the notion of <h:em>quotas</h:em> - limits
-          on the amount of data / files that are allowed on that particular file system.
-	  </h:p>
-	  <h:p>
-          To enable quotas, first configure the Linux kernel to include
-          <h:code>CONFIG_QUOTA</h:code>.
-	  </h:p>
-	  <h:p>
-          Next, install the <h:code>sys-fs/quota</h:code> package.
-	  </h:p>
-          <h:pre>
+</fix>
+<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
+<check-content-ref name="oval:org.gentoo.dev.swift:def:16" href="gentoo-oval.xml" />
+</check>
+</Rule>
+
+</Group>
+
+<Group id="xccdf_org.gentoo.dev.swift_group_installation-storage-encrypted">
+<title>Use encrypted file systems</title>
+<description>
+<h:p>
+TODO: Use encrypted file systems if not hosted in fully trusted environment
+</h:p>
+<h:p>
+This includes encrypted swap!
+</h:p>
+</description>
+</Group>
+
+</Group>
+
+<Group id="xccdf_org.gentoo.dev.swift_group_installation-base">
+<title>Gentoo base installation</title>
+<description>
+<h:p>
+The Gentoo base installation concerns itself with the extraction of a minimal Gentoo Linux environment.
+This minimal environment provides the base foundation for building the rest of the system, including
+a compiler, necessary set of libraries and system services.
+</h:p>
+</description>
+
+<Group id="xccdf_org.gentoo.dev.swift_group_installation-base-stage3">
+<title>Hardened stage3</title>
+<description>
+<h:p>
+Use one of Gentoo Hardened's stage3 archive files as the base of the Linux installation.
+</h:p>
+<h:p>
+The Gentoo Hardened stages are built with a hardened compiler and toolchain, which means
+that the various binaries included are already built with PIC and PIE, allowing for the 
+various memory protections (such as Address Space Layout Randomization) to take effect.
+</h:p>
+<h:p>
+Administrations will have the option of selecting a hardened <h:em>nomultilib</h:em> stage
+as well. With multilib, the system is capable of running both 32-bit and 64-bit applications.
+With a <h:em>nomultilib</h:em> stage, only 64-bit applications can be used. It is generally recommended
+to use the <h:em>nomultilib</h:em> stages if this is possible functionally. That means, if there
+is no need to run 32-bit applications on a 64-bit installation.
+</h:p>
+<h:p>
+One of the concerns with using multilib systems is that a number of libraries are provided through
+the <h:tt>emul-linux</h:tt> package, which might contain vulnerable libraries. Sadly, there is not
+enough manpower available to update this package as quickly as the main libraries. Gentoo Linux
+is slowly converting towards the <h:em>gx86-multilib</h:em> approach where the 32-bit libraries
+are provided by the native ebuilds themselves.
+</h:p>
+</description>
+<reference href="https://wiki.gentoo.org/wiki/Multilib/gx86-multilib">Gentoo gx86-multilib information</reference>
+</Group>
+
+<Group id="xccdf_org.gentoo.dev.swift_group_installation-base-toolchain">
+<title>Hardened toolchain</title>
+<description>
+<h:p>
+When Gentoo is installed, use the hardened stages and hardened toolchain.
+The hardened toolchain includes additional security patches, such as
+support for non-executable program stacks and buffer overflow detection.
+</h:p>
+<h:ul>
+<h:li>
+When using <h:em>Position Independent Executables (PIE)</h:em> and <h:em>Position Independent
+Code (PIC)</h:em>, which is enabled when selecting the hardened toolchain, memory hardening techniques
+such as those implemented by grsecurity PaX allows for Address Space Layout Randomization (ASLR) so
+that memory locations for an application are randomized with every run. This makes exploitation of
+memory oriented vulnerabilities much harder.
+</h:li>
+<h:li>
+<h:em>Stack Smashing Protection (SSP)</h:em> adds markers outside buffer areas
+to detect buffer overflow attacks, killing the application rather than effectively
+having the overflow succeed.
+</h:li>
+</h:ul>
+<h:p>
+During installation, make sure that the <h:em>default</h:em> hardened
+toolchain is selected, not one of the <h:code>-hardenedno*</h:code> as
+those are toolchains where specific settings are disabled. The
+<h:code>-vanilla</h:code> one is a toolchain with no hardened patches.
+</h:p>
+<h:pre>
+# <h:b>gcc-config -l</h:b>
+[1] x86_64-pc-linux-gnu-4.4.5 *
+[2] x86_64-pc-linux-gnu-4.4.5-hardenednopie
+[3] x86_64-pc-linux-gnu-4.4.5-hardenednopie.gcc-config-ref
+[4] x86_64-pc-linux-gnu-4.4.5-hardenednopiessp
+[5] x86_64-pc-linux-gnu-4.4.5-hardenednossp
+[6] x86_64-pc-linux-gnu-4.4.5-vanilla</h:pre>
+</description>
+
+<Rule id="xccdf_org.gentoo.dev.swift_rule_installation-toolchain-hardened" selected="false" severity="low" weight="0.0">
+<title>The hardened toolchain is used</title>
+<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_installation-toolchain-hardened">
+Use a hardened Gentoo profile and select the default compiler (not vanilla
+nor any of the hardenedno* ones).
+</fixtext>
+<check system="http://open-scap.org/page/SCE">
+<check-import import-name="stdout" />
+<check-content-ref href="bin/gentoo-sce_installation-toolchain-hardened.sh" />
+</check>
+</Rule>
+
+</Group>
+
+</Group>
+
+<Group id="xccdf_org.gentoo.dev.swift_group_installation-boot">
+<title>Boot-critical services</title>
+<description>
+<h:p>
+Before finishing a Gentoo Linux installation, a number of boot-critical services are installed.
+This includes the boot loader itself as well as the Linux kernel.
+</h:p>
+<h:p>
+Building a Linux kernel with the right set of security-related settings is moved outside the scope of this
+benchmark. Please refer to the Kernel hardening benchmark for more information.
+</h:p>
+</description>
+<reference href="http://dev.gentoo.org/~swift/docs/security_benchmarks/guide-kernel-xccdf.html">Gentoo Linux Kernel hardening benchmark</reference>
+
+<Group id="xccdf_org.gentoo.dev.swift_group_installation-boot-bootloader">
+<title>Bootloader configuration</title>
+<description>
+<h:p>
+The bootloader (be it GRUB or another tool) is responsible for loading
+the Linux kernel and handing over system control to the kernel. But boot
+loaders also allow for a flexible approach on kernel loading, which can
+be (ab)used to work around security mechanisms.
+</h:p>
+</description>
+
+<Group id="xccdf_org.gentoo.dev.swift_group_installation-boot-bootloader-uefi">
+<title>UEFI settings</title>
+<description>
+<h:p>
+TODO: Use UEFI boot mode
+</h:p>
+<h:p>
+TODO: Password required to enter UEFI configuration
+</h:p>
+<h:p>
+TODO: UEFI level password to boot system
+</h:p>
+</description>
+</Group>
+
+<Group id="xccdf_org.gentoo.dev.swift_group_installation-boot-bootloader-grub2pass">
+<title>Password protect GRUB 2</title>
+<description>
+<h:p>
+It is recommended to password-protect the GRUB configuration so that the
+boot options cannot be modified during a boot without providing the valid
+password.
+</h:p>
+<h:p>
+TODO looks like this has become a lot more difficult to obtain
+</h:p>
+</description>
+<reference href="https://help.ubuntu.com/community/Grub2/Passwords">GRUB2 Passwords (Ubuntu wiki)</reference>
+</Group>
+
+<Group id="xccdf_org.gentoo.dev.swift_group_installation-boot-bootloader-grub1pass">
+<title>Password protect GRUB (legacy)</title>
+<description>
+<h:p>
+It is recommended to password-protect the GRUB configuration so that
+the boot options cannot be modified during a boot without providing the
+valid password.
+</h:p>
+<h:p>
+This can be accomplished by inserting <h:code>password abc123</h:code>
+in <h:code>/boot/grub/grub.conf</h:code> (which will set the password
+to "abc123"). But as clear-text passwords in the configuration file are insecure as well,
+hash the passwords. Just start <h:b>grub</h:b>
+and, in the grub-shell, type <h:b>md5crypt</h:b>.
+</h:p>
+<h:pre>
+# <h:b>grub</h:b>
+
+GRUB version 0.92 (640K lower / 3072K upper memory)
+
+[ Minimal BASH-like line editing is supported. ... ]
+
+grub&gt; <h:b>md5crypt</h:b>
+
+Password: <h:em>abc123</h:em>
+Encrypted: $1$18u.M0$J8VbOsGXuoG9Fh3n7ZkqY.
+
+grub&gt; <h:b>quit</h:b></h:pre>
+<h:p>
+This hashed password can now be used in <h:code>grub.conf</h:code>
+using <h:code>password --md5 $1$18u.M0$J8VbOsGXuoG9Fh3n7ZkqY.</h:code>.
+</h:p>
+</description>
+
+<Rule id="xccdf_org.gentoo.dev.swift_rule_grubconf-password-md5" selected="false" severity="low" weight="6.9">
+<title>Grub legacy (if it exists) has a password entry with md5 hash</title>
+<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_grubconf-password-md5">
+Edit /boot/grub/grub.conf and set a password entry with md5 hash
+</fixtext>
+<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
+<check-content-ref name="oval:org.gentoo.dev.swift:def:34" href="gentoo-oval.xml" />
+</check>
+</Rule>
+
+</Group>
+
+<Group id="xccdf_org.gentoo.dev.swift_group_installation-boot-bootloader-lilopass">
+<title>Password protect LILO</title>
+<description>
+<h:p>
+It is recommended to password-protect the LILO configuration so that
+modifying the boot options during a boot without providing the
+valid password is not possible.
+</h:p>
+<h:p>
+This can be accomplished  by inserting <h:code>password=abc123</h:code>
+followed by <h:code>restricted</h:code> in the
+<h:code>/etc/lilo.conf</h:code> file. It is also possible to do this
+on a per-image level.
+</h:p>
+<h:pre>
+password=abc123
+restricted
+delay=3
+
+image=/boot/bzImage
+read-only
+password=def456
+restricted</h:pre>
+<h:p>
+The <h:code>restricted</h:code> keyword is needed to have LILO only
+ask for the password if a modification is given. If the defaults are
+used, then no password needs to be provided.
+</h:p>
+<h:p>
+Rerun <h:code>lilo</h:code> after updating the configuration file.
+</h:p>
+</description>
+
+<Rule id="xccdf_org.gentoo.dev.swift_rule_liloconf-password" selected="false" severity="low" weight="6.9">
+<title>LILO (if it exists) has a password entry</title>
+<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_liloconf-password">
+Edit /etc/lilo.conf and set a password entry
+</fixtext>
+<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
+<check-content-ref name="oval:org.gentoo.dev.swift:def:35" href="gentoo-oval.xml" />
+</check>
+</Rule>
+
+</Group>
+
+</Group>
+
+</Group>
+
+</Group> <!-- End of installation related -->
+
+<Group id="xccdf_org.gentoo.dev.swift_group_system">
+<title>Portage and system settings</title>
+<description>
+<h:p>
+After a succesful Gentoo Linux installation, there are still various settings which need to be
+adjusted in order to create a properly hardened system.
+</h:p>
+</description>
+
+<Group id="xccdf_org.gentoo.dev.swift_group_system-fs">
+<title>File system related settings</title>
+<description>
+Servers and systems are about manipulating data. In this chapter, the security settings
+for file systems are explained.
+</description>
+
+<Group id="xccdf_org.gentoo.dev.swift_group_system-fs-quotas">
+<title>Disk quota support</title>
+<description>
+<h:p>
+Most file systems support the notion of <h:em>quotas</h:em> - limits
+on the amount of data / files that are allowed on that particular file system.
+</h:p>
+<h:p>
+To enable quotas, first configure the Linux kernel to include
+<h:code>CONFIG_QUOTA</h:code>.
+</h:p>
+<h:p>
+Next, install the <h:code>sys-fs/quota</h:code> package.
+</h:p>
+<h:pre>
 # <h:b>emerge quota</h:b></h:pre>
-          <h:p>
-          Then add <h:code>usrquota</h:code> and <h:code>grpquota</h:code> to
-          the partitions (in <h:code>/etc/fstab</h:code>) where quotas need to be
-          enabled on. For instance, the following snippet from
-          <h:code>/etc/fstab</h:code> enables quotas on <h:code>/var</h:code>
-          and <h:code>/home</h:code>.
-	  </h:p>
-          <h:pre>
+<h:p>
+Then add <h:code>usrquota</h:code> and <h:code>grpquota</h:code> to
+the partitions (in <h:code>/etc/fstab</h:code>) where quotas need to be
+enabled on. For instance, the following snippet from
+<h:code>/etc/fstab</h:code> enables quotas on <h:code>/var</h:code>
+and <h:code>/home</h:code>.
+</h:p>
+<h:pre>
 /dev/mapper/volgrp-home /home ext4 noatime,nodev,nosuid,<h:b>usrquota,grpquota</h:b> 0 0
 /dev/mapper/volgrp-var  /var  ext4 noatime,<h:b>usrquota,grpquota</h:b>              0 0</h:pre>
-          <h:p>
-          Finally, add the <h:code>quota</h:code> service to the boot runlevel.
-	  </h:p>
-          <h:pre>
+<h:p>
+Finally, add the <h:code>quota</h:code> service to the boot runlevel.
+</h:p>
+<h:pre>
 # <h:b>rc-update add quota boot</h:b></h:pre>
-          <h:p>
-          Reboot the system so that the partitions are mounted with the correct
-          mount options and that the quota service is running. Then the quotas for
-          users and groups can be set up.
-	  </h:p>
-        </description>
-        <reference
-        href="http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch28_:_Managing_Disk_Usage_with_Quotas">Managing
-        Disk Usage with Quotas (LinuxHomeNetworking)</reference>
-        <reference href="http://www.gentoo.org/doc/en/kernel-config.xml#shorthand">Gentoo Linux Kernel Configuration - shorthand notation information</reference>
-        <Rule id="xccdf_org.gentoo.dev.swift_rule_kernel-quota" selected="false" severity="low" weight="1.7">
-          <title>The kernel supports quota (CONFIG_QUOTA)</title>
-          <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_kernel-quota">Rebuild the Linux kernel with quota support (CONFIG_QUOTA)</fixtext>
-          <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
-            <check-content-ref name="oval:org.gentoo.dev.swift:def:18" href="gentoo-oval.xml" />
-          </check>
-        </Rule>
-	<Rule id="xccdf_org.gentoo.dev.swift_rule_var-quota" selected="false" severity="low" weight="1.7">
-	  <title>The /var file system is mounted with usrquota or grpquota</title>
-	  <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_var-quota">Mount /var with usrquota and/or grpquota</fixtext>
-	  <fix id="xccdf_org.gentoo.dev.swift_fix_partition-var-quota"
-               system="urn:xccdf:fix:system:commands"
-	       platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false">
+<h:p>
+Reboot the system so that the partitions are mounted with the correct
+mount options and that the quota service is running. Then the quotas for
+users and groups can be set up.
+</h:p>
+</description>
+<reference
+href="http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch28_:_Managing_Disk_Usage_with_Quotas">Managing
+Disk Usage with Quotas (LinuxHomeNetworking)</reference>
+<reference href="http://www.gentoo.org/doc/en/kernel-config.xml#shorthand">Gentoo Linux Kernel Configuration - shorthand notation information</reference>
+
+<Rule id="xccdf_org.gentoo.dev.swift_rule_kernel-quota" selected="false" severity="low" weight="1.7">
+<title>The kernel supports quota (CONFIG_QUOTA)</title>
+<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_kernel-quota">Rebuild the Linux kernel with quota support (CONFIG_QUOTA)</fixtext>
+<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
+<check-content-ref name="oval:org.gentoo.dev.swift:def:18" href="gentoo-oval.xml" />
+</check>
+</Rule>
+
+<Rule id="xccdf_org.gentoo.dev.swift_rule_var-quota" selected="false" severity="low" weight="1.7">
+<title>The /var file system is mounted with usrquota or grpquota</title>
+<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_var-quota">Mount /var with usrquota and/or grpquota</fixtext>
+<fix id="xccdf_org.gentoo.dev.swift_fix_partition-var-quota"
+system="urn:xccdf:fix:system:commands"
+platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false">
 mount -o remount,usrquota,grpquota /var
-          </fix>
-          <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
-            <check-content-ref name="oval:org.gentoo.dev.swift:def:25" href="gentoo-oval.xml" />
-	  </check>
-	</Rule>
-	<Rule id="xccdf_org.gentoo.dev.swift_rule_home-quota" selected="false" severity="low" weight="1.7">
-	  <title>The /home file system is mounted with usrquota or grpquota</title>
-	  <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_home-quota">Mount /home with usrquota and/or grpquota</fixtext>
-	  <fix id="xccdf_org.gentoo.dev.swift_fix_partition-home-quota"
-	       system="urn:xccdf:fix:system:commands"
-	       platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false">
+</fix>
+<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
+<check-content-ref name="oval:org.gentoo.dev.swift:def:25" href="gentoo-oval.xml" />
+</check>
+</Rule>
+
+<Rule id="xccdf_org.gentoo.dev.swift_rule_home-quota" selected="false" severity="low" weight="1.7">
+<title>The /home file system is mounted with usrquota or grpquota</title>
+<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_home-quota">Mount /home with usrquota and/or grpquota</fixtext>
+<fix id="xccdf_org.gentoo.dev.swift_fix_partition-home-quota"
+system="urn:xccdf:fix:system:commands"
+platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false">
 mount -o remount,usrquota,grpquota /home
-          </fix>
-          <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
-            <check-content-ref name="oval:org.gentoo.dev.swift:def:26" href="gentoo-oval.xml" />
-	  </check>
-	</Rule>
-      </Group> <!-- system-fs-quotas -->
-      <Group  id="xccdf_org.gentoo.dev.swift_group_system-fs-hidepid">
-        <title>Hiding process information through hidepid</title>
-	<description>
-	  <h:p>
-	    In order to hide process information from other users, the <h:code>/proc</h:code> file system needs to be
-	    mounted with the <h:code>hidepid</h:code> option. With value 0, the default behavior is used, meaning that 
-	    all process information is world readable.
-	  </h:p>
-	  <h:p>
-	    When the value 1 is passed, the process information is not readable, but process directories are still shown
-	    in the <h:code>/proc</h:code> mount. In order to truly hide this information, pass on the value 2.
-	  </h:p>
-	  <h:p>
-	    In order to allow a particular group of people to see other people's processes, the <h:code>gid=</h:code>
-	    option can be used to exempt this group from the PID hiding.
-	  </h:p>
-	</description>
-	<reference href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0499680a42141d86417a8fbaa8c8db806bea1201">Kernel commit introducing
-	the hidepid support</reference>
-	<Rule id="xccdf_org.gentoo.dev.swift_rule_proc-hidepid" selected="false" severity="medium" weight="1.7">
-	  <title>The /proc file system is mounted with hidepid=1 or hidepid=2</title>
-	  <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_proc-hidepid">Mount /proc with hidepid=1 or hidepid=2</fixtext>
-	  <fix id="xccdf_org.gentoo.dev.swift_fix_proc-hidepid"
-	       system="urn:xccdf:fix:system:commands"
-	       platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false">
+</fix>
+<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
+<check-content-ref name="oval:org.gentoo.dev.swift:def:26" href="gentoo-oval.xml" />
+</check>
+</Rule>
+
+</Group> <!-- system-fs-quotas -->
+
+<Group  id="xccdf_org.gentoo.dev.swift_group_system-fs-hidepid">
+<title>Hiding process information through hidepid</title>
+<description>
+<h:p>
+In order to hide process information from other users, the <h:code>/proc</h:code> file system needs to be
+mounted with the <h:code>hidepid</h:code> option. With value 0, the default behavior is used, meaning that 
+all process information is world readable.
+</h:p>
+<h:p>
+When the value 1 is passed, the process information is not readable, but process directories are still shown
+in the <h:code>/proc</h:code> mount. In order to truly hide this information, pass on the value 2.
+</h:p>
+<h:p>
+In order to allow a particular group of people to see other people's processes, the <h:code>gid=</h:code>
+option can be used to exempt this group from the PID hiding.
+</h:p>
+</description>
+<reference href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0499680a42141d86417a8fbaa8c8db806bea1201">Kernel commit introducing
+the hidepid support</reference>
+
+<Rule id="xccdf_org.gentoo.dev.swift_rule_proc-hidepid" selected="false" severity="medium" weight="1.7">
+<title>The /proc file system is mounted with hidepid=1 or hidepid=2</title>
+<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_proc-hidepid">Mount /proc with hidepid=1 or hidepid=2</fixtext>
+<fix id="xccdf_org.gentoo.dev.swift_fix_proc-hidepid"
+system="urn:xccdf:fix:system:commands"
+platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false">
 mount -o remount,hidepid=2 /proc
-          </fix>
-	  <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
-	    <check-content-ref name="oval:org.gentoo.dev.swift:def:33" href="gentoo-oval.xml" />
-	  </check>
-	</Rule>
-      </Group>
-    </Group> <!-- system-fs -->
-    <Group id="xccdf_org.gentoo.dev.swift_group_system-services">
-      <title>System services</title>
-      <description>
-        <h:p>
-        Services (daemons) are the primary reason for a server to exist.
-        They represent the function of the server. For instance, a web server
-        will run the apache2 or lighttpd service. A name server will run the
-        named service.
-	</h:p>
-	<h:p>
-        In this benchmark, the focus is on a limited set of system services. For
-        the other services it is wise to consult other hardening guides specific
-	for those services.
-	</h:p>
-      </description>
-      <reference href="http://www.cisecurity.org">Center for Internet Security,
-      host of many service benchmarks</reference>
-      <Group id="xccdf_org.gentoo.dev.swift_group_system-services-disable">
-        <title>Disable unsafe services</title>
-        <description>
-	  <h:p>
-          It is recommended to disable (or even uninstall) the following services unless
-          absolutely necessary. These services use plain-text protocols and are as such unsafe
-          to use on (untrusted) networks.
-	  </h:p>
-          <h:ul>
-            <h:li>Telnet service</h:li>
-            <h:li>FTP Service</h:li>
-          </h:ul>
-	  <h:p>
-          It is recommended to substitute these services with their more secure
-          counterparts (like sFTP, SSH, ...).
-	  </h:p>
-        </description>
-        <!-- Max score: password in clear text and your system is compromised (if it is root) -->
-	<Rule id="xccdf_org.gentoo.dev.swift_rule_telnetd-notrunning" selected="false" severity="high" weight="10.0">
-          <title>No telnet daemons are running</title>
-          <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_telnetd-notrunning">Stop telnet services</fixtext>
-          <fix id="xccdf_org.gentoo.dev.swift_fix_telnetd-notrunning"
-            system="urn:xccdf:fix:system:commands"
-            platform="cpe:/o:gentoo:linux" complexity="low" disruption="high" reboot="false">
+</fix>
+<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
+<check-content-ref name="oval:org.gentoo.dev.swift:def:33" href="gentoo-oval.xml" />
+</check>
+</Rule>
+
+</Group>
+
+</Group> <!-- system-fs -->
+
+<Group id="xccdf_org.gentoo.dev.swift_group_system-services">
+<title>System services</title>
+<description>
+<h:p>
+Services (daemons) are the primary reason for a server to exist.
+They represent the function of the server. For instance, a web server
+will run the apache2 or lighttpd service. A name server will run the
+named service.
+</h:p>
+<h:p>
+In this benchmark, the focus is on a limited set of system services. For
+the other services it is wise to consult other hardening guides specific
+for those services.
+</h:p>
+</description>
+<reference href="http://www.cisecurity.org">Center for Internet Security,
+host of many service benchmarks</reference>
+
+<Group id="xccdf_org.gentoo.dev.swift_group_system-services-disable">
+<title>Disable unsafe services</title>
+<description>
+<h:p>
+It is recommended to disable (or even uninstall) the following services unless
+absolutely necessary. These services use plain-text protocols and are as such unsafe
+to use on (untrusted) networks.
+</h:p>
+<h:ul>
+<h:li>Telnet service</h:li>
+<h:li>FTP Service</h:li>
+</h:ul>
+<h:p>
+It is recommended to substitute these services with their more secure
+counterparts (like sFTP, SSH, ...).
+</h:p>
+</description>
+<!-- Max score: password in clear text and your system is compromised (if it is root) -->
+
+<Rule id="xccdf_org.gentoo.dev.swift_rule_telnetd-notrunning" selected="false" severity="high" weight="10.0">
+<title>No telnet daemons are running</title>
+<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_telnetd-notrunning">Stop telnet services</fixtext>
+<fix id="xccdf_org.gentoo.dev.swift_fix_telnetd-notrunning"
+system="urn:xccdf:fix:system:commands"
+platform="cpe:/o:gentoo:linux" complexity="low" disruption="high" reboot="false">
 for service in /etc/init.d/*telnet*;
 do
-  test -f ${service} &amp;&amp; run_init rc-service ${service##*/} stop;
+test -f ${service} &amp;&amp; run_init rc-service ${service##*/} stop;
 done
-          </fix>
-          <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
-            <check-content-ref name="oval:org.gentoo.dev.swift:def:19" href="gentoo-oval.xml" />
-          </check>
-        </Rule>
-        <!-- Partial breach, assuming accounts are not system accounts -->
-        <Rule id="xccdf_org.gentoo.dev.swift_rule_ftpd-notrunning" selected="false" severity="medium" weight="7.5">
-          <title>No FTP daemons are running</title>
-          <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_ftpd-notrunning">Stop FTPd services</fixtext>
-          <fix id="xccdf_org.gentoo.dev.swift_fix_ftpd-notrunning"
-            system="urn:xccdf:fix:system:commands"
-            platform="cpe:/o:gentoo:linux" complexity="low" disruption="high" reboot="false">
+</fix>
+<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
+<check-content-ref name="oval:org.gentoo.dev.swift:def:19" href="gentoo-oval.xml" />
+</check>
+</Rule>
+
+<!-- Partial breach, assuming accounts are not system accounts -->
+<Rule id="xccdf_org.gentoo.dev.swift_rule_ftpd-notrunning" selected="false" severity="medium" weight="7.5">
+<title>No FTP daemons are running</title>
+<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_ftpd-notrunning">Stop FTPd services</fixtext>
+<fix id="xccdf_org.gentoo.dev.swift_fix_ftpd-notrunning"
+system="urn:xccdf:fix:system:commands"
+platform="cpe:/o:gentoo:linux" complexity="low" disruption="high" reboot="false">
 for service in /etc/init.d/*ftp*;
 do
-  test -f ${service} &amp;&amp; run_init rc-service ${service##*/} stop;
+test -f ${service} &amp;&amp; run_init rc-service ${service##*/} stop;
 done
-          </fix>
-          <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
-            <check-content-ref name="oval:org.gentoo.dev.swift:def:20" href="gentoo-oval.xml" />
-          </check>
-        </Rule>
-      </Group>
-      <Group id="xccdf_org.gentoo.dev.swift_group_system-services-sulogin">
-        <title>Require single-user boot to give root password</title>
-        <description>
-	  <h:p>
-          When a system is booted in single user mode, some users might find it
-          handy to immediately get a root prompt; many even have a specific
-          bootloader entry to boot in single user mode.
-	  </h:p>
-	  <h:p>
-          It is important that, for a more secure server environment, even
-          booting in single user mode requires the user to enter the root
-          password. This is already done by default in Gentoo through the
-          <h:code>rc_shell</h:code> variable in <h:code>/etc/rc.conf</h:code>.
-	  </h:p>
-	  <h:p>
-          Administrators should also make sure that no direct shells are provided
-          in <h:code>/etc/inittab</h:code> for single-user mode. Gentoo's
-          <h:code>/etc/inittab</h:code> definition should look like so:
-	  </h:p>
-          <h:pre>
+</fix>
+<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
+<check-content-ref name="oval:org.gentoo.dev.swift:def:20" href="gentoo-oval.xml" />
+</check>
+</Rule>
+
+</Group>
+
+<Group id="xccdf_org.gentoo.dev.swift_group_system-services-sulogin">
+<title>Require single-user boot to give root password</title>
+<description>
+<h:p>
+When a system is booted in single user mode, some users might find it
+handy to immediately get a root prompt; many even have a specific
+bootloader entry to boot in single user mode.
+</h:p>
+<h:p>
+It is important that, for a more secure server environment, even
+booting in single user mode requires the user to enter the root
+password. This is already done by default in Gentoo through the
+<h:code>rc_shell</h:code> variable in <h:code>/etc/rc.conf</h:code>.
+</h:p>
+<h:p>
+Administrators should also make sure that no direct shells are provided
+in <h:code>/etc/inittab</h:code> for single-user mode. Gentoo's
+<h:code>/etc/inittab</h:code> definition should look like so:
+</h:p>
+<h:pre>
 su0:S:wait:/sbin/rc single
 <h:b>su1:S:wait:/sbin/sulogin</h:b></h:pre>
-        </description>
-        <!-- CVSS2: AV:L/AC:H/Au:S/C:C/I:C/A:C (high attack complexity due to console access) -->
-        <Rule id="xccdf_org.gentoo.dev.swift_rule_rcconf-sulogin" selected="false" severity="medium" weight="6.0">
-          <title>sulogin is used for single-user boot (/etc/rc.conf)</title>
-          <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_rcconf-sulogin">Set /sbin/sulogin for rc_shell</fixtext>
-          <fix id="xccdf_org.gentoo.dev.swift_fix_rcconf-sulogin"
-            system="urn:xccdf:fix:system:commands"
-            platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false">
+</description>
+
+<!-- CVSS2: AV:L/AC:H/Au:S/C:C/I:C/A:C (high attack complexity due to console access) -->
+<Rule id="xccdf_org.gentoo.dev.swift_rule_rcconf-sulogin" selected="false" severity="medium" weight="6.0">
+<title>sulogin is used for single-user boot (/etc/rc.conf)</title>
+<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_rcconf-sulogin">Set /sbin/sulogin for rc_shell</fixtext>
+<fix id="xccdf_org.gentoo.dev.swift_fix_rcconf-sulogin"
+system="urn:xccdf:fix:system:commands"
+platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false">
 sed -i -e 's:^rc_shell=.*:rc_shell="/sbin/sulogin":g' /etc/rc.conf
-          </fix>
-          <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
-            <check-content-ref name="oval:org.gentoo.dev.swift:def:21" href="gentoo-oval.xml" />
-          </check>
-        </Rule>
-        <Rule id="xccdf_org.gentoo.dev.swift_rule_inittab-sulogin" selected="false" severity="medium" weight="6.0">
-          <title>sulogin is used for single-user boot (/etc/inittab)</title>
-          <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_inittab-sulogin">
-            Set /sbin/sulogin or '/sbin/rc single' for single-user boot in /etc/inittab
-          </fixtext>
-          <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
-            <check-content-ref name="oval:org.gentoo.dev.swift:def:22" href="gentoo-oval.xml" />
-          </check>
-        </Rule>
-      </Group>
-      <Group id="xccdf_org.gentoo.dev.swift_group_system-services-tcpwrappers">
-        <title>Properly Configure TCP Wrappers</title>
-        <description>
-	  <h:p>
-          With TCP wrappers, services that support TCP wrappers (or those
-          started through <h:b>xinetd</h:b>) should be configured to only accept
-          communication with trusted hosts. With the use of
-          <h:code>/etc/hosts.allow</h:code> and <h:code>/etc/hosts.deny</h:code>,
-          proper access control lists can be created.
-	  </h:p>
-	  <h:p>
-          More information on the format of these files can be obtained through
-          <h:b>man 5 hosts_access</h:b>.
-	  </h:p>
-        </description>
-        <Rule id="xccdf_org.gentoo.dev.swift_rule_hostsallow-exists" selected="false" severity="info" weight="0.0">
-          <title>/etc/hosts.allow exists</title>
-          <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_hostsallow-exists">
-            Create and properly configure /etc/hosts.allow
-          </fixtext>
-          <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
-            <check-content-ref name="oval:org.gentoo.dev.swift:def:23" href="gentoo-oval.xml" />
-          </check>
-        </Rule>
-      </Group>
-      <Group id="xccdf_org.gentoo.dev.swift_group_system-services-ssh">
-        <title>SSH service</title>
-        <description>
-	  <h:p>
-          The SSH service is used for secure remote access towards a system, but
-          also to provide secure file transfers. It is very commonly found on Unix/Linux
-          systems so proper hardening is definitely in place.
-	  </h:p>
-	  <h:p>
-          Please use the "Hardening OpenSSH" guide for the necessary instructions.
-	  </h:p>
-        </description>
-      </Group>
-      <Group id="xccdf_org.gentoo.dev.swift_group_system-services-cron">
-        <title>Cron service</title>
-        <description>
-          A cron service is used to schedule tasks and processes on predefined
-          times. Cron is most often used for regular maintenance tasks.
-        </description>
-        <Group id="xccdf_org.gentoo.dev.swift_group_system-services-cron-acl">
-          <title>Only allow trusted accounts cron access</title>
-          <description>
-	    <h:p>
-            Only allow trusted accounts to use cron. How to achieve this depends on the cron service
-            installed.
-	    </h:p>
-	    <h:p>
-            If vixie-cron or cronie is installed, then have (only) those users that need cron access
-	    take part in the <h:em>cron</h:em> unix group. 
-	    </h:p>
-	    <h:p>
-            If dcron is used, then make sure <h:code>/usr/sbin/crontab</h:code> is only executable by
-            root and the cron unix group, and make sure (only) those users that need cron access take part
-            in the <h:em>cron</h:em> unix group.
-	    </h:p>
-          </description>
-        </Group>
-      </Group>
-      <Group id="xccdf_org.gentoo.dev.swift_group_system-services-at">
-        <title>At service</title>
-        <description>
-          The at service allows users to execute a task once on a given time.
-          Unlike cron, this is not scheduled repeatedly - once executed, the
-          task is considered completed and at will not invoke it again.
-        </description>
-        <Group id="xccdf_org.gentoo.dev.swift_group_system-services-at-acl">
-          <title>Only allow trusted accounts at access</title>
-          <description>
-	    <h:p>
-            Only allow trusted accounts to use at. Unlike cron access, at access is governed through
-            the <h:code>/etc/at/at.allow</h:code> file. If the <h:code>at.allow</h:code> file does not
-            exist but <h:code>/etc/at/at.deny</h:code> does, then all names <h:em>not</h:em> mentioned in
-            the file are allowed to run at. The most secure method is to use the <h:code>at.allow</h:code>
-            method.
-	    </h:p>
-	    <h:p>
-            The format of these files is one username per line.
-	    </h:p>
-          </description>
-          <Rule id="xccdf_org.gentoo.dev.swift_rule_atallow-exists" selected="false" severity="low" weight="0.0">
-            <title>/etc/at/at.allow exists</title>
-            <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_atsallow-exists">
-              Create and properly configure /etc/at/at.allow
-            </fixtext>
-            <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
-              <check-content-ref name="oval:org.gentoo.dev.swift:def:24" href="gentoo-oval.xml" />
-            </check>
-          </Rule>
-        </Group>
-      </Group>
-      <Group id="xccdf_org.gentoo.dev.swift_group_system-services-ntp">
-        <title>NTP service</title>
-        <description>
-	  <h:p>
-          With NTP, systems can synchronise their clocks, ensuring correct date
-          and time information. This is important as huge clock drift could
-          cause misinterpretation of log files or even unwanted execution of
-          commands.
-	  </h:p>
-        </description>
-        <Group id="xccdf_org.gentoo.dev.swift_group_system-services-ntp-sync">
-          <title>Synchronise the system clock</title>
-          <description>
-	    <h:p>
-            Synchronise the systems' clock with an authorative NTP server, and
-            use the same NTP service for all other systems.
-	    </h:p>
-	    <h:p>
-            This can be accomplished by regularly executing <h:b>ntpdate</h:b>,
-            but can also be handled using a service like <h:code>net-misc/ntp</h:code>'s
-            <h:b>ntpd</h:b>.
-	    </h:p>
-          </description>
-        </Group>
-      </Group>
-      <Group id="xccdf_org.gentoo.dev.swift_group_system-services-syslog">
-        <title>Syslog service</title>
-	<description>
-	  <h:p>
-	  The system logger handles all non-audit related logging generated by applications
-	  and daemons. In order to ensure proper forensic analysis if it would ever be needed,
-	  the system logger should be properly configured.
-	  </h:p>
-	</description>
-	<Group id="xccdf_org.gentoo.dev.swift_group_system-services-syslog-logintervals">
-          <title>Configure the system logger to log intervals</title>
-	  <description>
-	    <h:p>
-	    Have the system logger log every 10 minutes or so. Without interval logging,
-	    administrators might think nothing is wrong although in reality the system
-	    logger is malfunctioning and not writing any log events.
-	    </h:p>
-	  </description>
-	</Group>
-	<Group id="xccdf_org.gentoo.dev.swift_group_system-services-syslog-remotelogging">
-	  <title>Enable remote logging</title>
-	  <description>
-	    <h:p>
-	    If possible, have vital (or all) logs sent to a remote system logger as well.
-	    In home deployments, off-the-shelf (wifi) routers often have a logging daemon
-	    that can receive syslog events. For larger environments, a dedicated centralized
-	    log server is recommended.
-	    </h:p>
-	  </description>
-	</Group>
-	<Group id="xccdf_org.gentoo.dev.swift_group_system-services-syslog-terminal">
-	  <title>Decide which events to send to user terminals</title>
-	  <description>
-	    <h:p>
-	    On Linux and Unix systems, events can be sent to user terminals to
-	    make those users immediately aware of what is happening. It is
-	    recommended to send emergency-level events to everyone and have
-	    alerts sent to specific administrative user terminals.
-	    </h:p>
-	  </description>
-	</Group>
-      </Group>
-    </Group>
-    <Group id="xccdf_org.gentoo.dev.swift_group_system-portage">
-      <title>Portage settings</title>
-      <description>
-        <h:p>
-        The package manager of any system is a very important tool. It is
-        responsible for handling proper software deployments, but also offers
-        features that should not be neglected, like security patch roll-out.
-	</h:p>
-	<h:p>
-        For Gentoo, the package manager offers a great deal of flexibility (as
-        that is the goal of Gentoo anyhow). As such, good settings for a more
-        secure environment within Portage (assuming that Portage is used as
-        package manager) are important.
-	</h:p>
-      </description>
-      <Group id="xccdf_org.gentoo.dev.swift_group_system-portage-use">
-        <title>USE flags</title>
-        <description>
-	  <h:p>
-          USE flags in Gentoo are used to tune the functionality of many
-          components and enable or disable features.
-	  </h:p>
-	  <h:p>
-          For a well secured environment, there are a couple of USE flags that
-          should be set in a global manner. These USE flags are
-	  </h:p>
-          <h:ul>
-            <h:li>
-              <h:code>pam</h:code> to enable Pluggable Authentication
-              Modules support
-            </h:li>
-            <h:li>
-              <h:code>tcpd</h:code> for TCP wrappers support
-            </h:li>
-            <h:li>
-              <h:code>ssl</h:code> for SSL/TLS support
-            </h:li>
-          </h:ul>
-	  <h:p>
-          <h:b>Pluggable Authentication Modules</h:b> are a powerful mechanism
-          to manage authentication, authorization and user sessions.
-          Applications that support PAM can be tuned to the liking of the
-          organization, leveraging central authentication, password policies,
-          auditing and more.
-	  </h:p>
-	  <h:p>
-          With <h:b>TCP wrappers</h:b>, services can be shielded from
-          unauthorized access on host level. It is an access control level
-          mechanism which allows configuring allowed (and denied) hosts or
-          network segments on application level.
-	  </h:p>
-	  <h:p>
-          Finally, leveraging <h:b>Secure Sockets Layer</h:b> (or the
-          standardized <h:b>Transport Layer Security</h:b>) allows applications
-          to encrypt network communication or even implement a
-          client-certificate based authentication mechanism.
-	  </h:p>
-	  <h:p>
-          Set the USE flags globally in <h:code>/etc/portage/make.conf</h:code>
-          so they are applicable to all installed software.
-	  </h:p>
-          <h:pre>
+</fix>
+<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
+<check-content-ref name="oval:org.gentoo.dev.swift:def:21" href="gentoo-oval.xml" />
+</check>
+</Rule>
+
+<Rule id="xccdf_org.gentoo.dev.swift_rule_inittab-sulogin" selected="false" severity="medium" weight="6.0">
+<title>sulogin is used for single-user boot (/etc/inittab)</title>
+<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_inittab-sulogin">
+Set /sbin/sulogin or '/sbin/rc single' for single-user boot in /etc/inittab
+</fixtext>
+<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
+<check-content-ref name="oval:org.gentoo.dev.swift:def:22" href="gentoo-oval.xml" />
+</check>
+</Rule>
+
+</Group>
+
+<Group id="xccdf_org.gentoo.dev.swift_group_system-services-tcpwrappers">
+<title>Properly Configure TCP Wrappers</title>
+<description>
+<h:p>
+With TCP wrappers, services that support TCP wrappers (or those
+started through <h:b>xinetd</h:b>) should be configured to only accept
+communication with trusted hosts. With the use of
+<h:code>/etc/hosts.allow</h:code> and <h:code>/etc/hosts.deny</h:code>,
+proper access control lists can be created.
+</h:p>
+<h:p>
+More information on the format of these files can be obtained through
+<h:b>man 5 hosts_access</h:b>.
+</h:p>
+</description>
+
+<Rule id="xccdf_org.gentoo.dev.swift_rule_hostsallow-exists" selected="false" severity="info" weight="0.0">
+<title>/etc/hosts.allow exists</title>
+<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_hostsallow-exists">
+Create and properly configure /etc/hosts.allow
+</fixtext>
+<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
+<check-content-ref name="oval:org.gentoo.dev.swift:def:23" href="gentoo-oval.xml" />
+</check>
+</Rule>
+
+</Group>
+
+<Group id="xccdf_org.gentoo.dev.swift_group_system-services-ssh">
+<title>SSH service</title>
+<description>
+<h:p>
+The SSH service is used for secure remote access towards a system, but
+also to provide secure file transfers. It is very commonly found on Unix/Linux
+systems so proper hardening is definitely in place.
+</h:p>
+<h:p>
+Please use the "Hardening OpenSSH" guide for the necessary instructions.
+</h:p>
+</description>
+</Group>
+
+<Group id="xccdf_org.gentoo.dev.swift_group_system-services-cron">
+<title>Cron service</title>
+<description>
+A cron service is used to schedule tasks and processes on predefined
+times. Cron is most often used for regular maintenance tasks.
+</description>
+<Group id="xccdf_org.gentoo.dev.swift_group_system-services-cron-acl">
+<title>Only allow trusted accounts cron access</title>
+<description>
+<h:p>
+Only allow trusted accounts to use cron. How to achieve this depends on the cron service
+installed.
+</h:p>
+<h:p>
+If vixie-cron or cronie is installed, then have (only) those users that need cron access
+take part in the <h:em>cron</h:em> unix group. 
+</h:p>
+<h:p>
+If dcron is used, then make sure <h:code>/usr/sbin/crontab</h:code> is only executable by
+root and the cron unix group, and make sure (only) those users that need cron access take part
+in the <h:em>cron</h:em> unix group.
+</h:p>
+</description>
+</Group>
+
+</Group>
+
+<Group id="xccdf_org.gentoo.dev.swift_group_system-services-at">
+<title>At service</title>
+<description>
+The at service allows users to execute a task once on a given time.
+Unlike cron, this is not scheduled repeatedly - once executed, the
+task is considered completed and at will not invoke it again.
+</description>
+
+<Group id="xccdf_org.gentoo.dev.swift_group_system-services-at-acl">
+<title>Only allow trusted accounts at access</title>
+<description>
+<h:p>
+Only allow trusted accounts to use at. Unlike cron access, at access is governed through
+the <h:code>/etc/at/at.allow</h:code> file. If the <h:code>at.allow</h:code> file does not
+exist but <h:code>/etc/at/at.deny</h:code> does, then all names <h:em>not</h:em> mentioned in
+the file are allowed to run at. The most secure method is to use the <h:code>at.allow</h:code>
+method.
+</h:p>
+<h:p>
+The format of these files is one username per line.
+</h:p>
+</description>
+
+<Rule id="xccdf_org.gentoo.dev.swift_rule_atallow-exists" selected="false" severity="low" weight="0.0">
+<title>/etc/at/at.allow exists</title>
+<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_atsallow-exists">
+Create and properly configure /etc/at/at.allow
+</fixtext>
+<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
+<check-content-ref name="oval:org.gentoo.dev.swift:def:24" href="gentoo-oval.xml" />
+</check>
+</Rule>
+
+</Group>
+
+</Group>
+
+<Group id="xccdf_org.gentoo.dev.swift_group_system-services-ntp">
+<title>NTP service</title>
+<description>
+<h:p>
+With NTP, systems can synchronise their clocks, ensuring correct date
+and time information. This is important as huge clock drift could
+cause misinterpretation of log files or even unwanted execution of
+commands.
+</h:p>
+</description>
+
+<Group id="xccdf_org.gentoo.dev.swift_group_system-services-ntp-sync">
+<title>Synchronise the system clock</title>
+<description>
+<h:p>
+Synchronise the systems' clock with an authorative NTP server, and
+use the same NTP service for all other systems.
+</h:p>
+<h:p>
+This can be accomplished by regularly executing <h:b>ntpdate</h:b>,
+but can also be handled using a service like <h:code>net-misc/ntp</h:code>'s
+<h:b>ntpd</h:b>.
+</h:p>
+</description>
+</Group>
+
+</Group>
+
+<Group id="xccdf_org.gentoo.dev.swift_group_system-services-syslog">
+<title>Syslog service</title>
+<description>
+<h:p>
+The system logger handles all non-audit related logging generated by applications
+and daemons. In order to ensure proper forensic analysis if it would ever be needed,
+the system logger should be properly configured.
+</h:p>
+</description>
+
+<Group id="xccdf_org.gentoo.dev.swift_group_system-services-syslog-logintervals">
+<title>Configure the system logger to log intervals</title>
+<description>
+<h:p>
+Have the system logger log every 10 minutes or so. Without interval logging,
+administrators might think nothing is wrong although in reality the system
+logger is malfunctioning and not writing any log events.
+</h:p>
+</description>
+</Group>
+
+<Group id="xccdf_org.gentoo.dev.swift_group_system-services-syslog-remotelogging">
+<title>Enable remote logging</title>
+<description>
+<h:p>
+If possible, have vital (or all) logs sent to a remote system logger as well.
+In home deployments, off-the-shelf (wifi) routers often have a logging daemon
+that can receive syslog events. For larger environments, a dedicated centralized
+log server is recommended.
+</h:p>
+</description>
+</Group>
+
+<Group id="xccdf_org.gentoo.dev.swift_group_system-services-syslog-terminal">
+<title>Decide which events to send to user terminals</title>
+<description>
+<h:p>
+On Linux and Unix systems, events can be sent to user terminals to
+make those users immediately aware of what is happening. It is
+recommended to send emergency-level events to everyone and have
+alerts sent to specific administrative user terminals.
+</h:p>
+</description>
+</Group>
+
+</Group>
+
+</Group>
+
+<Group id="xccdf_org.gentoo.dev.swift_group_system-portage">
+<title>Portage settings</title>
+<description>
+<h:p>
+The package manager of any system is a very important tool. It is
+responsible for handling proper software deployments, but also offers
+features that should not be neglected, like security patch roll-out.
+</h:p>
+<h:p>
+For Gentoo, the package manager offers a great deal of flexibility (as
+that is the goal of Gentoo anyhow). As such, good settings for a more
+secure environment within Portage (assuming that Portage is used as
+package manager) are important.
+</h:p>
+</description>
+
+<Group id="xccdf_org.gentoo.dev.swift_group_system-portage-use">
+<title>USE flags</title>
+<description>
+<h:p>
+USE flags in Gentoo are used to tune the functionality of many
+components and enable or disable features.
+</h:p>
+<h:p>
+For a well secured environment, there are a couple of USE flags that
+should be set in a global manner. These USE flags are
+</h:p>
+<h:ul>
+<h:li>
+<h:code>pam</h:code> to enable Pluggable Authentication
+Modules support
+</h:li>
+<h:li>
+<h:code>tcpd</h:code> for TCP wrappers support
+</h:li>
+<h:li>
+<h:code>ssl</h:code> for SSL/TLS support
+</h:li>
+</h:ul>
+<h:p>
+<h:b>Pluggable Authentication Modules</h:b> are a powerful mechanism
+to manage authentication, authorization and user sessions.
+Applications that support PAM can be tuned to the liking of the
+organization, leveraging central authentication, password policies,
+auditing and more.
+</h:p>
+<h:p>
+With <h:b>TCP wrappers</h:b>, services can be shielded from
+unauthorized access on host level. It is an access control level
+mechanism which allows configuring allowed (and denied) hosts or
+network segments on application level.
+</h:p>
+<h:p>
+Finally, leveraging <h:b>Secure Sockets Layer</h:b> (or the
+standardized <h:b>Transport Layer Security</h:b>) allows applications
+to encrypt network communication or even implement a
+client-certificate based authentication mechanism.
+</h:p>
+<h:p>
+Set the USE flags globally in <h:code>/etc/portage/make.conf</h:code>
+so they are applicable to all installed software.
+</h:p>
+<h:pre>
 USE="... pam tcpd ssl"</h:pre>
-        </description>
-        <Rule id="xccdf_org.gentoo.dev.swift_rule_USE-pam" selected="false" severity="low" weight="0.0">
-          <title>USE="pam" is set</title>
-          <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_USE-pam">
-	    Edit /etc/portage/make.conf and make sure that 'pam' is in the USE declaration
-          </fixtext>
-          <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
-            <check-content-ref name="oval:org.gentoo.dev.swift:def:27" href="gentoo-oval.xml" />
-          </check>
-        </Rule>
-        <Rule id="xccdf_org.gentoo.dev.swift_rule_USE-tcpd" selected="false" severity="low" weight="0.0">
-          <title>USE="tcpd" is set</title>
-          <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_USE-tcpd">
-	    Edit /etc/portage/make.conf and make sure that 'tcpd' is in the USE declaration
-          </fixtext>
-          <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
-            <check-content-ref name="oval:org.gentoo.dev.swift:def:28" href="gentoo-oval.xml" />
-          </check>
-        </Rule>
-        <Rule id="xccdf_org.gentoo.dev.swift_rule_USE-ssl" selected="false" severity="low" weight="0.0">
-          <title>USE="ssl" is set</title>
-          <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_USE-ssl">
-	    Edit /etc/portage/make.conf and make sure that 'ssl' is in the USE declaration
-          </fixtext>
-          <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
-            <check-content-ref name="oval:org.gentoo.dev.swift:def:29" href="gentoo-oval.xml" />
-          </check>
-        </Rule>
-      </Group>
-      <Group id="xccdf_org.gentoo.dev.swift_group_system-portage-webrsync">
-        <title>Fetching signed portage tree</title>
-        <description>
-	  <h:p>
-          Gentoo Portage supports fetching signed tree snapshots using
-          <h:b>emerge-webrsync</h:b>. This is documented in the Gentoo Handbook,
-          but as it is quite easy, here are the instructions again:
-	  </h:p>
-          <h:pre>
+</description>
+
+<Rule id="xccdf_org.gentoo.dev.swift_rule_USE-pam" selected="false" severity="low" weight="0.0">
+<title>USE="pam" is set</title>
+<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_USE-pam">
+Edit /etc/portage/make.conf and make sure that 'pam' is in the USE declaration
+</fixtext>
+<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
+<check-content-ref name="oval:org.gentoo.dev.swift:def:27" href="gentoo-oval.xml" />
+</check>
+</Rule>
+
+<Rule id="xccdf_org.gentoo.dev.swift_rule_USE-tcpd" selected="false" severity="low" weight="0.0">
+<title>USE="tcpd" is set</title>
+<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_USE-tcpd">
+Edit /etc/portage/make.conf and make sure that 'tcpd' is in the USE declaration
+</fixtext>
+<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
+<check-content-ref name="oval:org.gentoo.dev.swift:def:28" href="gentoo-oval.xml" />
+</check>
+</Rule>
+
+<Rule id="xccdf_org.gentoo.dev.swift_rule_USE-ssl" selected="false" severity="low" weight="0.0">
+<title>USE="ssl" is set</title>
+<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_USE-ssl">
+Edit /etc/portage/make.conf and make sure that 'ssl' is in the USE declaration
+</fixtext>
+<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
+<check-content-ref name="oval:org.gentoo.dev.swift:def:29" href="gentoo-oval.xml" />
+</check>
+
+</Rule>
+
+</Group>
+
+<Group id="xccdf_org.gentoo.dev.swift_group_system-portage-webrsync">
+<title>Fetching signed portage tree</title>
+<description>
+<h:p>
+Gentoo Portage supports fetching signed tree snapshots using
+<h:b>emerge-webrsync</h:b>. This is documented in the Gentoo Handbook,
+but as it is quite easy, here are the instructions again:
+</h:p>
+<h:pre>
 # <h:b>mkdir -p /etc/portage/gpg</h:b>
 # <h:b>chmod 0700 /etc/portage/gpg</h:b>
 # <h:b>export SRV="subkeys.pgp.net"</h:b>
 # <h:b>export KEY="0x96D8BF6D"</h:b>
 # <h:b>gpg --homedir /etc/portage/gpg --keyserver ${SRV} --recv-keys ${KEY}</h:b>
 # <h:b>gpg --homedir /etc/portage/gpg --edit-key ${KEY} trust</h:b></h:pre>
-          <h:p>
-          After this, edit <h:code>/etc/portage/make.conf</h:code>:
-	  </h:p>
-          <h:pre>
+<h:p>
+After this, edit <h:code>/etc/portage/make.conf</h:code>:
+</h:p>
+<h:pre>
 FEATURES="webrsync-gpg"
 PORTAGE_GPG_DIR="/etc/portage/gpg"
 </h:pre>
-          <h:p>
-	  In the repository configuration (<h:code>/etc/portage/repos.conf</h:code> or a 
-	  file inside it) <h:code>sync-uri</h:code> has to be commented out, or set to an
-	  empty value.
-	  </h:p>
-        </description>
-	<Rule id="xccdf_org.gentoo.dev.swift_rule_FEATURES-webrsync-gpg" selected="false" severity="low" weight="0.0">
-	  <title>FEATURES="webrsync-gpg" is set</title>
-	  <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_FEATURES-webrsync-gpg">
-	    Edit /etc/portage/make.conf and make sure that 'webrsync-gpg' is in the FEATURES declaration.
-	  </fixtext>
-	  <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
-	    <check-content-ref name="oval:org.gentoo.dev.swift:def:30" href="gentoo-oval.xml" />
-	  </check>
-	</Rule>
-        <Rule id="xccdf_org.gentoo.dev.swift_rule_PORTAGE_GPG_DIR-nonempty" selected="false" severity="low" weight="0.0">
-	  <title>PORTAGE_GPG_DIR is set</title>
-	  <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_PORTAGE_GPG_DIR-nonempty">
-	    Edit /etc/portage/make.conf and make sure that PORTAGE_GPG_DIR is set correctly.
-	  </fixtext>
-	  <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
-	    <check-content-ref name="oval:org.gentoo.dev.swift:def:31" href="gentoo-oval.xml" />
-	  </check>
-	</Rule>
-
-      </Group>
-    </Group>
-    <Group id="xccdf_org.gentoo.dev.swift_group_system-kernel">
-      <title>Kernel configuration</title>
-      <description>
-        <h:p>
-        The Linux kernel should be configured using a sane security standard in
-        mind. When using grSecurity, additional security-enhancing settings can
-        be enabled.
-	</h:p>
-	<h:p>
-        For further details, please refer to the "Hardening the Linux kernel" guide.
-	</h:p>
-      </description>
-      <reference href="http://www.gentoo.org/doc/en/kernel-config.xml#shorthand">Gentoo Kernel Configuration Guide - Shorthand notation information</reference>
-    </Group>
-    <Group id="xccdf_org.gentoo.dev.swift_group_system-bootloader">
-      <title>Bootloader configuration</title>
-      <description>
-        <h:p>
-        The bootloader (be it GRUB or another tool) is responsible for loading
-        the Linux kernel and handing over system control to the kernel. But boot
-        loaders also allow for a flexible approach on kernel loading, which can
-        be (ab)used to work around security mechanisms.
-	</h:p>
-      </description>
-      <Group id="xccdf_org.gentoo.dev.swift_group_system-bootloader-grub2pass">
-        <title>Password protect GRUB 2</title>
-	<description>
-	  <h:p>
-	  It is recommended to password-protect the GRUB configuration so that the
-	  boot options cannot be modified during a boot without providing the valid
-	  password.
-	  </h:p>
-	  <h:p>
-	  TODO looks like this has become a lot more difficult to obtain
-	  </h:p>
-	</description>
-	<reference href="https://help.ubuntu.com/community/Grub2/Passwords">GRUB2 Passwords (Ubuntu wiki)</reference>
-      </Group>
-      <Group id="xccdf_org.gentoo.dev.swift_group_system-bootloader-grub1pass">
-        <title>Password protect GRUB (legacy)</title>
-        <description>
-	  <h:p>
-          It is recommended to password-protect the GRUB configuration so that
-          the boot options cannot be modified during a boot without providing the
-          valid password.
-	  </h:p>
-	  <h:p>
-          This can be accomplished by inserting <h:code>password abc123</h:code>
-          in <h:code>/boot/grub/grub.conf</h:code> (which will set the password
-          to "abc123"). But as clear-text passwords in the configuration file are insecure as well,
-          hash the passwords. Just start <h:b>grub</h:b>
-          and, in the grub-shell, type <h:b>md5crypt</h:b>.
-	  </h:p>
-          <h:pre>
-# <h:b>grub</h:b>
+<h:p>
+In the repository configuration (<h:code>/etc/portage/repos.conf</h:code> or a 
+file inside it) <h:code>sync-uri</h:code> has to be commented out, or set to an
+empty value.
+</h:p>
+</description>
 
-GRUB version 0.92 (640K lower / 3072K upper memory)
+<Rule id="xccdf_org.gentoo.dev.swift_rule_FEATURES-webrsync-gpg" selected="false" severity="low" weight="0.0">
+<title>FEATURES="webrsync-gpg" is set</title>
+<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_FEATURES-webrsync-gpg">
+Edit /etc/portage/make.conf and make sure that 'webrsync-gpg' is in the FEATURES declaration.
+</fixtext>
+<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
+<check-content-ref name="oval:org.gentoo.dev.swift:def:30" href="gentoo-oval.xml" />
+</check>
+</Rule>
 
-[ Minimal BASH-like line editing is supported. ... ]
+<Rule id="xccdf_org.gentoo.dev.swift_rule_PORTAGE_GPG_DIR-nonempty" selected="false" severity="low" weight="0.0">
+<title>PORTAGE_GPG_DIR is set</title>
+<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_PORTAGE_GPG_DIR-nonempty">
+Edit /etc/portage/make.conf and make sure that PORTAGE_GPG_DIR is set correctly.
+</fixtext>
+<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
+<check-content-ref name="oval:org.gentoo.dev.swift:def:31" href="gentoo-oval.xml" />
+</check>
+</Rule>
 
-grub&gt; <h:b>md5crypt</h:b>
+</Group>
 
-Password: <h:em>abc123</h:em>
-Encrypted: $1$18u.M0$J8VbOsGXuoG9Fh3n7ZkqY.
+</Group>
 
-grub&gt; <h:b>quit</h:b></h:pre>
-          <h:p>
-          This hashed password can now be used in <h:code>grub.conf</h:code>
-          using <h:code>password --md5 $1$18u.M0$J8VbOsGXuoG9Fh3n7ZkqY.</h:code>.
-	  </h:p>
-        </description>
-        <Rule id="xccdf_org.gentoo.dev.swift_rule_grubconf-password-md5" selected="false" severity="low" weight="6.9">
-	  <title>Grub legacy (if it exists) has a password entry with md5 hash</title>
-	  <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_grubconf-password-md5">
-	    Edit /boot/grub/grub.conf and set a password entry with md5 hash
-	  </fixtext>
-	  <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
-	    <check-content-ref name="oval:org.gentoo.dev.swift:def:34" href="gentoo-oval.xml" />
-	  </check>
-	</Rule>
-      </Group>
-      <Group id="xccdf_org.gentoo.dev.swift_group_system-bootloader-lilopass">
-        <title>Password protect LILO</title>
-        <description>
-	  <h:p>
-          It is recommended to password-protect the LILO configuration so that
-          modifying the boot options during a boot without providing the
-          valid password is not possible.
-	  </h:p>
-	  <h:p>
-          This can be accomplished  by inserting <h:code>password=abc123</h:code>
-          followed by <h:code>restricted</h:code> in the
-          <h:code>/etc/lilo.conf</h:code> file. It is also possible to do this
-          on a per-image level.
-	  </h:p>
-          <h:pre>
-password=abc123
-restricted
-delay=3
+<Group id="xccdf_org.gentoo.dev.swift_group_system-kernel">
+<title>Kernel configuration</title>
+<description>
+<h:p>
+The Linux kernel should be configured using a sane security standard in
+mind. When using grSecurity, additional security-enhancing settings can
+be enabled.
+</h:p>
+<h:p>
+For further details, please refer to the "Hardening the Linux kernel" guide.
+</h:p>
+</description>
+<reference href="http://www.gentoo.org/doc/en/kernel-config.xml#shorthand">Gentoo Kernel Configuration Guide - Shorthand notation information</reference>
+</Group>
 
-image=/boot/bzImage
-        read-only
-        password=def456
-        restricted</h:pre>
-	   <h:p>
-           The <h:code>restricted</h:code> keyword is needed to have LILO only
-           ask for the password if a modification is given. If the defaults are
-           used, then no password needs to be provided.
-	   </h:p>
-	   <h:p>
-           Rerun <h:code>lilo</h:code> after updating the configuration file.
-	   </h:p>
-        </description>
-        <Rule id="xccdf_org.gentoo.dev.swift_rule_liloconf-password" selected="false" severity="low" weight="6.9">
-	  <title>LILO (if it exists) has a password entry</title>
-	  <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_liloconf-password">
-	    Edit /etc/lilo.conf and set a password entry
-	  </fixtext>
-	  <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
-	    <check-content-ref name="oval:org.gentoo.dev.swift:def:35" href="gentoo-oval.xml" />
-	  </check>
-	</Rule>
-      </Group>
-    </Group>
-    <Group id="xccdf_org.gentoo.dev.swift_group_system-auth">
-      <title>Authentication and authorization settings</title>
-      <description>
-        <h:p>
-        An important part in a servers' security is its authentication and
-        authorization support. We have already described how to build in PAM
-        support (through the Portage USE flags), but proper authentication and
-        authorization settings are mode than just compiling in the necessary
-        functionality.
-	</h:p>
-      </description>
-      <Group id="xccdf_org.gentoo.dev.swift_group_system-auth-securetty">
-        <title>Restrict root system logon</title>
-        <description>
-	  <h:p>
-          To restrict where the root user can directly log on, edit
-          <h:code>/etc/securetty</h:code> and specify the supported terminals
-          for the root user.
-	  </h:p>
-	  <h:p>
-          When properly configured, any attempt to log on as the root user from
-          a non-defined terminal will result in logon failure.
-	  </h:p>
-	  <h:p>
-          A recommended setting is to only allow root user login through the
-          console and the physical terminals (<h:code>tty0-tty12</h:code>).
-	  </h:p>
-          <h:pre>
+<Group id="xccdf_org.gentoo.dev.swift_group_system-auth">
+<title>Authentication and authorization settings</title>
+<description>
+<h:p>
+An important part in a servers' security is its authentication and
+authorization support. We have already described how to build in PAM
+support (through the Portage USE flags), but proper authentication and
+authorization settings are mode than just compiling in the necessary
+functionality.
+</h:p>
+</description>
+
+<Group id="xccdf_org.gentoo.dev.swift_group_system-auth-securetty">
+<title>Restrict root system logon</title>
+<description>
+<h:p>
+To restrict where the root user can directly log on, edit
+<h:code>/etc/securetty</h:code> and specify the supported terminals
+for the root user.
+</h:p>
+<h:p>
+When properly configured, any attempt to log on as the root user from
+a non-defined terminal will result in logon failure.
+</h:p>
+<h:p>
+A recommended setting is to only allow root user login through the
+console and the physical terminals (<h:code>tty0-tty12</h:code>).
+</h:p>
+<h:pre>
 console
 tty0
 tty1
 ...
 tty12</h:pre>
-        </description>
-        <Rule id="xccdf_org.gentoo.dev.swift_rule_securetty-limitentries" selected="false" severity="low" weight="0.0">
-	  <title>/etc/securetty is limited to console and tty's</title>
-	  <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_securetty-limitentries">
-	    Edit /etc/securetty and make sure only 'console' and 'tty[0-9]*' are defined.
-	  </fixtext>
-	  <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
-	    <check-content-ref name="oval:org.gentoo.dev.swift:def:32" href="gentoo-oval.xml" />
-	  </check>
-	</Rule>
-      </Group>
-      <Group id="xccdf_org.gentoo.dev.swift_group_system-auth-userlogin">
-        <title>Allow only known users to login</title>
-        <description>
-	  <h:p>
-          When PAM is enabled, the <h:code>/etc/security/access.conf</h:code>
-          file is used to check which users are allowed to log on and not
-          (through the <h:b>login</h:b> application). These limits are based on
-          username, group and host, network or tty that the user is trying to
-          log on from.
-	  </h:p>
-	  <h:p>
-          By enabling these settings, the risk is reduced that a functional
-          account (say <h:code>apache</h:code>) is abused to log on with, or
-          that a new account is created as part of an exploit.
-	  </h:p>
-	  <h:p>
-	  The following example setting allows only local root logins on tty1,
-	  and only the <h:em>swift</h:em> account to log on on the system.
-	  </h:p>
-	  <h:pre>
+</description>
+
+<Rule id="xccdf_org.gentoo.dev.swift_rule_securetty-limitentries" selected="false" severity="low" weight="0.0">
+<title>/etc/securetty is limited to console and tty's</title>
+<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_securetty-limitentries">
+Edit /etc/securetty and make sure only 'console' and 'tty[0-9]*' are defined.
+</fixtext>
+<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
+<check-content-ref name="oval:org.gentoo.dev.swift:def:32" href="gentoo-oval.xml" />
+</check>
+</Rule>
+
+</Group>
+
+<Group id="xccdf_org.gentoo.dev.swift_group_system-auth-userlogin">
+<title>Allow only known users to login</title>
+<description>
+<h:p>
+When PAM is enabled, the <h:code>/etc/security/access.conf</h:code>
+file is used to check which users are allowed to log on and not
+(through the <h:b>login</h:b> application). These limits are based on
+username, group and host, network or tty that the user is trying to
+log on from.
+</h:p>
+<h:p>
+By enabling these settings, the risk is reduced that a functional
+account (say <h:code>apache</h:code>) is abused to log on with, or
+that a new account is created as part of an exploit.
+</h:p>
+<h:p>
+The following example setting allows only local root logins on tty1,
+and only the <h:em>swift</h:em> account to log on on the system.
+</h:p>
+<h:pre>
 + : root : tty1
 - : ALL EXCEPT swift : ALL
-          </h:pre>
-        </description>
-      </Group>
-      <Group id="xccdf_org.gentoo.dev.swift_group_system-auth-resources">
-        <title>Restrict user resources</title>
-        <description>
-	  <h:p>
-          When facing a DoS (Denial-of-Service) attack, reducing the impact of
-          the attack can be done by limited resource consumption. Although the
-          component that is under attack will even more quickly fail, the impact
-          towards the other services on the system (including remote logon to
-          fix things) is more limited.
-	  </h:p>
-	  <h:p>
-          In Gentoo Linux, the following methods are available to limit
-          resources.
-	  </h:p>
-          <h:ul>
-            <h:li>
-              <h:code>/etc/security/limits.conf</h:code> defines the
-              resource limits for logins that are done through a PAM-aware
-              component (default in our setup)
-            </h:li>
-            <h:li>
-              <h:code>/etc/limits</h:code> defines the resource limits for
-              logins that are done through login programs that are not
-              PAM-aware.
-            </h:li>
-          </h:ul>
-	  <h:p>
-          Generally, it should suffice to set up
-          <h:code>/etc/security/limits.conf</h:code>, which is the configuration
-          file used by the <h:code>pam_limits.so</h:code> module.
-	  </h:p>
-	  <h:p>
-          Note that the settings are applicable on a <h:em>per login
-          session</h:em> basis.
-	  </h:p>
-	  <h:p>
-          More information on these files and their syntax can be obtained
-          through their manual pages.
-	  </h:p>
-          <h:pre>
+</h:pre>
+</description>
+</Group>
+
+<Group id="xccdf_org.gentoo.dev.swift_group_system-auth-resources">
+<title>Restrict user resources</title>
+<description>
+<h:p>
+When facing a DoS (Denial-of-Service) attack, reducing the impact of
+the attack can be done by limited resource consumption. Although the
+component that is under attack will even more quickly fail, the impact
+towards the other services on the system (including remote logon to
+fix things) is more limited.
+</h:p>
+<h:p>
+In Gentoo Linux, the following methods are available to limit
+resources.
+</h:p>
+<h:ul>
+<h:li>
+<h:code>/etc/security/limits.conf</h:code> defines the
+resource limits for logins that are done through a PAM-aware
+component (default in our setup)
+</h:li>
+<h:li>
+<h:code>/etc/limits</h:code> defines the resource limits for
+logins that are done through login programs that are not
+PAM-aware.
+</h:li>
+</h:ul>
+<h:p>
+Generally, it should suffice to set up
+<h:code>/etc/security/limits.conf</h:code>, which is the configuration
+file used by the <h:code>pam_limits.so</h:code> module.
+</h:p>
+<h:p>
+Note that the settings are applicable on a <h:em>per login
+session</h:em> basis.
+</h:p>
+<h:p>
+More information on these files and their syntax can be obtained
+through their manual pages.
+</h:p>
+<h:pre>
 # <h:b>man limits.conf</h:b>
 # <h:b>man limits</h:b></h:pre>
-        </description>
-      </Group>
-      <Group id="xccdf_org.gentoo.dev.swift_group_system-auth-password">
-        <title>Enforce password policy</title>
-        <description>
-	  <h:p>
-          Usually most organizations have a password policy, telling their users
-          how long their passwords should be and how often the passwords should
-          be changed. Most users see this as an annoying aspect, so it might be
-          best to enforce this policy.
-	  </h:p>
-	  <h:p>
-          Enforcing password policies is (partially) part of the
-          <h:code>sys-apps/shadow</h:code> package (which is installed by
-          default) and can be configured through the
-          <h:code>/etc/login.defs</h:code> file. This file is well documented
-          (using comments) and it has a full manual page as well.
-	  </h:p>
-	  <h:p>
-          A second important player when dealing with password policies is the
-          <h:code>pam_cracklib.so</h:code> library. This can be used in the
-          appropriate <h:code>/etc/pam.d/*</h:code> files. For instance, for the
-          <h:code>/etc/pam.d/passwd</h:code> definition:
-	  </h:p>
-          <h:pre>
+</description>
+</Group>
+
+<Group id="xccdf_org.gentoo.dev.swift_group_system-auth-password">
+<title>Enforce password policy</title>
+<description>
+<h:p>
+Usually most organizations have a password policy, telling their users
+how long their passwords should be and how often the passwords should
+be changed. Most users see this as an annoying aspect, so it might be
+best to enforce this policy.
+</h:p>
+<h:p>
+Enforcing password policies is (partially) part of the
+<h:code>sys-apps/shadow</h:code> package (which is installed by
+default) and can be configured through the
+<h:code>/etc/login.defs</h:code> file. This file is well documented
+(using comments) and it has a full manual page as well.
+</h:p>
+<h:p>
+A second important player when dealing with password policies is the
+<h:code>pam_cracklib.so</h:code> library. This can be used in the
+appropriate <h:code>/etc/pam.d/*</h:code> files. For instance, for the
+<h:code>/etc/pam.d/passwd</h:code> definition:
+</h:p>
+<h:pre>
 auth     required pam_unix.so shadow nullok
 account  required pam_unix.so
 <h:b>password required pam_cracklib.so difok=3 retry=3 \
-                                  minlen=8 dcredit=-2 \
-				  ocredit=-2</h:b>
+minlen=8 dcredit=-2 \
+ocredit=-2</h:b>
 password required pam_unix.so md5 use_authok
 session  required pam_unix.so</h:pre>
-          <h:p>
-          In the above example, the password is required to be at least 8
-          characters long, differ more than 3 characters from the previous
-          password, contain 2 digits and 2 non-alphanumeric characters.
-	  </h:p>
-        </description>
-      </Group>
-      <Group id="xccdf_org.gentoo.dev.swift_group_system-auth-ripper">
-        <title>Review password strength regularly</title>
-        <description>
-	  <h:p>
-          Regularly check the strength of the users' passwords. There are tools
-          out there, like <h:code>app-crypt/johntheripper</h:code> which, given
-          a <h:code>/etc/shadow</h:code> file (or sometimes even LDAP dump) try
-          to find the passwords for the users.
-	  </h:p>
-	  <h:p>
-          When such a tool can guess a users' password, that users' password
-          should be expired and the user should be notified and asked to change
-          his password.
-	  </h:p>
-        </description>
-      </Group>
-    </Group>
-    <Group id="xccdf_org.gentoo.dev.swift_group_system-session">
-      <title>Session settings</title>
-      <description>
-        <h:p>
-        Unlike authentication and authorization settings, a <h:em>session</h:em>
-        setting is one that is applicable to an authenticated and authorized
-        user when he is logged on to the system.
-	</h:p>
-      </description>
-      <Group id="xccdf_org.gentoo.dev.swift_group_system-session-mesg">
-        <title>Disable access to user terminals</title>
-        <description>
-	  <h:p>
-          By default, user terminals are accessible by others to write messages
-          to (using <h:b>write</h:b>, <h:b>wall</h:b> or <h:b>talk</h:b>). It is
-          adviseable to disable this unless explicitly necessary.
-	  </h:p>
-	  <h:p>
-          Messages can confuse users and trick them into performing malicious
-          actions. 
-	  </h:p>
-	  <h:p>
-          This can be disabled by setting <h:code>mesg n</h:code> in
-          <h:code>/etc/profile</h:code>. A user-friendly method for doing so in
-          Gentoo is to create a file <h:code>/etc/profile.d/disable_mesg</h:code> which
-          contains this command.
-	  </h:p>
-        </description>
-      </Group>
-    </Group>
-    <Group id="xccdf_org.gentoo.dev_group_system-fileprivileges">
-      <title>File and directory privileges and integrity</title>
-      <description>
-        Proper privileges on files makes it far more difficult to malicious
-        users to obtain sensitive information or write/update files they should
-        not have access to.
-      </description>
-      <Group id="xccdf_org.gentoo.dev.swift_group_system-fileprivileges-worldrw">
-        <title>Limit world writable files and locations</title>
-        <description>
-	  <h:p>
-          Limit (or even remove) the use of world writable files and locations.
-          If a directory is world writable, it makes sense to have the
-          sticky bit set on it as well (like with <h:code>/tmp</h:code>).
-	  </h:p>
-	  <h:p>
-          Use <h:code>find</h:code> to locate such files or directories.
-	  </h:p>
-          <h:pre>
+<h:p>
+In the above example, the password is required to be at least 8
+characters long, differ more than 3 characters from the previous
+password, contain 2 digits and 2 non-alphanumeric characters.
+</h:p>
+</description>
+</Group>
+
+<Group id="xccdf_org.gentoo.dev.swift_group_system-auth-ripper">
+<title>Review password strength regularly</title>
+<description>
+<h:p>
+Regularly check the strength of the users' passwords. There are tools
+out there, like <h:code>app-crypt/johntheripper</h:code> which, given
+a <h:code>/etc/shadow</h:code> file (or sometimes even LDAP dump) try
+to find the passwords for the users.
+</h:p>
+<h:p>
+When such a tool can guess a users' password, that users' password
+should be expired and the user should be notified and asked to change
+his password.
+</h:p>
+</description>
+</Group>
+
+</Group>
+
+<Group id="xccdf_org.gentoo.dev.swift_group_system-session">
+<title>Session settings</title>
+<description>
+<h:p>
+Unlike authentication and authorization settings, a <h:em>session</h:em>
+setting is one that is applicable to an authenticated and authorized
+user when he is logged on to the system.
+</h:p>
+</description>
+<Group id="xccdf_org.gentoo.dev.swift_group_system-session-mesg">
+<title>Disable access to user terminals</title>
+<description>
+<h:p>
+By default, user terminals are accessible by others to write messages
+to (using <h:b>write</h:b>, <h:b>wall</h:b> or <h:b>talk</h:b>). It is
+adviseable to disable this unless explicitly necessary.
+</h:p>
+<h:p>
+Messages can confuse users and trick them into performing malicious
+actions. 
+</h:p>
+<h:p>
+This can be disabled by setting <h:code>mesg n</h:code> in
+<h:code>/etc/profile</h:code>. A user-friendly method for doing so in
+Gentoo is to create a file <h:code>/etc/profile.d/disable_mesg</h:code> which
+contains this command.
+</h:p>
+</description>
+</Group>
+
+</Group>
+
+<Group id="xccdf_org.gentoo.dev_group_system-fileprivileges">
+<title>File and directory privileges and integrity</title>
+<description>
+Proper privileges on files makes it far more difficult to malicious
+users to obtain sensitive information or write/update files they should
+not have access to.
+</description>
+
+<Group id="xccdf_org.gentoo.dev.swift_group_system-fileprivileges-worldrw">
+<title>Limit world writable files and locations</title>
+<description>
+<h:p>
+Limit (or even remove) the use of world writable files and locations.
+If a directory is world writable, it makes sense to have the
+sticky bit set on it as well (like with <h:code>/tmp</h:code>).
+</h:p>
+<h:p>
+Use <h:code>find</h:code> to locate such files or directories.
+</h:p>
+<h:pre>
 # <h:b>find / -perm +o=w ! \( -type d -perm +o=t \) ! -type l -print</h:b></h:pre>
-          <h:p>
-          The above command shows world writable files and locations, unless it
-          is a directory with the sticky bit set, or a symbolic link (whose
-          world writable privilege is not accessible anyhow).
-	  </h:p>
-        </description>
-        <Rule id="xccdf_org.gentoo.dev.swift_rule_worldwritedir-stickybit" selected="false" severity="medium" weight="4.3">
-	  <title>All world writable directories have the sticky bit set</title>
-	  <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_worldwritedirs-stickybit">
-	    Make sure all world-writable directories have the sticky bit set
-	  </fixtext>
-	  <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
-	    <check-content-ref name="oval:org.gentoo.dev.swift:def:36" href="gentoo-oval.xml" />
-	  </check>
-	</Rule>
-
-      </Group>
-      <Group id="xccdf_org.gentoo.dev.swift_group_system-fileprivileges-suidsgid">
-        <title>Limit setuid and setgid file and directory usage</title>
-        <description>
-	  <h:p>
-          The <h:em>setuid</h:em> and <h:em>setgid</h:em> flags for files and
-          directories can be used to work around authentication and
-          authorization measures taken on the system. So their use should be
-          carefully guarded.
-	  </h:p>
-	  <h:p>
-          In case of files, the setuid or setgid bit causes the application (if
-          the file is marked as executable) to run with the privileges of the
-          file owner (setuid) or group owner (setgid). It is necessary for
-          applications that need elevated privileges, like <h:b>su</h:b> or
-          <h:b>sudo</h:b>.
-	  </h:p>
-	  <h:p>
-          In case of directories, the setgit bit causes newly created
-          files in that directory to automatically be owned by the same group as
-          the mentioned (parent) directory.
-	  </h:p>
-        </description>
-      </Group>
-      <Group id="xccdf_org.gentoo.dev.swift_group_system-fileprivileges-caps">
-        <title>Limit capability enabled files</title>
-	<description>
-	  <h:p>
-	  Capabilities within Linux allow users to perform certain privileged tasks.
-	  </h:p>
-	  <h:p>
-	  Unlike <h:em>setuid</h:em> flags, the allowed privileges can be defined
-	  in a more granular approach (although one can still add in all possible
-	  capabilities and thus gain similar privileges as through <h:em>setuid</h:em>
-	  binaries).
-	  </h:p>
-	  <h:p>
-	  Files with particular capabilities set (through the <h:b>setcap</h:b>
-	  application) should be regularly reviewed. Capability-enabled files 
-	  can be found through the following command:
-	  </h:p>
-	  <h:pre>
+<h:p>
+The above command shows world writable files and locations, unless it
+is a directory with the sticky bit set, or a symbolic link (whose
+world writable privilege is not accessible anyhow).
+</h:p>
+</description>
+
+<Rule id="xccdf_org.gentoo.dev.swift_rule_worldwritedir-stickybit" selected="false" severity="medium" weight="4.3">
+<title>All world writable directories have the sticky bit set</title>
+<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_worldwritedirs-stickybit">
+Make sure all world-writable directories have the sticky bit set
+</fixtext>
+<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
+<check-content-ref name="oval:org.gentoo.dev.swift:def:36" href="gentoo-oval.xml" />
+</check>
+</Rule>
+
+</Group>
+
+<Group id="xccdf_org.gentoo.dev.swift_group_system-fileprivileges-suidsgid">
+<title>Limit setuid and setgid file and directory usage</title>
+<description>
+<h:p>
+The <h:em>setuid</h:em> and <h:em>setgid</h:em> flags for files and
+directories can be used to work around authentication and
+authorization measures taken on the system. So their use should be
+carefully guarded.
+</h:p>
+<h:p>
+In case of files, the setuid or setgid bit causes the application (if
+the file is marked as executable) to run with the privileges of the
+file owner (setuid) or group owner (setgid). It is necessary for
+applications that need elevated privileges, like <h:b>su</h:b> or
+<h:b>sudo</h:b>.
+</h:p>
+<h:p>
+In case of directories, the setgit bit causes newly created
+files in that directory to automatically be owned by the same group as
+the mentioned (parent) directory.
+</h:p>
+</description>
+</Group>
+
+<Group id="xccdf_org.gentoo.dev.swift_group_system-fileprivileges-caps">
+<title>Limit capability enabled files</title>
+<description>
+<h:p>
+Capabilities within Linux allow users to perform certain privileged tasks.
+</h:p>
+<h:p>
+Unlike <h:em>setuid</h:em> flags, the allowed privileges can be defined
+in a more granular approach (although one can still add in all possible
+capabilities and thus gain similar privileges as through <h:em>setuid</h:em>
+binaries).
+</h:p>
+<h:p>
+Files with particular capabilities set (through the <h:b>setcap</h:b>
+application) should be regularly reviewed. Capability-enabled files 
+can be found through the following command:
+</h:p>
+<h:pre>
 # <h:b>getcap -r /</h:b>
-          </h:pre>
-	</description>
-      </Group>
-      <Group id="xccdf_org.gentoo.dev.swift_group_system-fileprivileges-logs">
-        <title>Logs only readable by proper group</title>
-        <description>
-          No log file in <h:code>/var/log</h:code> should be world readable. Log
-          files should be limited by particular groups (either the group
-          representing the service, like <h:code>apache</h:code> or
-          <h:code>portage</h:code>, or a specific administrative group like
-          <h:code>wheel</h:code>).
-        </description>
-      </Group>
-      <Group id="xccdf_org.gentoo.dev.swift_group_system-fileprivileges-rootonly">
-        <title>Files only used by root should be root-only</title>
-        <description>
-	  <h:p>
-          Some files, like <h:code>/etc/shadow</h:code>, are meant to be read
-          (and perhaps modified) by root only. These files should never have
-          privileges for group- or others.
-	  </h:p>
-	  <h:p>
-          A nonexhaustive list of such files is:
-	  </h:p>
-          <h:ul>
-            <h:li>
-              <h:code>/etc/shadow</h:code> which contains account password
-              information (including password hashes)
-            </h:li>
-            <h:li>
-              <h:code>/etc/securetty</h:code> which contains the list of
-              terminals where root is allowed to log on from
-            </h:li>
-          </h:ul>
-        </description>
-      </Group>
-      <Group id="xccdf_org.gentoo.dev.swift_group_system-fileprivileges-hids">
-        <title>Review file integrity regularly</title>
-        <description>
-          Deploy intrusion detection tool(s) to validate the integrity and
-          privileges on important files. <h:code>app-forensics/aide</h:code> is
-          an example of such a tool.
-        </description>
-      </Group>
-    </Group> 
-  </Group> <!-- system -->
-  <Group id="xccdf_org.gentoo.dev.swift_group_data">
-    <title>Data flows</title>
-    <description>
-      Clearly map out how data flows in and out of the server (and which data
-      this is). This will be needed anyhow when firewalls are configured, but it
-      also improves integration of the server in a larger infrastructure.
-    </description>
-    <Group id="xccdf_org.gentoo.dev.swift_group_data-backup">
-      <title>Backup the data</title>
-      <description>
-        Make sure that the data is backed up. This is not only in case of
-        server loss, but also to protect against accidental file removal or an
-        awkward bug in a service that deleted important information.
-      </description>
-      <Group id="xccdf_org.gentoo.dev.swift_group_data-backup-automate">
-        <title>Automated backups</title>
-        <description>
-	  <h:p>
-          Automate backups on the system. If the backups are performed manually
-          then they are done wrong and someone will eventually forget it.
-	  </h:p>
-	  <h:p>
-          Use scheduling software like <h:code>cron</h:code> to
-          automatically take backups on regular intervals, or use a central
-          backup solution like <h:code>bacula</h:code>.
-	  </h:p>
-        </description>
-      </Group>
-      <Group id="xccdf_org.gentoo.dev.swift_group_data-backups-coverage">
-        <title>Full data coverage</title>
-        <description>
-          Many users that do take backups only do this on what they seem as
-          important files. However, it is wise to make full system backups too
-          as recreating an entire system from scratch could otherwise take days
-          or even weeks.
-        </description>
-      </Group>
-      <Group id="xccdf_org.gentoo.dev.swift_group_data-backups-history">
-        <title>Retention</title>
-        <description>
-	  <h:p>
-          Ensure that the backups use a long enough retention. It is not wise
-          to take a single backup and overwrite this one over and over again, as
-          there will be a time that a file needs to be recovered that was corrupted
-          long before the last backup was taken.
-	  </h:p>
-	  <h:p>
-          There is no perfect retention period however, as the more backups are 
-          kept, the more storage is required and the more money or time needs to be invested in
-          managing the backups.
-	  </h:p>
-	  <h:p>
-          In most cases, introduce a "layered" approach on retention. For instance:
-	  </h:p>
-          <h:ul>
-            <h:li>keep daily backups for a week</h:li>
-            <h:li>
-              keep weekly backups (say each monday backup) for a month
-            </h:li>
-            <h:li>
-              keep monthly backups (say each first monday) for a year
-            </h:li>
-            <h:li>
-              keep yearly backups for 30 years
-            </h:li>
-          </h:ul>
-        </description>
-      </Group>
-      <Group id="xccdf_org.gentoo.dev.swift_group_data-backups-location">
-        <title>Off-site backups</title>
-        <description>
-	  <h:p>
-          Keep the backups off-site in case of disaster. But consider this
-          location carefully. Investigate how fast the backup can be put there,
-          but also how fast it can be retrieved it in case of need. Also investigate if this
-          location is juridically sane (is it allowed to put the data on this location
-          and is this off-site location trusted).
-	  </h:p>
-	  <h:p>
-          Also ensure that the backups are stored securely. If necessary,
-          encrypt the backups.
-	  </h:p>
-        </description>
-      </Group>
-      <Group id="xccdf_org.gentoo.dev.swift_group_data-backups-validate">
-        <title>Validate and test</title>
-        <description>
-          Validate that the backup system works. Try recovering files (for
-          instance on a second server or different location) or even entire
-          systems (virtualization is a great help here) and do this regularly.
-        </description>
-      </Group>
-    </Group>
-  </Group> <!-- Data flows -->
-  <Group id="xccdf_org.gentoo.dev.swift_group_removal">
-    <title>Decommissioning servers</title>
-    <description>
-      When a server needs to be decommissioned, make sure that its data
-      is safeguarded from future extraction.
-    </description>
-    <Group id="xccdf_org.gentoo.dev.swift_group_removal-wipedisk">
-      <title>Wipe disks</title>
-      <description>
-        <h:p>
-        Clear all data from the disks on the server in a secure manner.
-        Applications like <h:b>shred</h:b> (part of
-        <h:code>sys-apps/coreutils</h:code>) can be used to security wipe data
-        or even entire partitions or disks.
-	</h:p>
-	<h:p>
-        It is recommended to perform full disk wipes rather than file wipes.
-        If this needs to be done on file level, see if the file system
-        journaling can be disabled during the wipe session as journaling might "buffer" the
-        secure writes and only write the end result to the disk.
-	</h:p>
-      </description>
-      <reference href="http://csrc.nist.gov/publications/nistpubs/800-88/NISTSP800-88_rev1.pdf">NIST Publication "Guidelines for Media Sanitization" (PDF)</reference>
-    </Group>
-  </Group> <!-- Removal -->
+</h:pre>
+</description>
+</Group>
+
+<Group id="xccdf_org.gentoo.dev.swift_group_system-fileprivileges-logs">
+<title>Logs only readable by proper group</title>
+<description>
+No log file in <h:code>/var/log</h:code> should be world readable. Log
+files should be limited by particular groups (either the group
+representing the service, like <h:code>apache</h:code> or
+<h:code>portage</h:code>, or a specific administrative group like
+<h:code>wheel</h:code>).
+</description>
+</Group>
+
+<Group id="xccdf_org.gentoo.dev.swift_group_system-fileprivileges-rootonly">
+<title>Files only used by root should be root-only</title>
+<description>
+<h:p>
+Some files, like <h:code>/etc/shadow</h:code>, are meant to be read
+(and perhaps modified) by root only. These files should never have
+privileges for group- or others.
+</h:p>
+<h:p>
+A nonexhaustive list of such files is:
+</h:p>
+<h:ul>
+<h:li>
+<h:code>/etc/shadow</h:code> which contains account password
+information (including password hashes)
+</h:li>
+<h:li>
+<h:code>/etc/securetty</h:code> which contains the list of
+terminals where root is allowed to log on from
+</h:li>
+</h:ul>
+</description>
+</Group>
+
+<Group id="xccdf_org.gentoo.dev.swift_group_system-fileprivileges-hids">
+<title>Review file integrity regularly</title>
+<description>
+Deploy intrusion detection tool(s) to validate the integrity and
+privileges on important files. <h:code>app-forensics/aide</h:code> is
+an example of such a tool.
+</description>
+</Group>
+
+</Group> 
+
+</Group> <!-- system -->
+
+<Group id="xccdf_org.gentoo.dev.swift_group_hardening">
+<title>Hardening and risk mitigation</title>
+<description>
+<h:p>
+This chapter focuses on additional hardening instructions and risk mitigation. Unlike the previous
+chapters, this one focuses on <h:em>additional software</h:em> and configuration concerns rather than
+tuning and tweaking existing ones.
+</h:p>
+</description>
+
+<Group id="xccdf_org.gentoo.dev.swift_group_hardening-secureboot">
+<title>SecureBoot</title>
+<description>
+<h:p>
+TODO
+</h:p>
+</description>
+</Group>
+
+<Group id="xccdf_org.gentoo.dev.swift_group_hardening-firewall">
+<title>Firewall</title>
+<description>
+<h:p>
+TODO: Firewall
+</h:p>
+</description>
+</Group>
+
+</Group>
+
+<Group id="xccdf_org.gentoo.dev.swift_group_data">
+<title>Data flows</title>
+<description>
+Clearly map out how data flows in and out of the server (and which data
+this is). This will be needed anyhow when firewalls are configured, but it
+also improves integration of the server in a larger infrastructure.
+</description>
+
+<Group id="xccdf_org.gentoo.dev.swift_group_data-backup">
+<title>Backup the data</title>
+<description>
+Make sure that the data is backed up. This is not only in case of
+server loss, but also to protect against accidental file removal or an
+awkward bug in a service that deleted important information.
+</description>
+
+<Group id="xccdf_org.gentoo.dev.swift_group_data-backup-automate">
+<title>Automated backups</title>
+<description>
+<h:p>
+Automate backups on the system. If the backups are performed manually
+then they are done wrong and someone will eventually forget it.
+</h:p>
+<h:p>
+Use scheduling software like <h:code>cron</h:code> to
+automatically take backups on regular intervals, or use a central
+backup solution like <h:code>bacula</h:code>.
+</h:p>
+</description>
+</Group>
+
+<Group id="xccdf_org.gentoo.dev.swift_group_data-backups-coverage">
+<title>Full data coverage</title>
+<description>
+Many users that do take backups only do this on what they seem as
+important files. However, it is wise to make full system backups too
+as recreating an entire system from scratch could otherwise take days
+or even weeks.
+</description>
+</Group>
+
+<Group id="xccdf_org.gentoo.dev.swift_group_data-backups-history">
+<title>Retention</title>
+<description>
+<h:p>
+Ensure that the backups use a long enough retention. It is not wise
+to take a single backup and overwrite this one over and over again, as
+there will be a time that a file needs to be recovered that was corrupted
+long before the last backup was taken.
+</h:p>
+<h:p>
+There is no perfect retention period however, as the more backups are 
+kept, the more storage is required and the more money or time needs to be invested in
+managing the backups.
+</h:p>
+<h:p>
+In most cases, introduce a "layered" approach on retention. For instance:
+</h:p>
+<h:ul>
+<h:li>keep daily backups for a week</h:li>
+<h:li>
+keep weekly backups (say each monday backup) for a month
+</h:li>
+<h:li>
+keep monthly backups (say each first monday) for a year
+</h:li>
+<h:li>
+keep yearly backups for 30 years
+</h:li>
+</h:ul>
+</description>
+</Group>
+
+<Group id="xccdf_org.gentoo.dev.swift_group_data-backups-location">
+<title>Off-site backups</title>
+<description>
+<h:p>
+Keep the backups off-site in case of disaster. But consider this
+location carefully. Investigate how fast the backup can be put there,
+but also how fast it can be retrieved it in case of need. Also investigate if this
+location is juridically sane (is it allowed to put the data on this location
+and is this off-site location trusted).
+</h:p>
+<h:p>
+Also ensure that the backups are stored securely. If necessary,
+encrypt the backups.
+</h:p>
+</description>
+</Group>
+
+<Group id="xccdf_org.gentoo.dev.swift_group_data-backups-validate">
+<title>Validate and test</title>
+<description>
+Validate that the backup system works. Try recovering files (for
+instance on a second server or different location) or even entire
+systems (virtualization is a great help here) and do this regularly.
+</description>
+</Group>
+
+</Group>
+
+</Group> <!-- Data flows -->
+
+<Group id="xccdf_org.gentoo.dev.swift_group_removal">
+<title>Decommissioning servers</title>
+<description>
+When a server needs to be decommissioned, make sure that its data
+is safeguarded from future extraction.
+</description>
+
+<Group id="xccdf_org.gentoo.dev.swift_group_removal-wipedisk">
+<title>Wipe disks</title>
+<description>
+<h:p>
+Clear all data from the disks on the server in a secure manner.
+Applications like <h:b>shred</h:b> (part of
+<h:code>sys-apps/coreutils</h:code>) can be used to security wipe data
+or even entire partitions or disks.
+</h:p>
+<h:p>
+It is recommended to perform full disk wipes rather than file wipes.
+If this needs to be done on file level, see if the file system
+journaling can be disabled during the wipe session as journaling might "buffer" the
+secure writes and only write the end result to the disk.
+</h:p>
+</description>
+<reference href="http://csrc.nist.gov/publications/nistpubs/800-88/NISTSP800-88_rev1.pdf">NIST Publication "Guidelines for Media Sanitization" (PDF)</reference>
+</Group>
+
+</Group> <!-- Removal -->
+
 </Benchmark>