path: root/xml/SCAP/gentoo-xccdf.xml

<?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-20130917-1" xsi:schemaLocation="http://checklists.nist.gov/xccdf/1.2 xccdf-1.2.xsd" resolved="0">
  <status date="2013-09-17">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>20130917.1</version>
  <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.
    </description>
  </Profile>
  <Profile id="xccdf_org.gentoo.dev.swift_profile_default">
    <title>Default server setup settings</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.
    </description>
    <!-- The /home location is a separate file system -->
    <select idref="xccdf_org.gentoo.dev.swift_rule_partition-home" selected="true" />
  </Profile>
  <Group id="xccdf_org.gentoo.dev.swift_group_intro">
    <title>Introduction</title>
    <description>
      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:br />
      <h:br />
      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, we did not include all
      information from the Gentoo Security Handbook as some of the settings are
      specific to a service that is not all that default on a Gentoo Linux
      system. Although these settings are important as well, it is our believe
      that this is best done in separate benchmarks for those services instead.
      <h:br />
      <h:br />
      Where applicable, this benchmark will refer to a different hardening guide
      for specific purposes (such as the Hardening OpenSSH benchmark).
    </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>
        It is <h:em>very important</h:em> to realize that this document is not a
	policy.  You are not obliged to follow this if you want a secure system
	nor do you need to agree with everything said in the document.
	<h:br />
	<h:br />
	The purpose of this document is to guide you in your quest to hardening
	your system.  It will provide pointers that could help you decide in
	particular configuration settings and will do this hopefully using
	sufficient background information to make a good choice.
	<h:br />
	<h:br />
	You <h:em>will</h:em> find settings you don't agree with. That's fine, but
	if you disagree with <h:em>why</h:em> we do this, we would like to hear it
	and we'll add the feedback to the guide.
      </description>
    </Group>
    <Group id="xccdf_org.gentoo.dev.swift_group_intro-scap">
      <title>A little more about SCAP and OVAL</title>
      <description>
        Within SCAP, NIST has defined some new standards of which XCCDF and OVAL
        are notably important in light of the guide you are currently using.
        <h:ul>
          <h:li>
            XCCDF (Extensible Configuration Checklist Description Format) is
            a specification language for writing security checklists and benchmarks
            (such as the one you are reading now)
          </h:li>
          <h:li>
            OVAL (Open Vulnerability and Assessment Language) is a standard to describe
            and validate system settings
          </h:li>
        </h:ul>
        <h:br />
        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.
      </description>
    </Group>
    <Group id="xccdf_org.gentoo.dev.swift_group_intro-using">
      <title>Using this guide</title>
      <description>
        The guide you are currently reading is the guide generated from this 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:br />
        <h:pre>### Command to generate this guide ###
# <h:b>oscap xccdf generate guide scap-gentoo-xccdf.xml &gt; output.html</h:b>
        </h:pre>
        <h:br />
        Secondly, together with this XCCDF XML, you will also find an OVAL XML file.
        The two files combined allow you to automatically validate various settings as
        documented in the benchmark.
	<h:br />
	<h:br />
	Now, to validate the tests, you can use the following commands:
        <h:pre>### Testing the rules mentioned in the XCCDF document ###
# <h:b>oscap xccdf eval --profile xccdf_org.gentoo.dev.swift_profile_default scap-gentoo-xccdf.xml</h:b></h:pre>
        <h:br />
        To generate a full report in HTML as well, you can use the next command:
        <h:pre>### Testing the rules and generating an HTML report ###
