SELinux and AppArmor: An Introductory Comparison

In another article, Hardening Linux Systems in the Application Layer: Why It's Important, I
explained the importance of hardening our Linux systems by reinforcing the security policy in the
application layer too. As I said, SELinux is not the only available tool for this purpose. AppArmor is
another well known one, while FreeBSD users have TrustedBSD.
A Linux administrator, or even (why not?) a Linux home user, could ask which one is better. As always
when one asks a question like this, the answer is that it depends... Anyway, some clear guidelines are
given if you read the rest of this article.
First of all, a very short history and introduction. Regarding the version I refer to, I tried:

OpenSUSE 10.2 with its default AppArmor 2.0.1;
Fedora Core 4, Fedora Core 6, Fedora 7, Fedora 8, CentOS 5.0 with their default SELinux
installation.

AppArmor
AppArmor was born as a commercial product. Developed by Immunix, only recently (January 2006) it
was made an open source product by Novell. With AppArmor you can immunize applications (as the
name Immunix suggests), protecting them from vulnerabilities. Given any program (executable,
commands script, daemon...), one can decide to protect it with AppArmor, then she/he creates a profile
associated to such application, where all that the application can do will be explicitly listed (and what is
not in the list cannot be done).
AppArmor is shipped by default with Suse Linux (OpenSUSE, Enterprise...) and is comfortably
supported by Yast, the GUI system configuration tool, but you can use it with other distributions too.
Suppose you want to reinforce your security policy immunizing a program X. What you usually will do
is:

