[ << ]
[ < ]
[ Home ]
[ > ]
[ >> ]
1. Enhancing Linux Security
A Warm Welcome
Welcome to the Gentoo SELinux handbook. In this resource, we will bring you up
to speed with Gentoo Hardened's implementation of SELinux and the policies
involved. Part of this exercise is to help you understand why SELinux was
brought to life and which concept is behind the development of the SELinux
patches. We will cover the SELinux concepts, the reference policy that Gentoo
Hardened uses and elaborate on how to work with the various SELinux tools.
The purpose of this book is not to explain SELinux itself in great detail. There
are many references available on the Internet and in the better bookstores that
help you with the SELinux topic. Instead, we will focus on SELinux integration
within Gentoo Hardened. Of course, we will give a quick introduction to SELinux
to allow you to understand how it works, what it is and help you identify which
actions you will need to take in order to properly secure your system using the
1.b. Securing Linux
Security In General
Security is often seen as a vague concept. What is security in general? How do
you measure security? What is the benefit and how do you make sure you do not
put too much effort in securing your system?
Well, security zealots will tell you that there is no such thing as too much
security. If properly implemented, security does not restrict functionality or
performance. It does not give you too much overhead in order to do your tasks.
But implementing security properly is a different and time-consuming task. That
is also why you often hear that security is as good as its administrator.
So, how can you look at security? A good practice on security is to define your
security goals. List what you want to achieve and why. By tracking the threats
that you want to minimize, you build up a security model that is appropriate for
your environment. Such threats can be very broad, such as "Ensure no-one is able
to work around our security measures".
In case of a Linux system powered with SELinux, this would at least mean that
you want to protect critical system files, such as kernel image(s) and boot
loader configuration, passwords and the SELinux policy binary itself from being
written by anyone or anything except trusted processes.
A decent access control system (or group of systems) ensures that only
authorized individuals or processes are granted access to the resources they are
tring to work with.
Before one can implement an access control system, you first need to have proper
authentication in place. If your authentication schemes are flawed, your access
control system might not be able to differentiate legitimate users from
Authenticating users within Linux is often done through PAM (Pluggable
Authentication Modules), a powerful mechanism to integrate multiple
low-level authentication schemes into a high-level interface.
Authorizing access to resources however is often done through a simple
permission scheme. Most resources are not hidden by default, although
patches and updates exist (such as those offered by Gentoo Hardened's
kernel sources with grSecurity patches which includes support for this
kind of measures). File-system wise, you can hide the existence of files
by ensuring the directory in which the file resides is not readable nor
"executable" by unauthorized accounts.
This default permission scheme has major drawbacks. It does not allow you to
define very flexible authorizations (it only allows permissions on three levels:
owner, group-owner and everybody else) and is limited to read/write/execute
rights (although a few additional attributes are supported nowadays as well).
Another drawback is that the permission scheme is discretionary, meaning
that users and processes are able to change the security policy in place.
For the majority of uses, this permission scheme is sufficient and has proven to
offer a decent method for managing access authorizations. But the drawbacks have
shown to be a major hole in the Linux' offering.
1.c. Mandatory Access Control
If the above mentioned discretionary access control, abbreviated to DAC,
is not sufficient (and if you are keen on security, you will not find it
sufficient), you need a Mandatory Access Control, or MAC system.
When using a MAC system, activities that a process wants to perform on another
resource need to be explicitly allowed. It offers a higher granularity on
permissions as well as resources. They often support not only files, but also
sockets, ports, memory segments, queues, processes, kernel services, system
calls, devices, file systems and more. The granularity of activities supported
is also quite large. For files, this can be append, create, execute, write,
link, ioctl, get- and setattr, read, rename, lock, ... whereas for sockets this
might be append, bind, connect, create, write, sendto, accept, ... Also, when
using a MAC system, no user or process can manipulate the security policy
itself: what the security administrator has defined cannot be overturned.
This is where SELinux comes to play. SELinux is a Linux kernel feature which
implements, amongst other things, a MAC system for controlling and governing
access to various resources. It uses a deny-by-default permission scheme, so any
access that a process wants to perform needs to be explicitly granted.
SELinux also allows you to put a finer-grained permission model on top
of the traditional DAC system (which is still in use when using SELinux
- in other words, if the traditional system does not allow certain activities,
it will not be allowed even if there are SELinux policies granting the
What is SELinux
To support this finer-grained permission model, you would think that changes
are needed to the Linux kernel. Yet thanks to the Linux kernel LSM
interface (Linux Security Modules), support for SELinux was easily added
and since the 2.6 kernel series, SELinux has been integrated in the mainstream
kernel release. But supporting SELinux and using SELinux are very different topics.
In order to properly identify resources, SELinux needs to assign labels to these
resources. When the resources are in-memory, this is mostly supported by the
Linux kernel itself, but for persistent resources such as files, these labels
need to be placed somewhere. SELinux has chosen to use a file's extended
attributes (which is stored on the file system itself). The advantage here is
that a label remains on the file even if the file is renamed. A disadvantage of
this approach is that the file system must support extended attributes,
which not all file systems do (or have activated).
SELinux also uses roles to govern resource access. A user that does not have
access to the system administration role should never be allowed to execute any
system administration activities even if he is able to escalate its privileges
(say through a set-uid application). To support roles, SELinux requires changes
to the authentication services (PAM) and needs to store role definitions and
Next to the kernel support and labels assigned to the resources and support
within the authorization system, SELinux also requires particular tools to
support the SELinux features. Examples are administrative tools to view and
manipulate labels, privilege management tools (like sudo), system
services (like SysVInit) etc. This is reflected in a set of patches
against these (and more) tools which are not always part of the applications'
main source code.
Gentoo Hardened and SELinux
What Gentoo Hardened offers is SELinux integrated in the distribution. When you
select SELinux support, Gentoo Hardened will apply the necessary patches against
the applications and help you (re)label your files and other resources to become
SELinux-manageable. Gentoo Hardened also integrates SELinux support inside
Portage, allowing for newly installed files to be automatically labeled and to
use a SELinux-supporting sandbox environment for
safe package building.
Next to the pure technological support, we hope that you will also find the
necessary supporting documents, guides, experience and on-line support for using
SELinux within Gentoo. Never hesitate to come and say hi on the
#gentoo-hardened chat channel in the Freenode IRC network or on our
If you believe that SELinux is the right thing for you and you want to try it
out using Gentoo Hardened, please read on. The next chapter will inform you how
SELinux security is "designed" and how it is conceptually structured. Further
chapters will then help you with the authorization language and the "base"
policies that most distributions start from, and finally help you install,
run and manage a SELinux hardened Gentoo system.
[ << ]
[ < ]
[ Home ]
[ > ]
[ >> ]
The contents of this document, unless otherwise expressly stated, are licensed under the CC-BY-SA-2.5 license. The Gentoo Name and Logo Usage Guidelines apply.