# <h:b>oscap xccdf eval --profile xccdf_org.gentoo.dev.swift_profile_default --results xccdf-results.xml --report report.html scap-gentoo-xccdf.xml</h:b></h:pre>
        <h:br />
	<h:br />
        Finally, this benchmark will suggest some settings which you do not want
        to enable. That is perfectly fine - even more, some settings might even
        raise eyebrows left and right. We will try to document the reasoning behind
        the settings but you are free to deviate from them. If that is the case,
        you might want to disable the rules in the XCCDF document so that they are
        not checked on your system.
      </description>
    </Group>
    <Group id="xccdf_org.gentoo.dev.swift_group_intro-profiles">
      <title>Available XCCDF Profiles</title>
      <description>
        As mentioned earlier, the XCCDF document supports multiple profiles. For the time
	being, two profiles are defined:
	<h:br />
	<h:ul>
	  <h:li>
	    The <em>default</em> profile contains tests that are quick to validate
	  </h:li>
	  <h:li>
	    The <em>intensive</em> profile contains all tests, including those that
	    take a while (for instance because they perform full file system scans)
	  </h:li>
	</h:ul>
	Substitute the profile information in the commands above with the profile you want to test on.
      </description>
    </Group>
  </Group>
  <Group id="xccdf_org.gentoo.dev.swift_group_preinstallation">
    <title>Before You Start</title>
    <description>
      Before you start deploying Gentoo Linux and start hardening it, it is wise
      to take a step back and think about what you want to accomplish. Setting
      up a more secured Gentoo Linux isn't a goal, but a means to reach
      something. Most likely, you are considering setting up a Gentoo Linux
      powered server. What is this server for? Where will you put it? What other
      services will you want to run on the same OS? Etc.
    </description>
    <Group id="xccdf_org.gentoo.dev.swift_group_preinstallation-architecturing">
      <title>Infrastructure Architecturing</title>
      <description>
        When considering your entire IT architecture, many architecturing
        frameworks exist to write down and further design your infrastructure.
        There are very elaborate ones, like TOGAF (The Open Group Architecture
        Framework), but smaller ones exist as well.
        <h:br />
        <h:br />
        A well written and maintained infrastructure architecture helps you
        position new services or consider the impact of changes on existing
        components. And the reason for mentioning such a well designed architecture
        in a hardening guide is not weird.
        <h:br />
        <h:br />
        Security is about reducing risks, not about harassing people or making
        work for a system administrator harder. And reducing risks also means
        that you need to keep a clear eye out on your architecture and all its
        components. If you do not know what you are integrating, where you are
        putting it or why, then you have more issues to consider than hardening
        a system.
      </description>
    </Group>
    <Group id="xccdf_org.gentoo.dev.swift_group_preinstallation-requirements">
      <title>Mapping Requirements</title>
      <description>
        When you design a service, you 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. Have you
        considered auditing? Where do the audit logs need to be sent to? What
        about authentication? Centrally managed, or manually set? And the server
        you are installing, will it only host a particular service, or will it
        provide several services?
        <h:br />
        <h:br />
        When hosting multiple services on the same server, make sure that the
        server is positioned within your network on an acceptable segment. It is
        not safe to host your central LDAP infrastructure on the same system as
        your web server that is facing the Internet.
      </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, we will only focus on the software side
        hardening. There are of course also non-software concerns that you
        should investigate.
      </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>
          Make sure that your system is only accessible (physically) by trusted
          people. Fully hardening your system, only to have a malicious person
          take out the harddisk and run away with your confidential data is not
          something you want to experience.
          <h:br />
          <h:br />
          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 (backups), and also that the
          data on it cannot be read by unauthorized people. We will come back on
          disk encryption later.
        </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>
          Create or validate the security policies in your 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).
        </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>
      Let's focus now on the OS hardening. Gentoo Linux allows you to update the
      system as you want after installation, but it might be interesting to
      consider the following aspects during installation if you do not want a
      huge migration project later.
    </description>
    <Group id="xccdf_org.gentoo.dev.swift_group_installation-storage">
      <title>Storage Configuration</title>
      <description>
        Your storage is of utmost importance in any environment. It needs to be
        sufficiently fast, not to jeopardize performance, but also secure and
        manageable yet still remain 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 your file system structure you want on a
          different partition or logical volume. Separate locations allow for a
          more distinct segregation (for instance, 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-home">
          <title>/home Location</title>
          <description>
            The <h:code>/home</h:code> location should be on its own partition,
            allowing the administrator to mount this location with specific
            options targetting the file systems' security settings or quota.
          </description>
	  <Rule id="xccdf_org.gentoo.dev.swift_rule_partition-home" selected="true">
	    <title>Test if /home is a separate partition</title>
	    <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>
        </Group>
      </Group>
    </Group>
    <!-- 
    <Group id="gt-installation-toolchain">
      <title>Use a Hardened Toolchain</title>
      <description>
        When you install Gentoo, 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:br />
        <h:br />
        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:pre>### Using the appropriate hardened toolchain ###
# <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>
    </Group>
    <Group id="gt-installation-selinux">
      <title>Use a Mandatory Access Control system</title>
      <description>
        Linux uses, by default, what is called a <h:em>Discretionary Access Control</h:em>
	system. This means, amongst other things, that a user can control which files others
	can access, but also that he is able to leak information towards other users.
	<h:br />
	<h:br />
	With a <h:em>Mandatory Access Control</h:em> system in place, the security administrator
	of a system defines security policies to which the entire system should adhere to. Users
	then can "play" within the defined fields of this policy, but cannot extend this policy themselves.
	<h:br />
	<h:br />
	Linux supports a few of these MAC systems. SELinux is a popular one, grSecurity RBAC system
	is another, TOMOYO exists as well, etc. It is advisable to use such a MAC system, but its
	configuration and testing of these settings are beyond the scope of this benchmark for now.
      </description>
      <reference href="http://hardened.gentoo.org/selinux">Gentoo Hardened SELinux project page</reference>
    </Group>
    -->
  </Group>
  <!-- 
  <Group id="gt-system">
    <title>System Settings</title>
    <description>
      Within this chapter, we describe the (recommended) settings that can be
      adjusted relatively easily, even when a Gentoo installation has already
      been performed. This is the bulk of the security settings.
    </description>
    <Group id="gt-system-mounts">
      <title>Mounts and Mount Points</title>
      <description>
        When mounting file systems, options can be presented that add or remove
        features from the mount point. Some of these options can be used to
        restrict actions taken or originating from the file system.
        <h:br />
        <h:br />
        Mount options can be set in <h:code>/etc/fstab</h:code> in the fourth column.
        <h:pre>### Setting mount options###
# <h:b>vim /etc/fstab</h:b>
[...]
tmpfs      /tmp      tmpfs      defaults<h:b>,nosuid,noexec,nodev</h:b>   0 0</h:pre>
        <h:br />
        Important mount options that are used later are:
        <h:ul>
          <h:li>
            <h:code>nosuid</h:code> will ignore SUID bits on binaries. If such
            a binary is encountered, it is executed as if it did not have the SUID
            bit set.
          </h:li>
          <h:li>
            <h:code>noexec</h:code> will prevent direct execution of files or
            binaries from this partition.
          </h:li>
          <h:li>
            <h:code>nodev</h:code> will ignore device files in this partition.
          </h:li>
        </h:ul>
        <h:br />
        Even though these mount options can be worked around, it is a first line
        of defence against popular exploits and worms.
      </description>
      <Group id="gt-system-mounts-tmp">
        <title>Temporary Files</title>
        <description>
          The <h:code>/tmp</h:code> location is world writable, allowing for
          any service to put temporary files in it that are required during
          service operation.
          <h:br />
          <h:br />
          This location should be a tmpfs file system (so that its content is
          cleared during shut down or reboot) and mounted with nosuid,noexec and
          nodev mount options (to reduce the impact when an exploit is attempted from
          within this location).
          <h:pre>### Sample /etc/fstab line for /tmp ###
tmpfs   /tmp   tmpfs       defaults,nosuid,noexec,nodev     0 0</h:pre>
          Also, the location must have the sticky bit set (cfr the trailing 't' in the
	  output of <h:b>ls -ld</h:b>).
	  <h:pre>### Sticky bit for /tmp must be set ###
# <h:b>ls -ld /tmp</h:b>
drwxrwxrwt  9 root root  260  Dec 27  16:00  /tmp</h:pre>
          Of course, using <h:code>tmpfs</h:code> does not give you freedom nor a 
	  secure means to write security sensitive information in <h:code>/tmp</h:code>.
        </description>
      </Group>
      <Group id="gt-system-mounts-home">
        <title>Home Directories</title>
        <description>
          The <h:code>/home</h:code> location is used to host end user files.
          To reduce the risk of an exploit being launched, it is adviseable to
          mount this partition with the <h:code>nosuid,nodev</h:code> mount options.
          <h:br />
          <h:pre>### Sample /etc/fstab line for /home ###
/dev/mapper/volgrp-home   /home   ext4     noatime,nosuid,nodev,data=journal   0 2</h:pre>
        </description>
      </Group>
      <Group id="gt-system-mounts-quotas">
        <title>Quota's</title>
        <description>
          Most file systems support the notion of <h:em>quotas</h:em> - limits
          on the amount of data / files you are allowed to have on that
          particular file system.
          <h:br />
          <h:br />
          To enable quotas, first configure your Linux kernel to include
          <h:code>CONFIG_QUOTA</h:code>.
          <h:br />
          <h:br />
          Next, install the <h:code>sys-fs/quota</h:code> package.
          <h:pre>### Installing quota ###
# <h:b>emerge quota</h:b></h:pre>
          Then add <h:code>usrquota</h:code> and <h:code>grpquota</h:code> to
          the partitions (in <h:code>/etc/fstab</h:code>) where you want to
          enable quotas 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:pre>### Example quota definition in /etc/fstab ###
/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>
          Finally, add the <h:code>quota</h:code> service to the boot runlevel.
          <h:pre>### Adding quota to the boot runlevel ###
# <h:b>rc-update add quota boot</h:b></h:pre>
          Reboot the system so that the partitions are mounted with the correct
          mount options and that the quota service is running. Then you can
          setup quotas for users and groups. 
        </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>
      </Group>
    </Group>
    <Group id="gt-system-services">
      <title>Services</title>
      <description>
        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:br />
        <h:br />
        In this benchmark, we will only focus on those services that are either
        default available on a Gentoo installation (like SSHd) or that are 
        commonly used in Gentoo server architectures (like rsync). For the other
        services, we refer to other benchmarks.
      </description>
      <reference href="http://www.cisecurity.org">Center for Internet Security,
      host of many service benchmarks</reference>
      <Group id="gt-system-services-disable">
        <title>Disable Unsafe Services</title>
        <description>
          We recommend not to enable the following services unless absolutely
          necessary. These services use plain-text protocols and as thus unsafe
          to use on untrusted networks (like the Internet, but also internal
          networks).
          <h:ul>
            <h:li>Telnet service</h:li>
            <h:li>FTP Service</h:li>
          </h:ul>
          <h:br />
          It is recommended to substitute these services with their more secure
          counterparts (like sFTP, SSH, ...).
        </description>
      </Group>
      <Group id="gt-system-services-sulogin">
        <title>Require Single-User Boot to Give Root Password</title>
        <description>
          When a system is booted in single user mode, some users might find it
          handy to immediately get a root prompt; others even have a specific
          bootloader entry to boot in single user mode.
          <h:br />
          <h:br />
          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 and is part of
          <h:code>/etc/inittab</h:code>'s definition:
          <h:pre>### Ensure sulogin is available for single user mode ###
su0:S:wait:/sbin/rc single
<h:b>su1:S:wait:/sbin/sulogin</h:b></h:pre>
        </description>
      </Group>
      <Group id="gt-system-services-tcpwrappers">
        <title>Properly Configure TCP Wrappers</title>
        <description>
          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:br />
          <h:br />
          More information on the format of these files can be obtained through
          <h:b>man 5 hosts_access</h:b>.
        </description>
      </Group>
      <Group id="gt-system-services-ssh">
        <title>SSH Service</title>
        <description>
          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 to proper hardening is definitely in place.
	  <h:br />
	  <h:br />
	  Please use the "Hardening OpenSSH" guide for the necessary instructions.
        </description>
      </Group>
      <Group id="gt-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="gt-system-services-cron-acl">
          <title>Only Allow Trusted Accounts Cron Access</title>
          <description>
            Only allow trusted accounts to use cron. You should list trusted
            accounts in <h:code>/etc/cron.allow</h:code>. 
          </description>
        </Group>
      </Group>
      <Group id="gt-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="gt-system-services-at-acl">
          <title>Only Allow Trusted Accounts At Access</title>
          <description>
            Only allow trusted accounts to use at. You should list trusted
            accounts in <h:code>/etc/at.allow</h:code>.
          </description>
        </Group>
      </Group>
      <Group id="gt-system-services-ntp">
        <title>NTP Service</title>
        <description>
          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.
        </description>
        <Group id="gt-system-services-ntp-sync">
          <title>Synchronise The System Clock</title>
          <description>
            Synchronise your systems' clock with an authorative NTP server, and
            use the same NTP service for all your systems.
            <h:br />
            <h:br />
            You can accomplish this by regularly executing <h:b>ntpdate</h:b>,
            but you can also use a service like <h:code>net-misc/ntp</h:code>'s
            <h:b>ntpd</h:b>.
          </description>
        </Group>
      </Group>
    </Group>
    <Group id="gt-system-portage">
      <title>Portage Settings</title>
      <description>
        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:br />
        <h:br />
        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 you use Portage as
        package manager) are important.
      </description>
      <Group id="gt-system-portage-use">
        <title>USE Flags</title>
        <description>
          USE flags in Gentoo are used to tune the functionality of many
          components and enable or disable features.
          <h:br />
          <h:br />
          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: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: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:br />
          <h:br />
          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 you to identify allowed (and denied) hosts or
          network segments on application level.
          <h:br />
          <h:br />
          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:br />
          <h:br />
          You should set the USE flags globally in
          <h:code>/etc/make.conf</h:code>.
          <h:br />
          <h:pre>### Setting the USE flag in /etc/make.conf ###
