September 22, 2004
This article was contributed by Jake Edge.
It has taken nearly four years for Security Enhanced Linux (SELinux) to
make its way into some of the more mainstream distributions, but that process
is accelerating. First released by the US National Security Agency (NSA),
in December 2000, SELinux has been incorporated into Fedora Core 2 (and the
test versions of Fedora Core 3), Debian and Gentoo and will likely see more
distributions that support it and more deployments in the future. It
seems like a good time to take an in-depth look at how SELinux can
increase the security of Linux.
Linux, like UNIX, has its security based on what is known as
Discretionary Access Control (DAC) which means that access to objects
is governed by the identity of an authenticated user.
It is discretionary because the user can
(sometimes unwittingly) pass their permissions to others on the system.
A simple "chmod a+w somefile" is an example of a command that
a Linux user can execute that opens up permissions on a file to all
other users in the system.
In addition, any program that is run by a user has at least the
permissions of that user.
This allows malicious, badly configured, or exploitable programs to use
the full permissions of the user executing them and can lead to unexpected
security breaches.
If, for example, the cat program had an exploitable
buffer overrun bug and a particular file could trigger that bug and cause
it to delete the files in a user's home directory, standard Linux access
control would not prevent it. Any user that could be tricked into
executing cat badfile would be susceptible.
SELinux, on the other hand, uses a Mandatory Access Control (MAC)
mechanism that seeks to only allow a program the access it needs to do
its job and not all the access that the user running it has. In the
example above, cat could be configured to only have read
access to any files that the user has read access to
and any attempt to write or delete any file in the system
would be prevented. The administrator can prevent programs from having
unneeded access and only allow the user to grant that portion of their
access that is needed by the normal functioning of the program.
MAC embodies the idea that "those things which are not explicitly
permitted are forbidden."
At its core, SELinux defines a security attribute called a type
and assigns types to various resources
handled by the kernel: processes, files, directories, sockets, etc.
The usage of the term type is unfortunate in that it implies all files
would be one type, all directories another, etc. This is not the case
as each individual resource could have its own type.
Each type in the system is associated with a set of rights for
each other type in the system and
those rights govern what kinds of operations can be performed.
This model is known as Type Enforcement (TE) and is the subject of a
patent granted to Secure Systems Corp. (SSC), one of the contractors that
worked with the NSA on parts of SELinux. At one time there were concerns
that the patent would preclude SELinux from being distributed under the
GPL, but the SSC
Statement of Assurance
seems to have alleviated those concerns.
SELinux augments the traditional TE model with the
addition of Role-Based Access Control (RBAC). Instead of directly
associating a user with a type, RBAC associates users with one or more
roles in the system and associates one or more types with each of
those roles.
The permissions checks are still handled by the TE system and RBAC just
provides a simpler way to manage users.
SELinux provides a much richer set of permissions than the
read, write, execute permissions that UNIX users are used to. There
are separate permissions that govern all of the kinds of operations
you can do on a file (create, delete, rename, unlink, etc.) as well as
specific kinds of permissions for directories, sockets, semaphores, etc.
Permissions are stored as bits in an access vector and SELinux has three
types of these vectors: allowed, auditallow, and auditdeny. The allowed
vector governs whether the operation is permitted. Auditallow and auditdeny
determine whether the operation is logged if it is allowed or denied.
It should be noted that all of the permissions checking that is done by
SELinux is done after the normal Linux permissions checks are performed.
If a user cannot read a file due to the rwx permissions, the
SELinux access control mechanism is not consulted.
One would guess that with all of this fine-grained control over permissions,
SELinux would be very complex to set up and that would be true, but the
NSA and the distributions have done a great deal of the necessary
groundwork. As part of
their release, the NSA also released policy definitions to be used as a
starting point for SELinux administrators. Various distributions have
tweaked these definitions for their specific needs, but it is still a very
complex and somewhat fragile framework. This author had difficulty with
various cron jobs on a Fedora Core 2 SELinux system and the
mailing list
archives have quite a few queries from administrators trying to get
the permissions set correctly for their specific needs. Based on this
message it would appear that Fedora Core 3
has ratcheted down
the checking that SELinux will do in the default install.
An upcoming article will give a more "hands-on" approach to exploring SELinux
using Fedora Core 3 test2 including looks at the policies defined and how
they are used to provide more protection than a standard Linux installation.
Comments (35 posted)
