Creating a new profile

The process and tools have been tested on Ubuntu 10.04 LTS with AppArmor 2.5.1.

Test plan

In order to successfully profile a program so that it is usable for you, you must exercise the program fully while using AppArmor in complain mode. For example, this will typically include:

Starting the application

Stopping the application

Restarting the application

Go through the man page or help and use all command-line options

Use different parts of the application. Eg, in the case of Empathy, you will want to create some accounts, connect to them, send messages, log messages, etc

Basic process

If not using auditd, temporarily disable kernel rate limiting on logs:

# sysctl -w kernel.printk_ratelimit=0

Create a preliminary profile with tunables and any abstractions you know you will need

Put the profile into complain mode with aa-complain

Execute your test plan (in another terminal if it is a terminal application)

Monitor the logs for AppArmor events

Adjust the profile for these events

Repeat steps 4-6 as necessary

When satisfied, put the profile into enforce mode with aa-enforce

Monitor the logs (optionally using aa-notify) and repeat steps 4-6 as necessary

Example: confining Empathy

In this example we will confine the chat program Empathy.

Disable kernel rate limiting (optional)

$ sysctl -w kernel.printk_ratelimit=0

Create a preliminary profile

First create a preliminary profile, including the global preamble (to pull in variables for HOME and use system aliases. Eg /etc/apparmor.d/usr.bin.empathy:

#include <tunables/global>
/usr/bin/empathy {
}

Then optionally (though in general recommended) add any abstractions or paths we know about. Eg, we know Empathy needs access to system libraries, needs to connect over the network, and is a Gnome application. So add:

#include <abstractions/nameservice>

#include <abstractions/gnome>

Looking at the gnome abstraction, we see it already pulls in the base, fonts, freedesktop.org and X abstractions, so we don't have to include them.

Test the application

Monitor logs

Monitor the logs be looking at/examining the output of any of:

dmesg

/var/log/kern.log

/var/log/messages

aa-notify

People develop different ways of monitoring by hand. When profiling an application from scratch by hand, it is quite helpful to group like accesses together. One way to do this is examining the logs after a denial. Eg, a typical log entry might be:

After updating the profile, you must reload profile with 'apparmor_parser -r'. Eg:

$ sudo apparmor_parser -r /etc/apparmor.d/usr.bin.empathy

Please note if removing access from a profile, you should not use '-r', but instead:

Unload the profile with 'apparmor_parser -R /etc/apparmor.d/<profile>

Load the profile with 'apparmor_parser -a /etc/apparmor.d/<profile>

Restart the application

Fine-tune the profile

As necessary, monitor the logs, modify the profile and reload the profile to fine-tune it for the access you require.

Put in enforce mode

Put the application in enforce mode with aa-enforce. Eg:

$ sudo aa-enforce /etc/apparmor.d/usr.bin.empathy

At this point the application should run confined and work. Because different code paths of the application are exercised when a profile is in enforce mode instead of complain mode, you still need to keep a close eye on the logs for a while, and adjust the profile as necessary.

Profile maintenance

As necessary, monitor the logs, modify the profile /etc/apparmor.d/<profile> and reload the profile to fine-tune it for the access you require. For example, after using the empathy profile for a while then upgrading the OS, it ended up being this: