Difference between revisions of "AppArmor"

From ArchWiki
Jump to: navigation, search
(Init scripts)
m (Mounts (/etc/fstab securityfs))
Line 126: Line 126:
=== Mounts (/etc/fstab securityfs) ===
=== Mounts (/etc/fstab securityfs) ===
   securityfs     /sys/kernel/security securityfs defaults            0      0
   none     /sys/kernel/security securityfs defaults            0      0
=== Init scripts ===
=== Init scripts ===

Revision as of 02:40, 5 November 2010

AppArmor is a MAC (Mandatory Access Control) system, implemented upon LSM (Linux Security Modules).

Implementation Status

AppArmor is currently available in Arch Linux kernel and AUR, but we still don't have the user-space tools tested:

It will take some time to make everything work Out-of-the-box.

aur/apparmor package

Added lot of features:

  • apparmor-parser
  • libapparmor
  • apparmor-utils
  • apparmor-profiles
  • apparmor-notify
  • apparmor-lib
  • apparmor-perl
  • apparmor-python
  • apparmor-ruby
  • apparmor-dbus
  • apparmor-profile-editor

But we still miss following features (TODO):

  • init (rc.d) scripts! http://aur.pastebin.com/beQ4BjGX
  • chase missing dependencies
  • test everything
  • make list of files that should go to backup=() arrays in packages...
  • changehat modules for PAM(!), Apache and Tomcat (btw those are dependent on libapparmor)
  • out-of-box-experience know-how
    • make some package with profiles for all [core] packages enabled by default without need for any further user configuration
    • etc...
  • apparmor gnome applet (can't build, deprecated...)

When compared to Ubuntu

we have almost everything that is in following Ubuntu packages:

  • apparmor
  • apparmor-profiles
  • apparmor-utils
  • apparmor-notify
  • apparmor-docs
  • libapparmor1
  • libapparmor-dev
  • libapparmor-perl

We don't have


AppArmor Packages

  • kernel26 2.6.36 (currently in [testing] have AppArmor support)
  • aur/apparmor

Kernel Configuration

Here is configuration of ArchLinux kernel which enables AppArmor (just FYI, you don't need to touch it):


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 on top of the 2.6.36 kernel to reintroduce these interfaces, but do not currently build against the Arch Linux kernel.

GRUB Configuration


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 /boot/grub/menu.lst so the entry for the Arch Linux kernel looks something like

# (0) Arch Linux
title  Arch Linux [/boot/vmlinuz26]
root   (hd0,1)
kernel /boot/vmlinuz26 root=/dev/sdaX resume=/dev/sdaY ro apparmor=1 security=apparmor
initrd /boot/kernel26.img

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 /boot/grub/menu.lst. 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 /etc/shadow) before booting. You can also password protect any insecure entries in /boot/grub/menu.lst 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 to 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 CDs and USB sticks, gaining root access to the machine.



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

 # (0) Arch Linux
 menuentry "Arch Linux" {
   set root=(hd0,1)
   linux /vmlinuz26 root=/dev/sda1 ro apparmor=1 security=apparmor
   initrd /kernel26.img

After reboot you can test if apparmor is really enabled using this command as root:

 # cat /sys/module/apparmor/parameters/enabled 

(Y=enabled, N=disabled, no such file = module not in kernel)


AppArmor will be disabled by default in ArchLinux, so you will not need to disable it explicitly until you will build your own kernel with AppArmor enabled by default.

 # (0) Arch Linux
 menuentry "Arch Linux" {
   set root=(hd0,1)
   linux /vmlinuz26 root=/dev/sda1 ro apparmor=0 security=""
   initrd /kernel26.img

System Configuration

Mounts (/etc/fstab securityfs)


 none     /sys/kernel/security securityfs defaults            0      0

Init scripts

In future we'll implement some /etc/rc.d/ scripts that will enable and load profiles during startup. http://aur.pastebin.com/beQ4BjGX The RC.d file of Slackware might be more interesting than ubuntu's init.d version http://sprunge.us/IbeJ

For developers

from /lib/apparmor/rc.apparmor.functions

 # NOTE: rc.apparmor initscripts that source this file need to implement
 # the following set of functions:
 # aa_action
 # aa_log_action_start
 # aa_log_action_end
 # aa_log_success_msg
 # aa_log_warning_msg
 # aa_log_failure_msg
 # aa_log_skipped_msg
 # aa_log_daemon_msg
 # aa_log_end_msg

UserSpace Tools


You can currently install userspace tools from AUR.


You need userspace tools that are compatible with your kernel version. The compatibility list can be found here: https://apparmor.wiki.kernel.org/index.php/AppArmor_versions eg.: Kernel 2.6.36 is compatible with AppArmor 2.5.1

More Info

Ubuntu, Suse and a number of other Linux distributions use it. Redhat uses SELINUX which is apparently a little bit more difficult to configure properly. There exists another framework called Tomoyo but it is not currently integrated with any distributions.

It suplements, rather than replaces the standard POSIX access control system.

What you can do with it is very easily create profiles for applications which either acccess the Internet or listen via IP (e.g servers).

One may specify at quite a fine grained level what applications may or may not do.

Taking a common example - Firefox is frequently the victim of Zero day exploits. If you were to browse to a website that ran a buffer overflow or such thing against your browser - all data accessible to Firefox would then belong to the attackers, think SSH keys, password stores etc etc.

Likewise Wireshark (tcpdump) has had decoder modules with buffer overflows before, imagine the scenario - you suspect a server has been compromised, run a packet capture on the network, and then your own machine is compromised (tcpdump must run as root).

For both these applications, apparmor profiles exist. The configuration is stored in easy to read text files in /etc/apparmor.d/<application name>.

You can lock down your applications using wildcards, specifying for example that Firefox can only read the ~/Downloads folder and it's own profile directory, that it cannot create shell processes etc.

Every breach of policy triggers a message in the syslog, many distributions also integrate it into DBUS so that you get realtime violation warnings popping up on your desktop.

See also