USE="... pam tcpd ssl"</h:pre>
        </description>
      </Group>
      <Group id="gt-system-portage-webrsync">
        <title>Fetching Signed Portage Tree</title>
        <description>
          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 you can find the instructions again:
	  <h:pre>### Using emerge-webrsync with GPG signatures ###
# <h:b>mkdir -p /etc/portage/gpg</h:b>
# <h:b>chmod 0700 /etc/portage/gpg</h:b>
# <h:b>gpg - -homedir /etc/portage/gpg - -keyserver subkeys.pgp.net - -recv-keys 0x239C75C4 0x96D8BF6D</h:b>
# <h:b>gpg - -homedir /etc/portage/gpg - -edit-key 0x239C75C4 trust</h:b>
# <h:b>gpg - -homedir /etc/portage/gpg - -edit-key 0x96D8BF6D trust</h:b></h:pre>
          After this, you can edit <h:code>/etc/make.conf</h:code>:
	  <h:pre>### Editing make.conf for signed portage trees ###
FEATURES="webrsync-gpg"
PORTAGE_GPG_DIR="/etc/portage/gpg"
SYNC=""</h:pre>
        </description>
      </Group>
    </Group>
    <Group id="gt-system-kernel">
      <title>Kernel Configuration</title>
      <description>
        The Linux kernel should be configured using a sane security standard in
        mind. When using grSecurity, additional security-enhancing settings can
        be enabled.
	<h:br />
	<h:br />
	For further details, I refer to the "Hardening the Linux kernel" guide.
      </description>
      <reference href="http://www.gentoo.org/doc/en/kernel-config.xml#shorthand">Gentoo Kernel Configuration Guide - Shorthand notation information</reference>
    </Group>
    <Group id="gt-system-bootloader">
      <title>Bootloader Configuration</title>
      <description>
        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.
      </description>
      <Group id="gt-system-bootloader-grubpass">
        <title>Password Protect GRUB</title>
        <description>
          It is recommended to password-protect the GRUB configuration so that
          you cannot modify boot options during a boot without providing the
          valid password.
          <h:br />
          <h:br />
          You can accomplish this 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 if you do not like having a clear-text password in
          the configuration file, you can hash it. Just start <h:b>grub</h:b>
          and, in the grub-shell, type <h:b>md5crypt</h:b>.
          <h:br />
          <h:pre>### Getting a hashed password for GRUB ###
