Security [LWN.net]

Inside SELinux on Fedora Core 3

October 6, 2004

This article was contributed by Jake Edge.

Following up on a previous overview of Security Enhanced Linux (SELinux), this article looks more closely at the implementation of Security Enhanced Linux (SELinux) in Fedora Core 3 test2 (FC3).

FC3 provides two separate SELinux policies, a default "targeted" policy and the more restrictive "strict" policy. The targeted policy focuses on a handful of specific system daemons and locks down their access while allowing the rest of the system to run using the standard Linux security mechanisms. The FC3 SELinux FAQ describes the reasoning behind the targeted policy:

Initially, when SELinux was included in Fedora Core, the NSA strict policy was enforced. For testing purposes, this helped to find hundreds of problems in the strict policy. In addition, it became obvious that applying a single strict policy to the many environments of Fedora users was not feasible. Managing a single strict policy for anything other than default installation was going to require local expertise.

There are 9 daemons currently handled by the targeted policy, all network services of various sorts (httpd, named, snmpd, etc.) and more daemons will be added to the policy in the future.

The top-level configuration file (/etc/selinux/config) for SELinux on FC3 allows one to choose which of the policies to use and also what enforcement level to use. In particular, the "permissive" level is useful for finding problems in the policy for a specific installation as it just warns when the policy has been violated. Once the policy has been adjusted, the level can be set to "enforcing," which will cause SELinux to enforce the policies. In addition, the enforcement level can be set to "disabled" which effectively turns off SELinux. Any changes made to the configuration file require a reboot to take effect, but the enforcement level can be changed in a running system using the setenforce command.

While changing the enforcement level is painless, the same is not true for changing policies. SELinux uses the extended attributes in Linux filesystems to permanently associate a security context with each file and when changing policies, the attributes of many files in the filesystem must also be changed. The fixfiles command is available to traverse the filesystem and make the required changes based on the information provided in the file_contexts file associated with the policy. file_contexts maps a regular expression describing some subtree of the filesystem (possibly down to an individual file) to a security context and fixfiles (and the related setfiles command) parse this file and set the attributes appropriately. FC3 puts the SELinux configuration in the /etc/selinux directory and the specifics for each policy in /etc/selinux/<policyname>. For example: /etc/selinux/targeted/contexts/file_contexts provides the security context configuration for files in the targeted policy.

To support examining the security context of various entities in the SELinux system, the -Z command line parameter has been added to several standard utilities. The ls, ps, and id commands have been modified to display the security context of files, processes and users respectively and are very useful when diagnosing policy issues.

To get a sense of what goes into the policy configuration and how complex it is, we examined the targeted policy configuration for the ntpd program. Once the selinux-policy-targeted-sources package is installed, the configuration file for ntpd can be found in /etc/selinux/targeted/src/policy/domains/program/ntpd.te. This file specifies the access that the daemon will be allowed to have and should specify all of the system entities (files, sockets, etc.) that the program needs to access for correct operation. The level of detail required in this file is rather eye opening:

Types are defined for the drift file and for the network port used by ntpd

All of the file and directory types that are used by the daemon are also specified with what access is granted for each

Read access is granted for the urandom device

Network access is granted

Access to bind to the udp port that it uses and socket creation access for datagram and stream sockets is granted

Capabilities allowing it to use the nice() system call are granted

etc.

It would appear that a fair amount of work went into figuring out all of the various pieces that go into this configuration for what, at first blush, would seem a fairly simple system daemon. Multiply this level of complexity by the number of daemons in a typical system and one can see why some critics of SELinux call it too complicated to be useful. On the other hand, SELinux does provide very fine grained control over access to system resources and in certain applications, that control is very desirable.

Comments (8 posted)

New vulnerabilities

cups: information leak

Package(s):

cups

CVE #(s):

CAN-2004-0923

Created:

October 5, 2004

Updated:

October 14, 2004

Description:

CUPS has an information leakage problem when printing to SMB shares requiring authentication.

Alerts:

Debian	DSA-566-1	2004-10-14
Gentoo	200410-06	2004-10-09
Fedora	FEDORA-2004-331	2004-10-05

Security

Inside SELinux on Fedora Core 3

cups: information leak

freenet6: file protection problem

net-acct: temporary file vulnerability

netkit-telnet: invalid free pointer

php: information disclosure and file upload vulnerabilities

rp-pppoe, pppoe: missing privilege dropping

samba: unauthorized file access

sharutils: arbitrary code execution

Apache mod_proxy: denial of service

apache: protected pages vulnerability

apache2: stack-based buffer overflow in ssl_util.c

aspell: bounds checking problem

cdrecord: failure to drop privilege

cups: denial of service

Filename disclosure vulnerability in fam

flim: insecure file creation

Foomatic: Arbitrary command execution in foomatic-rip

FreeRADIUS: denial of service

Gaim: remote code execution vulnerability

gtk2, gdk-pixbuf: buffer overflows

getmail: filesystem overwrite vulnerability

glibc: Information leak with LD_DEBUG

gnome-vfs: backend script vulnerabilities

gtkhtml: malformed messages cause crash

apache2: IPv6 denial of service

imagemagick: buffer overflow vulnerability

imlib2: buffer overflows

iproute: local denial of service

jabberd: remote denial of service vulnerability

kdebase: multiple vulnerabilities

kernel information leak

kernel-utils: setuid vulnerability

lha: stack-based buffer overflow

libpng: multiple vulnerabilities

libxml2 - arbitrary code execution

libxpm4: stack and integer overflows

logcheck: symlink vulnerability

Midnight Commander: extfs vfs vulnerability

mikmod: buffer overflow

mod_python: denial of service vulnerability

mozilla products: arbitrary code execution and other vulnerabilities

mpg123: buffer overflow bug

mpg321: format string vulnerability

neon: buffer overflow

netpbm: insecure temporary files

OpenOffice: information disclosure

openssh: timing attack leads to information disclosure

OpenSSL: denial of service vulnerabilities

pavuk: buffer overflow

php: remotely exploitable memory errors

PuTTY: pre-authentication arbitrary code execution problem

python: buffer overflow

qt3: BMP image parser heap overflow

rsync: path-sanitizing bug

ruby: insecure file permissions

sendmail: pre-set password

sox: buffer overflow

SpamAssassin: Denial of Service vulnerability

squid: buffer overflow

SquirrelMail cross site scripting vulnerabilities

Subversion: Remote heap overflow

subversion: metadata information disclosure

sysstat: temporary file vulnerability

File overwrite vulnerability in tar and unzip

tcpdump: ISAKMP payload handling denial-of-service vulnerabilities

Multiple vendor telnetd vulnerability

wv: buffer overflow

XChat 2.0.x SOCKS5 Vulnerability

xine-lib: buffer overflows

xine-ui - insecure temporary file creation

zlib: denial of service