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 SELinux tools.

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 malicious ones.

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.

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 permission).

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 authorizations somewhere.

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.

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 mailing lists.

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.