# <h:b>grub</h:b>

GRUB version 0.92 (640K lower / 3072K upper memory)

[ Minimal BASH-like line editing is supported. ... ]

grub&gt; <h:b>md5crypt</h:b>

Password: <h:em>abc123</h:em>
Encrypted: $1$18u.M0$J8VbOsGXuoG9Fh3n7ZkqY.

grub&gt; <h:b>quit</h:b></h:pre>
          <h:br />
          You can then use this hashed password in <h:code>grub.conf</h:code>
          using <h:code>password - -md5
          $1$18u.M0$J8VbOsGXuoG9Fh3n7ZkqY.</h:code>.
        </description>
      </Group>
      <Group id="gt-system-bootloader-lilopass">
        <title>Password Protect LILO</title>
        <description>
          It is recommended to password-protect the LILO configuration so that
          you cannot modify boot options during a boot without providing the
          valid password.
          <h:br />
          <h:br />
          You can accomplish this 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:br />
          <h:pre>### Setting a password for LILO in /etc/lilo.conf ###
password=abc123
restricted
delay=3

image=/boot/bzImage
        read-only
        password=def456
        restricted</h:pre>
           <h:br />
           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:br />
           <h:br />
           Rerun <h:code>lilo</h:code> after updating the configuration file.
        </description>
      </Group>
    </Group>
    <Group id="gt-system-auth">
      <title>Authentication and Authorization Settings</title>
      <description>
        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.
      </description>
      <Group id="gt-system-auth-securetty">
        <title>Restrict root System Logon</title>
        <description>
          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:br />
          <h:br />
          When properly configured, any attempt to log on as the root user from
          a non-defined terminal will result in logon failure.
          <h:br />
          <h:br />
          A recommended setting is to only allow root user login through the
          console and the physical terminals (<h:code>tty0-tty12</h:code>).
          <h:pre>### /etc/securetty ###
