YGG UNDERSTAND·OPEN·IMPROVE

AppArmor: an introduction to MAC for Linux applications

explainer · linux

AppArmor is a Linux kernel extension for mandatory access control (MAC) that increases computer security by granting each application only the permissions it actually needs.

01

What AppArmor is

AppArmor lets you define permissions for a given operation at the process level, depending on the location of the executable – it places its own control routines at critical points in the kernel. This adds overhead to the system, but it can stop a program from performing a potentially dangerous action that could lead to a security breach, including privilege escalation.

  • it is open source;
  • as a Linux Security Module (LSM) it has been part of the kernel since version 2.6.36 (October 2010);
  • it provides proactive protection of the system and applications – against internal, external, and even zero-day attacks;
  • policies are enforced through profiles, which define what permissions an application has (access to directories, sockets, or the network);
  • the most commonly used profiles ship directly in distribution channels.
02

What it is for and why to use it

  • it adds another layer of security, reduces the risk of system compromise, and dampens the impact of a successful breach;
  • it protects the system from applications gone wild;
  • profiles can be changed at runtime;
  • running an unknown application in “safe mode” reveals what it actually does before restrictions are enforced for real.
03

Where to find AppArmor

AppArmor is part of many distributions – Debian, Gentoo, (open)SUSE, Ubuntu. Profiles aren't limited to RPM packages for (open)SUSE; they can also be found or built on the openSUSE Build Service or on Launchpad.net.

04

Differences between AppArmor and SELinux

  • working with SELinux policies can be harder for some due to greater complexity;
  • AppArmor ships as part of the default install on, for example, (open)SUSE or Ubuntu, while SELinux is the default on RHEL or CentOS;
  • AppArmor works with file paths, SELinux with labels and inodes;
  • AppArmor looks at individual applications, SELinux at the system as a whole.
05

AppArmor components

  • a kernel module;
  • a parser;
  • control utilities.
06

How it works

At boot, AppArmor loads the kernel module and the available profiles from /etc/apparmor.d. Profiles are sorted by the mode they belong to:

  • disabled – the profile is not enforced;
  • complain (learning) – rule violations are only logged;
  • enforce (confined) – rules are actually enforced.

A profile's mode can be read either from its header, for example:

/usr/lib/colord flags=(attach_disconnected,complain)

or from the fact that the profile is symlinked in /etc/apparmor.d/disable.

07

Installation on (open)SUSE

A standard installation automatically includes the AppArmor packages. For a manual installation, the relevant packages are:

libapparmor
apparmor-profiles
apparmor-utils
apparmor-parser
yast2-apparmor
apparmor-docs
08

Checking whether AppArmor is running

systemctl status apparmor.service
aa-status
ps axuwZ | head
09

Control tools

  • aa-status – overview of loaded profiles and their modes;
  • aa-complain – switch a profile to complain mode;
  • aa-enforce – switch a profile to enforce mode;
  • aa-disable – disable a profile;
  • apparmor_parser – load and validate a profile;
  • aa-autodep – generate a baseline profile for an application;
  • aa-logprof – interactively extend a profile based on the log.
10

Logging

Operation logs live in /var/log/audit/audit.log. The default configuration logs DENIED operations. Logging covers both the type (DENIED, ALLOWED, STATUS) and the operation (mkdir, profile_load, profile_remove, profile_replace).

11

Bonus: an AppArmor profile file

Profile naming isn't strictly required to follow a convention, but the common pattern replaces slashes in the binary's path with dots – usr.bin.firefox maps to the profile for /usr/bin/firefox. Example policy file:

/tmp/ls flags=(complain) {
  # executable needs 'r' and mmap PROT_EXEC 'm'
  /tmp/ls rm,
  /lib/ld-2.5.so rmix,
  /etc/ld.so.cache rm,
  /lib/lib*.so* rm,
  /dev/pts/*    w,
  /proc/meminfo r,
  /var/run/nscd/socket w,
  /var/run/nscd/passwd r,
  /var/run/nscd/group  r,
  /tmp/ r,
}
12

Bonus: working with policies

  • switch a profile (process) to complain mode;
  • switch a profile (process) to enforce mode;
  • disable a profile (process) – the application then runs unconfined.
13

Bonus: creating a profile easily

A walkthrough on a simple test script test_bash.sh:

  1. create the script that should be profiled;
  2. run aa-autodep /root/test_bash.sh;
  3. review the generated profile, e.g. vim /etc/apparmor.d/root.test_bash.sh;
  4. run the application with the profile in complain mode;
  5. check the log for anything suspicious and extend the profile if needed;
  6. switch the profile to enforce mode with aa-enforce root.test_bash.sh.
14

What AppArmor doesn't do and its drawbacks

  • it is not 100% protection against all attacks;
  • AppArmor and SELinux (or another alternative) cannot be used at the same time;
  • converting AppArmor profiles to SELinux policies isn't currently possible;
  • there is no polished graphical interface;
  • profile edits happen ex-post, based on the log;
  • creating and administering profiles can be harder at the start.

Based on a talk “AppArmor – what it is, what it's for, and how to use it” (InstallFest 2017), slides, video.

← back to explore