MAC versus DAC in SELinux

Some system administrators do not understand Mandatory Access Control (MAC) and how it interacts with Discretionary Access Control (DAC) in Linux®. In a previous post, I stated Security-Enhanced Linux (SELinux) employs MAC rules to facilitate fine-grained security. I also discussed some of the collection of rules which form standard SELinux policies such as Targeted and Strict.

I received some emails from readers which said they weren't clear on how MAC and DAC work together in the operating system. Since I am a hands-on guy, I love to see real-world examples, so that's what I am going to show you.

I have configured a standard CentOS 5.6 Linux system with default Apache web server packages installed. The sestatus(8) command reports the operating system is enforcing the default SELinux Targeted policy.

# /usr/sbin/sestatus
SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   enforcing
Mode from config file:          enforcing
Policy version:                 21
Policy from config file:        targeted

Using the -Z argument to the ps(1) command shows the Apache daemon (httpd) is executing in the (httpd_t) domain:

# /bin/ps -aefZ |/usr/bin/grep httpd
root:system_r:httpd_t           root     24855     1  0 10:23 ?        00:00:00 /usr/sbin/httpd
root:system_r:httpd_t           apache   24856 24855  0 10:23 ?        00:00:00 /usr/sbin/httpd
root:system_r:httpd_t           apache   24857 24855  0 10:23 ?        00:00:00 /usr/sbin/httpd
root:system_r:httpd_t           apache   24858 24855  0 10:23 ?        00:00:00 /usr/sbin/httpd
root:system_r:httpd_t           apache   24859 24855  0 10:23 ?        00:00:00 /usr/sbin/httpd
root:system_r:httpd_t           apache   24860 24855  0 10:23 ?        00:00:00 /usr/sbin/httpd
root:system_r:httpd_t           apache   24862 24855  0 10:23 ?        00:00:00 /usr/sbin/httpd
root:system_r:httpd_t           apache   24863 24855  0 10:23 ?        00:00:00 /usr/sbin/httpd
root:system_r:httpd_t           apache   24864 24855  0 10:23 ?        00:00:00 /usr/sbin/httpd

I will use the curl(1) command to retrieve a URL from the Apache web server — this is equivalent to a web browser accessing the URL. By default, the provided Apache packages establishes the document root as /var/www/html. So, we will create a test.html file in the document root with a permissive DAC and a MAC which the httpd_t domain is not allowed to access.

# cd /var/www/html
# /bin/touch test.html
# /usr/bin/chcon system_u:object_r:shadow_t test.html 
# /bin/ls -lZ test.html
-rw-r--r--  root root system_u:object_r:shadow_t         test.html

I have temporarily set the SELinux context of this file to be of shadow_t type using the chcon(1) command. This restrictive type is set on the /etc/shadow system file – a web server would have no reason to access a file of this type. Using the -Z option to the ls(1) command you can see the type is now shadow_t in the SELinux context.

Note the DAC mode (-rw-r--r--) of the file permits the owner to read and write (rw), the group to read (r), and everybody else [other] is able to read (r) the file. However, when I try to retrieve the file the MAC rule in the SELinux policy FORBIDS the process running in the httpd_t domain from accessing files of type shadow_t — REGARDLESS of the permissive DAC mode:

# /usr/bin/curl -I http://localhost/test.html
HTTP/1.1 403 Forbidden
Date: Fri, 23 Sep 2011 14:48:51 GMT
Server: Apache/2.2.3 (CentOS)
Connection: close
Content-Type: text/html; charset=iso-8859-1

The SELinux policy also defines default SELinux contexts for directories and file patterns. When the system is rebooted or the restorecon(8) utility is called, file system objects are labeled according to the policy. I will use the restorecon utility to restore (set) the SELinux context on our test file appropriately:

# /sbin/restorecon test.html
# /bin/ls -Z test.html
-rw-r--r--  root root system_u:object_r:httpd_sys_content_t test.html

In order for the Apache web server running in the httpd_t domain to read files in its document root (/var/www/html), the files should be of http_sys_content_t type.

Now, I am able to access the file:

# /usr/bin/curl -I http://localhost/test.html
HTTP/1.1 200 OK
Date: Fri, 23 Sep 2011 14:50:16 GMT
Server: Apache/2.2.3 (CentOS)
Last-Modified: Fri, 23 Sep 2011 14:40:32 GMT
ETag: "15aac8-6-ca935800"
Accept-Ranges: bytes
Content-Length: 6
Connection: close
Content-Type: text/html; charset=UTF-8