console
tty0
tty1
...
tty12</h:pre>
        </description>
      </Group>
      <Group id="gt-system-auth-userlogin">
        <title>Allow Only Known Users to Login</title>
        <description>
          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:br />
          <h:br />
          By enabling these settings, you reduce the risk 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.
        </description>
      </Group>
      <Group id="gt-system-auth-resources">
        <title>Restrict User Resources</title>
        <description>
          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:br />
          <h:br />
          In Gentoo Linux, the following methods are available to limit
          resources.
          <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>
          Generally, you should suffice with setting
          <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:br />
          <h:br />
          Note that the settings are applicable on a <h:em>per login
          session</h:em> basis.
          <h:br />
          <h:br />
          More information on these files and their syntax can be obtained
          through their manual pages.
          <h:pre>### Reading the limits manual pages ###
# <h:b>man limits.conf</h:b>
# <h:b>man limits</h:b></h:pre>
        </description>
      </Group>
      <Group id="gt-system-auth-password">
        <title>Enforce Password Policy</title>
        <description>
          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:br />
          <h:br />
          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 to help you en
          route.
          <h:br />
          <h:br />
          A second important player when dealing with password policies is the
          <h:code>pam_cracklib.so</h:code> library. You can then use this 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:pre>### Sample /etc/pam.d/passwd setting with cracklib ###
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>
password  required pam_unix.so md5 use_authok
session   required pam_unix.so</h:pre>
          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.
        </description>
      </Group>
      <Group id="gt-system-auth-ripper">
        <title>Review Password Strength Regularly</title>
        <description>
          Regularly check the strength of your 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:br />
          <h:br />
          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.
        </description>
      </Group>
    </Group>
    <Group id="gt-system-session">
      <title>Session Settings</title>
      <description>
        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.
      </description>
      <Group id="gt-system-session-mesg">
        <title>Disable Access to User Terminals</title>
        <description>
          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:br />
          <h:br />
          Messages can confuse users and trick them into performing malicious
          actions. 
          <h:br />
          <h:br />
          You can disable this 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.
        </description>
      </Group>
    </Group>
    <Group id="gt-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="gt-system-fileprivileges-worldrw">
        <title>Limit World Writable Files and Locations</title>
        <description>
          Limit (or even remove) the use of world writable files and locations.
          If a directory is world writable, you probably want to have the
          sticky bit set on it as well (like with <h:code>/tmp</h:code>).
          <h:br />
          <h:br />
          You can use <h:code>find</h:code> to locate such files or directories.
          <h:pre>### Using find to find world writable files and directories ###
