Much Ado About Nothing

Hendrik Weimer


Normal version

When Novell released its AppArmor security suite under the GPL it created quite a media buzz. But since many people believe that the open source development model leads to better code quality, projects that are derived from a proprietary code base often arouse suspicion. The goal of AppArmor is to limit security breaches to a single process and to prevent compromising the entire system.

AppArmor runs only under Linux and requires the application of two kernel patches. Fortunately the published patches are not against the heavily modified SuSE kernels but against a vanilla version of 2.6.15.x. Additionally, before using AppArmor you have to download a parser, a utilities package and a library. Some scripts come with a proprietary license boilerplate, but let's assume that Novell simply overlooked them.

Each process can be configured individually, and it is possible to use AppArmor for only a few programs but not the entire system. The config file syntax is pretty straightforward and well explained in the documentation. The basic options for each program are given by supplying which files the process should read, write or execute. For execution, there are several modes which determine whether the current profile should be inherited or not.

Usually, you don't know in advance which files a process needs to have access to. Therefore, there is a so-called "monitor mode" in which AppArmor complains in a log file each time it does not have sufficient permissions.

The most important question for AppArmor is to ask in which scenarios in can provide a reasonable security improvement. The problem is, there aren't many. The main benefit is for systems where there are multiple services running, so that if your mail server is compromised your Samba shares are still secure. But such things have been implemented using UNIX permission decades ago and this hardly justifies setting up a complex security suite.

Another shortcoming is the inability to effectively limit the harm a process can do. On the first sight it sounds good that AppArmor supports POSIX capabilities, but these are for increasing the privileges of a process and not taking some away. And this won't be of much use anyway, since many services have now developed there own schemes for privilege separation.

For example, it would often be extremely desirable to prevent a process from accessing the network. Then a parser processing user-supplied data could not be abused as a beachhead scanning for vulnerable services like a SQL server in the back-end. Another important feature would be limiting the system calls an application can execute in order to reduce the risk of local root exploits due to kernel vulnerabilities (and there have been many in the past). These features are not unrealistic as SELinux provides them.

So unless these problems are fixed, AppArmor can hardly be used to improve the security of a system. We can only hope that Novell didn't release AppArmor under the GPL because they realized what a broken product it is.

Distributions: [?]□ Debian stable□ Debian unstable
□ Fedora□ Mandriva
■ Suse□ Ubuntu


  • Easy generation of profiles
  • No policies for network and syscall usage

Copyright 2006–2008 OS Reviews. This document is available under the terms of the GNU Free Documentation License. See the licensing terms for further details.