AppArmor ("Application Armor") is a security module for the Linux kernel, released under the GNU General Public License. AppArmor allows the system administrator to associate with each program a security profile that restricts the capabilities of that program. It supplements the traditional Unix discretionary access control (DAC) model by providing mandatory access control (MAC). It was included as of the 2.6.36 version of the mainline Linux kernel. Since 2009, Canonical Ltd. contributes to the ongoing AppArmor development.
In addition to manually specifying profiles, AppArmor includes a learning mode, in which violations of the profile are logged, but not prevented. This log can then be turned into a profile, based on the program's typical behavior.
AppArmor is implemented using the Linux Security Modules (LSM) kernel interface.
AppArmor is offered in part as an alternative to SELinux, which critics consider difficult for administrators to set up and maintain.[1] Unlike SELinux, which is based on applying labels to files, AppArmor works with file paths. Proponents of AppArmor claim that it is less complex and easier for the average user to learn than SELinux.[2] They also claim that AppArmor requires fewer modifications to work with existing systems:[citation needed] for example, SELinux requires a filesystem that supports "security labels", and thus cannot provide access control for files mounted via NFS. AppArmor is filesystem-agnostic.
AppArmor represents one of several possible approaches to the problem of restricting the actions that installed software may take.
The SELinux system generally takes a similar approach to AppArmor. One important difference is that SELinux identifies file system objects by inode number instead of path. This means that, for example, while a file that is inaccessible may become accessible under AppArmor when a hard link is created to it, SELinux would deny access through the newly created hard link.
While there has been considerable debate about which approach is better, there is as yet no strong evidence that either approach is preferable. Discussion about their relative merits often revolves around which approach is more aligned with existing Unix/Linux access control mechanisms, but Unix and Linux use a combination of path-based and inode-based access control. Note also that existing access control mechanisms remain in place with either system.[citation needed]
SELinux and AppArmor also differ significantly in how they are administered and how they integrate into the system.
Introduction
AppArmor is a Mandatory Access Control (MAC) system which is a kernel (LSM) enhancement to confine programs to a limited set of resources. AppArmor's security model is to bind access control attributes to programs rather than to users. AppArmor confinement is provided via profiles loaded into the kernel, typically on boot. AppArmor profiles can be in one of two modes: enforcement and complain. Profiles loaded in enforcement mode will result in enforcement of the policy defined in the profile as well as reporting policy violation attempts (either via syslog or auditd). Profiles in complain mode will not enforce policy but instead report policy violation attempts.
AppArmor is different from some other MAC systems on Linux in that it is path-based, allows for mixing of enforcement and complain mode profiles, uses include files to ease development and has a far lower barrier to entry than other popular MAC systems.
AppArmor is an established technology first seen in Immunix, and later integrated into Ubuntu, Novell/SUSE, and Mandriva. Core AppArmor functionality is in the mainline Linux kernel from 2.6.36 onwards; work is ongoing by AppArmor, Ubuntu and other developers to merge additional AppArmor functionality into the mainline kernel.
Example profile
From /etc/apparmor.d/usr.sbin.tcpdump on Ubuntu 9.04:
#include <tunables/global>
/usr/sbin/tcpdump {
#include <abstractions/base>
#include <abstractions/nameservice>
#include <abstractions/user-tmp>
capability net_raw,
capability setuid,
capability setgid,
capability dac_override,
network raw,
network packet,
# for -D
capability sys_module,
@{PROC}/bus/usb/ r,
@{PROC}/bus/usb/** r,
# for -F and -w
audit deny @{HOME}/.* mrwkl,
audit deny @{HOME}/.*/ rw,
audit deny @{HOME}/.*/** mrwkl,
audit deny @{HOME}/bin/ rw,
audit deny @{HOME}/bin/** mrwkl,
@{HOME}/ r,
@{HOME}/** rw,
/usr/sbin/tcpdump r,
}
The above profile for tcpdump demonstrates several properties of AppArmor:
- profiles are simple text files
- comments are supported in the profile
- absolute paths as well as file globbing can be used when specifying file access
- various access controls for files are present. From the profile we see 'r' (read), 'w' (write), 'm' (memory map as executable), 'k' (file locking), and 'l' (creation hard links). There are others not demonstrated in this profile, including (but not limited to) 'ix' (execute and inherit this profile), 'Px' (execute under another profile, after cleaning the environment), and 'Ux' (execute unconfined, after cleaning the environment)
- access controls for capabilities are present
- access controls for networking are present
-
specificity in rule matching, ie the most specific rule matches (eg access to @{HOME}/bin/bad.sh is denied with auditing due to 'audit deny @{HOME}/bin/** mrwkl,' even though general access to @{HOME} is permitted with '@{HOME}/** rw,')
-
include files are supported to ease development and simplify profiles (ie #include <abstractions/base>,#include <abstractions/nameservice>, #include <abstractions/user-tmp>)
-
variables can be defined and manipulated outside the profile (#include <tunables/global> with @{PROC} and @{HOME})
-
AppArmor profiles are easy to read and audit
Please see More information below for full details on updating and developing profiles as well as instructions using AppArmor.
AppArmor in Ubuntu
AppArmor support was first introduced in Ubuntu 7.04, and is turned on by default in Ubuntu 7.10 and later. AppArmor confinement in Ubuntu is application specific with profiles available for specific binaries. With each release, more and more profiles are shipped by default, with more planned.
If a profile is not available for an application, users may create a profile and add it to /etc/apparmor.d. If a profile is not defined for a particular binary, the binary is not confined. See More information for details.