(1) Look inside the directory /etc/apparmor/profiles/extras, where you could find a profile already
written for your specific program X (a number of profiles are given by default for common
programs).
(2) If there is a profile for X, copy it in the folder /etc/apparmor.d.
(3) If there is not such a ready profile, begin creating one, even an empty one, as you can iteratively
try it and add privileges any time you need them. At the end of the learning procedure the
profile will allow all operations users need to do (eventually, if you missed some, you can add
other privileges after the users' complaints), and no more: principle of the least privilege!

Very easy in principle and user friendly, even if some technical complications can take place, of course,
above all if the applications to be protected are complex. The security policy is reinforced immunizing
applications one by one.
In figure 1 you see the AppArmor main configuration window in Yast.


Figure 1
Configuri
ng
AppArmo
r with
Yast
(main
window)


SELinu
x
SELinux has older origins, starting from operating systems security research in the 1980s, mainly by
the National Security Agency (NSA), even if the first SELinux release was in December 2000. The
leading company in integrating SELinux in its Linux distribution is Red Hat.
If you have SELinux enabled in your system, many objects have supplementary labels meant for
SELinux access control. The access control is based on the security context, associated to an object,
which is made of three basic elements (user, role and type) plus other attributes (levels, categories...)
Just try some commands on the shell, such as ls -Z, ps -Z and id -Z, and see the corresponding man
pages. Even man pages for common Unix commands are integrated with SELinux related options.
SELinux has completely permeated your system because it is meant to include the whole system, not to
be partial, limited as AppArmor.
The process of creating a specific policy retailed for a user's program is vaguely similar to that of
AppArmor, but it can soon become complicated, at least if what you want to do is out of the limited
standard options; if you want to to something personalized, retailed for your specific needs, there are
some tools to do it but more than one more article is needed to explain how (and only for relatively
simple cases).
For the most common cases, you simply set some options, such those you can see in figure 2.

Figure 2 Some options in SELinux Administration (Fedora 8)


What they have in common
These two software products, very helpful in allowing the administrator to reinforce the security policy,
have lot of features in common, that is, mainly:

They are both focused on access control, reinforcing the standard Linux access control policy.
They both produce logs and give instruments for audit activity.
They work inside the application layer.
Technically, they use LSM (Linux Security Module) to interact with the Linux Kernel.
They allow the administrator to work with GUI and not GUI tools.
They allow the administrator to try policies without really blocking accesses (just alerting about the
policy violations), in order to apply the security reinforcing policy only after a satisfactory number
of tests.

A comparison
Now a short list of differences and a comparison. The first consideration is:

If you use a Red Hat-like distribution (Red Hat, Fedora, CentOS, etc.), the most natural thing is to
use SELinux, available by default.
If you use a Suse-like distribution, the most natural choice is to use AppArmor, available by default.
If you use another distribution (Ubuntu for instance), you can generally install both SELinux and
AppArmor, just you are a bit less comfortable.

The most natural thing means that you have the application and at least some related tools available
by default, without the problems of searching through the online packages, of versions compatibility, of
availability or not of certain related tools, etc. You immediately have GUI and non-GUI tools that make
your job easy (or at least represent an effort to make it easy).

The second aspect to be considered is the completeness and the level of security offered by this two
open source products. Here there is no doubt: SELinux is surely a more complete and ambitious
security tool than AppArmor. SELinux is a wide universe, it permeates everything, it potentially labels
every object in the system and conceptually elevates the system to a more sophisticated security
infrastructure, it allows you to implement all main security paradigms in access control theory; even
military and government organizations can use it for their strict security needs.
With SELinux it is possible to implement MAC (Mandatory Access Control), MLS (Multi-Level
Security, with Bell-La Padula and Biba models), MCS (Multi-Category Security), RBAC (Role
Based Access Control), TE (Type Enforcement). Besides, SELinux is based on the default deny
principle. AppArmor, on the other hand, simply lets you define what a single application can and
cannot do, according to the principle of least privilege but without the implementation of complete
security paradigms like those mentioned. AppArmor has a default deny approach to the single
immunized application but a default permit approach to the rest of the system, that is: once you decide
an application is protected by AppArmor, the default deny principle applies to it, while anything that is
not immunized is simply not considered by AppArmor, following the default permit approach.
It can be that you're not inside a military organization, or simply that you're not interested in high level
security but have low or medium level needs: in this case AppArmor can be enough.

The third aspect is the user friendliness and consequently the time required to master the tools (the so
called learning curve). Here AppArmor wins by large: you can become productive using AppArmor
already in the first days you try to use it, there is nothing particularly complicated to be understood, no
particular theory to be studied except the technical guide to use the tools. The tools you can use to
administer AppArmor are all from Suse/Novell, are well integrated, coherent, without the need of
installing various software from different sources and without version compatibility problems. Among
other things, Yast give you the possibility of easily configuring automatic incident reports which are
sent by email.
SELinux, on the contrary, is famous for not being easy to use. Being more complex, you have much
more to study just to understand what you are doing, what SELinux is. If you're not careful, you can
find yourself no more able to login into the computer, just because you have unintentionally activated a
default deny policy that blocks a lot of things by default, or, less dramatically, you can discover that the
reason because you can't make you printer work is that SELinux prevented it from printing (acting on
the CUPS service)... If you plan to use SELinux, do exercise far from the production environment for a
learning period, even if the Permissive Mode is given with the purpose of letting you try policies before
actually applying them. I found some difficulties in using some tools, the coherence of the versions of
the various components cannot be taken always for granted. SELinux developers are conscious of the
user friendliness problem and are making significant efforts to improve this aspect, so if you use a
recent version of you Linux distribution (for example Fedora 7 or 8, compared to previous
distributions) you immediately see enhancements of GUI tools in the security-related tasks and
particularly concerning SELinux. I tried CentOS 5.0 too and the GUI configurability (with the default
tools) of SELinux is inferior to that of Fedora, but the SELinux Troubleshooting tool works well and is
very useful.
Using GUI tools is useful at least during an initial learning period, then the administrator can work at
command line with production servers.

As the fourth aspect to be considered, let's talk about performance, that is the computational overhead,
the price you have to pay to have such an additional tool in order to reinforce the security policy. Both
AppArmor and SELinux add control operations to the traditional Linux system, they add conditions to
those of the traditional system (like in a logical AND) and this is done by means of the LSM. I
personally didn't make specific performance tests, but let's see what is declared about this aspect. In the
Novell AppArmor Administration Guide it is said that AppArmor overhead is between 0% and 2%
while that of SELinux is between 6% and 15%. So you deduce AppArmor has better performances, but
take this with caution, first of all because it is declared by Novell itself and not a third-party
organization, second because SELinux can take more time because it does more, it is a more complete
instrument that does more things. Fedora Core 5 declares an overhead of about 7%
(http://docs.fedoraproject.org/selinux-faq-fc5/#id2965028), again bigger than AppArmor's. In any case,
I have no reports of complaints about performance from system administrators keeping SELinux active.

Finally, fifth and last aspect for comparison I consider in this article is the availability of
documentation. SELinux available documentation is much more that that of AppArmor, even if not
particularly rich in absolute terms. First of all you have to consider that SELinux is more complex, so
there is more to write about it. With AppArmor you find, essentially, only Novell official
documentation, while SELinux appears as a more open and varied environment, with third party
articles and books, both from academic and business world.