AppArmor Packages

Kernel Configuration

CONFIG_SECURITY_APPARMOR=y
CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE=0
# CONFIG_DEFAULT_SECURITY_APPARMOR is not set

However, integration of AppArmor into the 2.6.36 kernel is not quite complete. It is missing network mediation and some of the interfaces for introspection. See here for details. There are compatibility patches that can be applied to every recent kernel to reintroduce these interfaces. The patchset is pretty small and should be applied if you decide to use AppArmor. (Note: the patchset for 2.6.39 works with Kernel 3.0.x)

GRUB Configuration

GRUB1

To test profiles, or enforce the use of AppArmor it must be enabled at boot time. To do this add apparmor=1 security=apparmor to the kernel boot parameters in Template:Filename so the entry for the Arch Linux kernel looks something like

Once you are happy with all your profiles, you may wish to force users to boot with AppArmor enabled. To do this add a password entry to the start of Template:Filename. This will prevent users editing any boot entries or using the Grub shell (which permits read access to any file on the system such as Template:Filename) before booting. You can also password protect any insecure entries in Template:Filename that you do not want unauthorized users to boot by adding the lock command (or another password) immediately below the title line for that entry. See Grub#Password_protection or Security in the Grub Manual for more details. If you are going through the trouble of securing Grub, don't forget to secure your BIOS settings as well or users will be able to boot from their own CD's and USB sticks, gaining root access to the machine.

GRUB2

Enable

Note that you can safely enable AppArmor and it will not affect the system at all until you enable it, load profiles, and set them to enforce mode with userspace tools. So you don't have to be afraid to enable AppArmor for testing purposes until you are enforcing AA profiles from init scripts (on each startup).

More Info

AppArmor, like most other LSMs, supplements rather than replaces the default Discretionary access control. As such it's impossible to grant a process more privileges than it had in the first place.

Ubuntu, SUSE and a number of other distributions use it by default. RHEL (and it's variants) use SELinux which requires good userspace integration to work properly. People tend to agree that it's also much much harder to configure correctly.

Taking a common example - A new Flash vulnerability: If you were to browse to a malicious website AppArmor can prevent the exploited plugin from accessing anything that may contain private information. In almost all browsers, plugins run out of process which makes isolating them much easier.

AppArmor profiles (usually) get stored in easy to read text files in Template:Filename

Every breach of policy triggers a message in the system log, and many distributions also integrate it into DBUS so that you get real-time violation warnings popping up on your desktop.