Introduction to AppArmor Profiles

AppArmor profiles are simple text files. Absolute paths as well as file globbing can be used when specifying file access. Most file access rules specify the type of access which is allowed: ‘r’ (read), ‘w’ (write), ‘m’ (memory map as executable), ‘k’ (file locking), ‘l’ (creation hard links), and ‘ix’ to execute another program with the new program inheriting policy. Other file access rules also exist such as ‘Px’ (execute under another profile, after cleaning the environment), ‘Cx’ (execute under a child profile, after cleaning the environment), and ‘Ux’ (execute unconfined, after cleaning the environment).

AppArmor supports access controls for:

• files
• Linux capabilities
• network
• mount, remount and umount
• pivot_root
• ptrace
• signal
• DBus
• unix domain sockets

In addition:

• variables (eg @{HOME} can be defined and manipulated outside the profile (#include <tunables/global> for @{PROC} and @{HOME})
• explicit deny rules are supported to override allow rules (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>)

To get started, let’s install some useful AppArmor utilities and the application that we want to confine:

sudo apt install apparmor-easyprof apparmor-notify apparmor-utils certspotter

Generating a basic profile

The easiest way to get started is to create a skeleton profile, set AppArmor to complain mode for your target and then use the aa-logprof tool to evaluate the denials.

We’ll use aa-easyprof to generate the skeleton policy; let’s see what it generates (be sure to specify the absolute path to the application):

$ aa-easyprof /usr/bin/certspotter

# vim:syntax=apparmor
# AppArmor policy for certspotter
# ###AUTHOR###
# ###COPYRIGHT###
# ###COMMENT###

#include <tunables/global>

# No template variables specified

"/usr/bin/certspotter" {
#include <abstractions/base>

# No abstractions specified

# No policy groups specified

# No read paths specified

# No write paths specified
}

Looks pretty basic, so let’s write that output into the profile file (the name of the file can be anything; it is the contents of the file which matter):

$ aa-easyprof /usr/bin/certspotter > usr.bin.certspotter
$ sudo mv usr.bin.certspotter /etc/apparmor.d

and then load the profile into the kernel:

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

Trying to run certspotter, results in an immediate (safe) crash.

$ certspotter
certspotter: /home/testuser/.certspotter/watchlist: open /home/testuser/.
certspotter/watchlist permission denied

This basic profile doesn’t allow certspotter access to resources it needs, so let’s look at the AppArmor denial messages to see what went wrong.

AppArmor Denials and Complain Mode

AppArmor denials are logged to /var/log/syslog (or /var/log/audit/audit.log for non-DBus policy violations if auditd is installed). The kernel will rate limit AppArmor denials which can cause problems while profiling. You can avoid this by installing auditd or by adjusting rate limiting in the kernel:

$ sudo sysctl -w kernel.printk_ratelimit=0

Another way to to view AppArmor denials is by using the aa-notify tool. aa-notify is a very simple program that will report any new AppArmor denials by consulting /var/log/syslog (or /var/log/audit/audit.log if auditd is installed). For example,

$ /usr/bin/aa-notify -s 1 -v

will show any AppArmor denials within the last day.

We are going to take the easy route to develop this profile and use the aa-logprof tool to evaluate the log entries that AppArmor makes in complain mode, so let’s set the AppArmor profile for certspotter to complain mode for this policy so that we can see what is happening.

$ sudo aa-complain certspotter

Now let’s try running certspotter again:

$ certspotter

It immediately starts generating AppArmor entries in the logs that look like this:

Hand Editing the Profile

Let’s go back and touch up the profile to allow certspotter to read and write from the $HOME/.certspotter directory.

$ sudo vi /etc/apparmor.d/usr.bin.certspotter

let’s change the /home/*/.certspotter/watchlist r, line to owner @{HOME}/.certspotter/** rw,. The ** glob means certspotter can now read and write to all files, directories and all paths under the current user’s .certspotter directory in their home directory. You can take this opportunity to touch up the ###AUTHOR###, ###COPYRIGHT###, and ###COMMENT### placeholders with your preferred information. Reload the policy once again:

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

Tips for evaluating your AppArmor policy

Some tips when evaluating your AppArmor policy:

• AppArmor provides additional permission checks to traditional Discretionary Access Controls (DAC). DAC is always checked in addition to the AppArmor permission checks. As such, AppArmor cannot override DAC to provide more access than what would be normally allowed.
• AppArmor normalizes path names. It resolves symlinks and considers each hard link as a different access path.
• Deny rules cannot be overridden by an allow rule.
• Creation of files requires the create permission (implied by w) on the path to be created. Separate rules for writing to the directory of where the file resides are not required. Deletion works like creation but requires the delete permission (implied by w). Copy requires ‘r’ of the source with create and write at the destination (implied by w). Move is like copy, but also requires delete at source.
• The profile must be loaded before an application starts for the confinement to take effect, but policy may be reloaded will the application is running with the rules taking effect immediately. You will want to make sure that you load policy during boot before any confined daemons or applications. This is done for you in Ubuntu.