# <h:b>find / -perm +o=w ! \( -type d -perm +o=t \) ! -type l -print</h:b></h:pre>
          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).
        </description>
	<Rule id="rule-world-writeable-sticky" selected="false">
          <title>World writeable directories must have sticky bit set</title>
	  <description>World writeable directories must have sticky bit set</description>
	  <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
	    <check-content-ref href="scap-gentoo-oval.xml" name="oval:@@OVALNS@@.static:def:2" />
	  </check>
	</Rule>
      </Group>
      <Group id="gt-system-fileprivileges-suidsgid">
        <title>Limit Setuid and Setgid File and Directory Usage</title>
        <description>
          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:br />
          <h:br />
          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:br />
          <h:br />
          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.
        </description>
      </Group>
      <Group id="gt-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="gt-system-fileprivileges-rootonly">
        <title>Files Only Used By Root Should be Root-Only</title>
        <description>
          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:br />
          <h:br />
          A nonexhaustive list of such files is:
          <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="gt-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>
  <Group id="gt-data">
    <title>Data Flows</title>
    <description>
      Clearly map out how data flows in and out of your server (and which data
      this is). You will need this anyhow when you want to add firewalls, but it
      also improves integration of the server in a larger infrastructure.
    </description>
    <Group id="gt-data-backup">
      <title>Backup Your Data</title>
      <description>
        Make sure that your data is backed up. This is not only in case of
        server loss, but also when you accidentally remove files or have an
        awkward bug in a service that deleted important information.
      </description>
      <Group id="gt-data-backup-automate">
        <title>Automated Backups</title>
        <description>
          Automate backups on the system. If you need to perform a backup
          manually, then you are doing it wrong and will start forgetting it.
          <h:br />
          <h:br />
          You can 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>.
        </description>
      </Group>
      <Group id="gt-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="gt-data-backups-history">
        <title>Retention</title>
        <description>
          Ensure that your backups use a long enough retention. It is not wise
          to take a single backup and overwrite this one over and over again, as
          you might want to recover a file that was corrupted long before you
          took your last backup.
          <h:br />
          <h:br />
          There is no perfect retention period however, as the more backups you
          keep, the more storage you require and the more you need to invest in
          managing your backups.
          <h:br />
          <h:br />
          In most cases, you will want to introduce a "layered" approach on
          retention. For instance, you can
          <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="gt-data-backups-location">
        <title>Off-site Backups</title>
        <description>
          Keep your backups off-site in case of disaster. But consider this
          location carefully. Investigate how fast you can put the backup there,
          but also retrieve it in case you need it. Also investigate if this
          location is juridically sane (are you allowed to put your location
          there, and do you trust this off-site location).
          <h:br />
          <h:br />
          Also ensure that the backups are stored securely. If necessary,
          encrypt your backups.
        </description>
      </Group>
      <Group id="gt-data-backups-validate">
        <title>Validate and Test</title>
        <description>
          Validate that your 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>
  <Group id="gt-removal">
    <title>Decommissioning Servers</title>
    <description>
      When you want to decommission a server, you should take care that its data
      is safeguarded from future extraction.
    </description>
    <Group id="gt-removal-wipedisk">
      <title>Wipe Disks</title>
      <description>
        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:br />
        <h:br />
        It is recommended to perform full disk wipes rather than file wipes.
        If you need to do this on file level, see if you can disable file system
        journaling during the wipe session as journaling might "buffer" the
        secure writes and only write the end result to the disk.
      </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>
  -->
</Benchmark>