This simple real-world example demonstrates how MAC rules supersede DAC settings. I encourage you to read the system documentation and experiment on lab systems. Too often system administrators become frustrated by “AVC Denial” messages and resort to disabling this enhanced security.

Security Blanket Supports SELinux

Security-Enhanced Linux (SELinux) is an enhancement to the standard Linux® kernel that provides fine-grained security by employing Mandatory Access Control (MAC) rules. Security Blanket® v4.0.7 now supports Red Hat® Enterprise Linux 4, 5, and 6 enforcing the default Targeted SELinux policy – as well as Fedora™ 10 through 13.

The aim of the Targeted policy is to provide additional security to some of the more commonly used daemons such as httpd, dhcpd, mailman, named, portmap, nscd, ntpd, portmap, mysqld, postgres, squid, syslogd, winbind, and ypbind by employing MAC rules.

 For example, the Apache Web Server (httpd) daemon executes in its own domain httpd_t. Other daemons on the system which do not have policy written specifically for them run in the domain unconfined_t.

Daemons and system processes running in the unconfined_t domain only use the standard Linux Discretionary Access Control (DAC) method of access control. In SELinux, access is granted to processes on a per-domain basis; each domain has a set of operations it may perform on each type of file, directory, or other resource.

For security reasons, the Security Blanket team preferred not to execute in the unconfined_t domain. Therefore, a specific policy module was written to augment the Targeted policy, which separated Security Blanket's Console, Dispatcher, and Core Engine components into their own domains. For more details and exceptions, please see the Security Blanket Administration Guide.

Processes and files are labeled with an SELinux Context that contains additional information, such as an SELinux user, role, type, and, optionally, a security level. When running SELinux, all of this information is used to make access control decisions. In Red Hat Enterprise Linux, SELinux provides a combination of Role-Based Access Control (RBAC), Type Enforcement® (TE), and, optionally, Multi-Level Security (MLS).

The above image is the output from the ls(1) command using the -Z argument , which displays the SELinux Context assigned to a file object.

In previous releases of Security Blanket, SELinux was not supported because the SELinux Context on file system objects could be destroyed and could only be restored by relabeling the object. Each file system object is referenced by its information node (inode) and the SELinux context is stored as an extended attribute.

Some Security Blanket modules created new files or worked with temporary copies of configuration files — then subsequently copied it to their final location. In these situations, a new information node was assigned. Several modifications to the Security Blanket Core Engine and associated modules were made to restore the SELinux context on such file system objects.

In future releases of Security Blanket, we may provide support for the Strict policy with MLS. The goal of MLS policy is to allow a Linux operating system to get EAL4+/LSPP certification. In developing this policy, the fourth field of the security context, the security or sensitivity level has been turned on — this facilitates the handling of labeled files.

Furthermore, the MLS policy contains rules that not only govern what security types are able to do, but also what they can do when running at a particular security level. In MLS there are two components of the Security Level, the sensitivity level, which can go from s0–s15, and the capabilities, which can go from c0–c255. The Multi Category System (MCS) policy was also added to the Targeted and Strict policies, which confines the sensitivity level to s0 but permits user defined capabilities.

The Security Blanket team is also watching the National Security Agency's (NSA) Certifiable Linux Integration Platform (CLIP) project. This project defines a specific configuration of SELinux designed to provide the foundation for hosting secure applications.

The Security Blanket team is excited to offer SELinux Targeted policy support and we are anxious to hear from our customers. Finally, if you are interested in using Security Blanket on systems enforcing the Strict policy or you have plans to use configurations defined by CLIP, send us an email at SecurityBlanket@TrustedCS.com.

For more information see: Taking advantage of SELinux in Red Hat® Enterprise Linux®, by Faye Coker and Russell Coker 

Red Hat 5 STIG: Kernel Modules

In the last few years, I've seen organizations extending the concept of least privilege to least installed or running. I have written about minimizing a system's attack surface by removing unnecessary software and turning off as many unused features as possible.

The draft release of the U.S. Defense Information Systems Agency's (DISA) “Red Hat 5 STIG” is no exception. I love it when security guidelines make these suggestions but it can be frustrating when assessment scanners report false-positives. For example, some scanners will report a failure if it can't find a setting in a configuration file for software which isn't even installed on the system.

The new draft STIG requires entries in a configuration file to prevent the kernel from loading modules – even if the modules aren't installed on the system. Nonetheless, I have compiled a list of the required settings which must be set in your modprobe.conf configuration file.

First of all, the STIG requires the loading and removing of kernel modules be recorded by the auditing subsystem (GEN002825). The system calls (-S) init_module and delete_module are tracked and watches (-w) are placed on some command line utilities. Add the following rules to your audit.rules file:

-a always,exit -S init_module -S delete_module -k modules 
-w /sbin/insmod -p x -k modules 
-w /sbin/modprobe -p x -k modules 
-w /sbin/rmmod -p x -k modules 

Unless your system has a specific need for the following networking related modules, they shouldn't be loaded into the kernel. These modules aren't installed in a default Red Hat Enterprise Linux installation but you'll still need to implicitly add entries in modprobe.conf file:

• Network Bridging (GEN003619)
• Stream Control Transmission Protocol (SCTP) (GEN007020)
• Datagram Congestion Control Protocol (DCCP) (GEN007080)
• Reliable Datagram Sockets (RDS) (GEN007480). Some implementations of Oracle Real Application Clusters (RAC) uses RDS as an interconnect.

If you don't use IPv6, it is recommended you disable support for it (GEN007700) and you should configure the system to prevent dynamic loading of the IPv6 protocol handler (GEN007720).

Additionally, the guideline recommends disabling support for Bluetooth, USB storage devices, and Firewire:

• Transparent Inter-Process Communication (TIPC) (GEN007540). TIPC was specially designed for intra-cluster communication and products like Wind River's VxWorks use it.
• Bluetooth (GEN007660)
• USB Mass Storage (GEN008480)
• IEEE 1394 (Firewire) (GEN008500)

To prevent the loading of the aforementioned modules and network modules, add the following to your /etc/modprobe.conf file:

# Network related
install bridge /bin/false
install sctp /bin/true
install dccp /bin/true
install dccp_ipv4 /bin/true
install dccp_ipv6 /bin/true 
install rds /bin/true

install tipc /bin/true
install bluetooth /bin/true

# IPv6
alias net-pf-10 off 
alias ipv6 off 
install ipv6 /bin/true

# USB and Firewire
install usb-storage /bin/true
install ieee1394 /bin/true

Section 2.2.2.5 of the National Security Agency's “Guide to the Secure Configuration of Red Hat Enterprise Linux 5” also recommends not loading kernel modules for uncommon filesystem types:

install cramfs /bin/true
install freevxfs /bin/true
install jffs2 /bin/true
install hfs /bin/true
install hfsplus /bin/true
install squashfs /bin/true
install udf /bin/true

My suggestion is always remove unused software, however many auditors will probably still want to see the implicit setting in the modprobe.conf file.

Red Hat 5 STIG: Network Settings

The draft release of the U.S. Defense Information Systems Agency's (DISA) “Red Hat 5 STIG” earlier this year has a few system administrators panicking. For Red Hat® Enterprise Linux® 5 administrators, this Security Technical Implementation Guide (STIG) has supplanted the generic UNIX STIG.

The generic UNIX STIG had the single potential discrepancy indicator (PDI) “GEN003600 - Network Security Settings.” The checklist document required you to check four network settings in the running kernel. The new Red Hat 5 STIG, however, has many more settings and provides better explanations.

I would caution administrators from rushing to add all of these settings to your systems because most of these settings are defaults. Nonetheless, the settings must be implicitly set in the sysctl.conf configuration file. My recommendation is to review the entire STIG in order to define a complete sysctl.conf file, so that it can be deployed and tested all at once.

To help get you started with the new Red Hat 5 STIG, I have compiled a list of settings from the guideline as well as a few from the National Security Agency's “Guide to the Secure Configuration of Red Hat Enterprise Linux 5.”

First of all, the ability to configure network interfaces should be limited to privileged users (GEN003581). This is achieved by setting “USERCTL” to “no” in the /etc/sysconfig/network-scripts/ifcfg* files.

The NSA configuration guide recommends disabling zero configuration networking (zeroconf); which is a set of techniques that automatically creates a usable Internet Protocol (IP) network without manual operator intervention or special configuration servers. To disable zeroconf, set “NOZEROCONF” to “yes” in the /etc/sysconfig/network file.

As before, IP forwarding [ip_forward] should be disabled (GEN005600) and the new guideline recommends not forwarding (GEN003600) or accepting (GEN003607) source-routed packets [accept_source_route] either.

The system must not respond to broadcast Internet Control Message Protocol (ICMP) echoes (GEN003603) or timestamp requests (GEN003604) [icmp_echo_ignore_braodcasts].

Furthermore, the system must ignore ICMP redirect messages (GEN003609) [accept_redirects] as well as not send ICMP redirects (GEN003610) [send_redirects]. Other guidelines recommend not accepting secure ICMP redirects [secure_redirects]. The secure redirect message is sent by a gateway that appears in the host's default gateway list.

To provide some mitigation to TCP denial of service attacks the guideline (GEN003601) recommends adjusting the TCP backlog queue size [tcp_max_syn_backlog]. Additionally (GEN003612), your system should be configured to send out requests [tcp_syncookies] to remote hosts if they are flooding your system’s backlog queue with SYN packets. These requests check whether or not the inbound SYN packets are legitimate.

Enabling TCP syncookies option on a system under normal load is useful. If your system is under high load it will make new connections but without advanced features such as explicit congestion notification (ECN) or selective acknowledgment (SACK).

To help mitigate the leaking of addressing information between attached network segments, the guideline (GEN003608) recommends disabling proxy Address Resolution Protocol (ARP) [proxy_arp].

The guideline (GEN003613) recommends the system perform source validation by reversed path [rp_filter]. When you enable reverse path source validation, inbound packets are dropped if the IP address from where the packets were received is not reachable (i.e., asymmetrical route).

It should be noted, however, that enabling this may cause problems in complex networks running a slow and unreliable protocol, using static routes, or where asymmetric routes are present. Asymmetric routes are not common, but may be necessary in certain cases. By default, Linux drops packets in which asymmetric routes are used because of the security risk.^[1]

It is also recommended (GEN003619) network bridging be disabled. This is usually a kernel module which can be checked with lsmod(8) command utility. To prevent it from loading, add the appropriate line for that module in the modprobe.conf file.

Finally, the guideline (GEN003611) recommends the kernel log all martian packets [log_martians]. Martian packets are packets which contain addresses known by the system to be invalid.

As I said earlier, many of these settings are kernel defaults. However, it is best to add the following settings into your /etc/sysctl.conf file:

net.ipv4.ip_forward = 0
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.all.secure_redirects = 0
net.ipv4.conf.default.secure_redirects = 0
net.ipv4.tcp_max_syn_backlog = 1280
net.ipv4.tcp_syncookies = 1
net.ipv4.conf.all.proxy_arp = 0
net.ipv4.conf.default.proxy_arp = 0
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.log_martians = 1
net.ipv4.conf.default.log_martians = 1

Now, you can execute /sbin/sysctl -p as root or reboot the system.

---

[1] Benvenuti, Christian. Understanding Linux Network Internals, Chapter 31. Sebastopol, CA: O'Reilly Media, Inc., 2006.

Getting started with the new Red Hat 5 STIG

I am pleased the U.S. Defense Information Systems Agency (DISA) released a draft of “Red Hat 5 STIG” earlier this year. As expected, there are some specific configuration guidelines for Red Hat® Enterprise Linux® 5 which were missing from the generic UNIX Security Technical Implementation Guide (STIG).

The generic UNIX STIG supported numerous UNIX® and Linux® distributions but never addressed Red Hat Enterprise Linux 5. For many years, this lack of support was a source of frustration for system administrators. In February 2011, I discussed the new guidelines in the article “DISA UNIX STIG for Red Hat Enterprise Linux 5 and 6.”

I am reviewing the “Red Hat 5 STIG” to develop a plan to add support for it to our Security Blanket® product. I've completed my initial review and I want to share some of my findings along with some tips.

First of all, the “Red Hat 5 STIG” is not to be used in conjunction with the generic UNIX STIG. Download the ZIP file, extract it, and transform the XML document to a more usable format. I used the XSLT processor which comes with Red Hat as follows:

/usr/bin/xsltproc STIG_unclass.xsl U_RedHat_5_V1R0_STIG_Manual-xccdf.xml > stig.html

The previous command will transform the document from XML format to HTML, so you can open it with your web browser. I like to have a delimited text list of the guideline, so I created the following simple XSLT:

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<xsl:stylesheet version="1.0"
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform" 
    xmlns:dc="http://purl.org/dc/elements/1.1/"
    xmlns:cdf="http://checklists.nist.gov/xccdf/1.1">
 <xsl:output method="text" />
 <xsl:template match="/">
  <xsl:for-each select="cdf:Benchmark/cdf:Group/cdf:Rule">
      <xsl:apply-templates select="." />
  </xsl:for-each>
 </xsl:template>

 <xsl:template match="cdf:Rule">
  <xsl:value-of select="@id" />
  <xsl:text>|</xsl:text>
  <xsl:value-of select="@severity" />
  <xsl:text>|</xsl:text>
  <xsl:value-of select="cdf:version" />
  <xsl:text>|</xsl:text>
  <xsl:value-of select="cdf:title" />
  <xsl:text>&#x0A;</xsl:text>
 </xsl:template>
</xsl:stylesheet>

Save the above as a file and use it instead of the “STIG_unclass.xsl” file.

This STIG, like the generic UNIX one, requires you to have a Disaster Recovery Plan or some form of Business Continuity Plan (BCP). The plan must contain detailed procedures for performing backups and recovery.

Wherever possible, try to have on-line, off-line, and off-site backups. On-line could include storage mirroring technologies and off-line could be some sort of media which isn't connected to equipment. If at all possible, perform encrypted backups and then store them in a media safe on-site and off-site. The off-site backups could be as simple as taking the off-line media outside of your data center and preferably not in the same building.

Account management and personnel security practices must be clearly documented. This includes documenting how access is granted to personnel. Procedures on removing accounts or revoking rights must also be documented. This also means taking a serious look at shared application and administrative accounts. Stop logging directly into these accounts (especially root!) — personnel should be logging into their own personal account then switching to the application/administrative account.

The biggest tip I can offer is to REMOVE ALL SOFTWARE WHICH IS NOT NEEDED. This is where you gain great insight to your system's architecture because you will learn what components rely on what. For example, if you are not using any features or utilities of Samba — remove it.

The new “Red Hat 5 STIG” has 596 potential discrepancy indicators (PDI) – sometimes called “STIG items.” Of these, 62 of them are related to extended access control lists (ACL), 8 to IPv6, and 14 to FIPS 140-2.

In the generic UNIX STIG, many STIG items restrict standard user-group-other permissions. These Discretionary Access Controls (DAC) are a fundamental security mechanism and POSIX.1e Access Control Lists (ACL) provide administrators the ability to grant access to additional users and groups without having to grant access to other (a.k.a, the world).

Nonetheless, there are 62 new STIG items which recommend stripping ACLs from files and directories. By default, file systems such as ext2 and newer support POSIX.1e ACL. If none of your applications require POSIX ACLs, I recommend mounting file systems with the 'noacl' option to disable support for them. This is an easy way to address all 62 items.

As for IPv6, my opinion is that if you are not using IPv6 simply disable support for it. First edit the /etc/sysconfig/network and set “NETWORKING_IPV6” to “no”. Next, add the following two lines to /etc/modprobe.conf:

alias net-pf-10 off
alias ipv6 off

Lastly, stop the IPv6 firewall service and configure it to not start when the system is rebooted:

# /sbin/service ip6tables stop
# /sbin/chkconfig ip6tables off

Fourteen of the new items require the “...[use of] a FIPS 140-2 validated cryptographic module (operating in FIPS mode).” These items, however, don't give the detailed check procedures as many of the other items do. Instead, DISA states, “The NIST CVMP web site provides a list of validated modules and the required security policies for the compliant use of such modules. Verify that the module is on this list and configured in accordance with the validated security policy.”

To make Red Hat Enterprise Linux 5 compliant with the Federal Information Processing Standard (FIPS) Publication 140-2 you need to make several changes to ensure that accredited cryptographic modules are used. For detailed instructions, download DOC-3923 from the Red Hat Knowledgebase.

Ensure the following accredited packages are available:

        kernel  2.6.18-164.2.1.el5
     libgcrypt	1.4.4-5.el5
       openssl  0.9.8e-12.el5
      openswan	2.6.21-5.el5_4.3
           nss  3.12.6-2.el5_4
selinux-policy	2.4.6-255.el5_4.2
 fipscheck-lib	1.2.0-1.el5

Next, disable prelinking by editing /etc/sysconfig/prelink and setting “PRELINKING” to “no”. Previous prelinks should be undone with:

# /usr/sbin/prelink -u -a

You'll need to recreate the initial RAM disk for x86_64 based platforms as follows:

# /sbin/mkinitrd --with-fips -f /boot/initrd-$(uname -r).img $(uname -r)

and for IA64 based platforms as follows:

# /sbin/mkinitrd --with-fips -f /boot/efi/efi/redhat/initrd-$(uname -r).img $(uname -r)

Finally, add “fips=1” as a kernel boot parameter. It's best to do this by editing your grub.conf file.

Once the operating system is operating in “FIPS” mode, you can proceed to address items such as GEN005490 – which requires the Secure Shell Daemon be configured to use the accredited modules. I will cover these specific items in some later posts.

Overall, I am impressed with the “Red Hat 5 STIG” and will be sharing tidbits over the next few months. The Security Blanket development team is working hard to automate the assessment and configuration of your systems to these new guidelines.