Skip to content

Guidelines

Common structure

AppArmor profiles can be written without any specific guidelines. However, when you work with over 1500 profiles, you need a common structure among all the profiles.

The logic behind it is that if a rule is present in a profile, it should only be in one place, making it easier to review profiles.

For example, if a program needs to run executable binaries then the rules allowing it can only be in a specific rule block (just after the @{exec_path} mr, rule). It is therefore easy to ensure some profile features such as:

  • A profile has access to a given resource
  • A profile enforces a strict write xor execute (W^X) policy.

It also improves compatibility and makes personalization easier thanks to the use of more variables.

Why does it matter?

The structure presented below is more important than it looks. Without this it would be easy to miss some rules when reviewing profiles, making the whole system more opaque and less secure.

Guidelines

In order to ensure a common structure across the profiles, all new profile must follow the guidelines presented here.

The rules in the profile should be written in blocks of same rule type. Each block should be sorted in the profile as follows:

Order Name Example
1 include
2 set rlimit
3 userns
4 capability
5 network
6 mount
7 remount
8 umount
9 pivot_root
10 change_profile
11 mqueue
12 signal
13 ptrace
14 unix
15 io_uring
16 dbus
17 file
18 local include

This rule order is taken from AppArmor with minor changes as we tend to:

  • Divide the file block into multiple subcategories
  • Put the block with the longer rules (files, dbus) after the other blocks

File sub-blocks

The file block is usually the longest block in a profile. It should be written in sub-blocks of identical file types. The file sub blocks must be sorted as follows.

Order Description Example Link
1 The entry point of the profile @{exec_path} mr,
2 The binaries and library required @{bin}/, @{lib}/, /opt/. It is the only place where you can have mr, rix, rPx, rUx, rPUX rules.
3 The shared resources /usr/share
4 The system configuration /etc
5 The system data /, /var, /boot
6 The user data owner @{HOME}/
7 The user configuration, cache and dotfiles @{user_cache_dirs}, @{user_config_dirs}, @{user_share_dirs}
8 Temporary and runtime data /tmp/, @{run}/, /dev/shm/
9 Sys files @{sys}/
10 Proc files @{PROC}/
11 Dev files /dev/
12 Deny rules deny

Dbus block

Dbus rules must be written in a dedicated block just before the file block. The dbus block must be sorted as follows:

  • The system bus should be sorted before the session bus
  • The bind rules should be sorted after send & receive rules

For DBus, try to determine peer's label when possible. E.g.: 

dbus send bus=session path=/org/freedesktop/DBus
     interface=org.freedesktop.DBus
     member={RequestName,ReleaseName}
     peer=(name=org.freedesktop.DBus, label="@{p_dbus_session}"),

If there is no predictable label it can be omitted.

Profile rules

Variables

Always use the apparmor.d variables. Example:

  • /usr/lib or /usr/bin become @{bin} or @{lib}
  • /usr/sbin or /sbin become @{bin}.

Sort

In a rule block, all rules must be alphabetically sorted.

Sub-profiles

Sub-profiles should come at the end of a profile.

Similar purpose

When some rules share similar purposes, they may be sorted together. E.g.: 
/etc/machine-id r,
/var/lib/dbus/machine-id r,

Limit the use of deny

The use of deny should be limited to the minimum:

  • In MAC policies, we only allow access (Rule )
  • deny rules are enforced even in complain mode,
  • If it works on your machine does not mean it will work on others (Rule ).

Comments

Ensure you only have useful comments. E.g.: 
# Config files for foo
owner @{user_config_dirs}/foo/{,**} r,
Does not help, and if generalized it would add a lot of complexity to any profiles.

Clarity over cleverness

Always prefer clarity to cleverness. E.g., if a rule is more explicit but longer, prefer it over a shorter but less explicit one.