From: "Sven Vermeulen" <swift@gentoo.org>
To: gentoo-commits@lists.gentoo.org
Subject: [gentoo-commits] proj/hardened-docs:master commit in: xml/SCAP/
Date: Fri, 4 Sep 2015 19:50:47 +0000 (UTC) [thread overview]
Message-ID: <1441396242.6c9db61696a9fd392340949543e32af8b82c537f.swift@gentoo> (raw)
commit: 6c9db61696a9fd392340949543e32af8b82c537f
Author: Sven Vermeulen <sven.vermeulen <AT> siphos <DOT> be>
AuthorDate: Fri Sep 4 19:50:42 2015 +0000
Commit: Sven Vermeulen <swift <AT> gentoo <DOT> org>
CommitDate: Fri Sep 4 19:50:42 2015 +0000
URL: https://gitweb.gentoo.org/proj/hardened-docs.git/commit/?id=6c9db616
Update on Gentoo hardening guide
xml/SCAP/Makefile | 16 +-
xml/SCAP/gentoo-oval.xml | 30 +
xml/SCAP/gentoo-xccdf.xml | 4158 ++++++++++++++++++++++++---------------------
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 > 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&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&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> <h:b>md5crypt</h:b>
+
+Password: <h:em>abc123</h:em>
+Encrypted: $1$18u.M0$J8VbOsGXuoG9Fh3n7ZkqY.
+
+grub> <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} && run_init rc-service ${service##*/} stop;
+test -f ${service} && 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} && run_init rc-service ${service##*/} stop;
+test -f ${service} && 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> <h:b>md5crypt</h:b>
+</Group>
-Password: <h:em>abc123</h:em>
-Encrypted: $1$18u.M0$J8VbOsGXuoG9Fh3n7ZkqY.
+</Group>
-grub> <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>
next reply other threads:[~2015-09-04 19:50 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-04 19:50 Sven Vermeulen [this message]
-- strict thread matches above, loose matches on Subject: below --
2015-09-02 20:24 [gentoo-commits] proj/hardened-docs:master commit in: xml/SCAP/ Sven Vermeulen
2014-03-30 20:08 Sven Vermeulen
2014-03-30 20:08 Sven Vermeulen
2014-03-30 18:29 Sven Vermeulen
2014-03-30 18:29 Sven Vermeulen
2014-03-26 21:07 Sven Vermeulen
2014-02-01 14:24 Sven Vermeulen
2014-02-01 14:24 Sven Vermeulen
2014-02-01 14:24 Sven Vermeulen
2014-02-01 14:24 Sven Vermeulen
2013-12-20 14:48 Sven Vermeulen
2013-12-20 14:47 Sven Vermeulen
2013-12-20 14:41 Sven Vermeulen
2013-12-20 14:38 Sven Vermeulen
2013-12-20 14:25 Sven Vermeulen
2013-12-20 14:15 Sven Vermeulen
2013-12-20 14:15 Sven Vermeulen
2013-12-20 13:56 Sven Vermeulen
2013-12-20 13:56 Sven Vermeulen
2013-12-20 13:56 Sven Vermeulen
2013-12-20 13:56 Sven Vermeulen
2013-12-20 13:56 Sven Vermeulen
2013-12-20 13:56 Sven Vermeulen
2013-12-20 10:59 Sven Vermeulen
2013-12-11 20:58 Sven Vermeulen
2013-12-11 20:58 Sven Vermeulen
2013-12-11 20:53 Sven Vermeulen
2013-12-11 20:53 Sven Vermeulen
2013-09-24 17:10 Sven Vermeulen
2013-09-23 11:46 Sven Vermeulen
2013-09-23 11:40 Sven Vermeulen
2013-09-19 19:26 Sven Vermeulen
2013-09-18 13:51 Sven Vermeulen
2013-09-17 19:07 Sven Vermeulen
2013-09-17 19:07 Sven Vermeulen
2013-09-17 19:07 Sven Vermeulen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1441396242.6c9db61696a9fd392340949543e32af8b82c537f.swift@gentoo \
--to=swift@gentoo.org \
--cc=gentoo-commits@lists.gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox