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.
(
Log in to post comments)