AppArmor is a file-path based access control framework implemented using the Linux Kernels Security Modules. It is used and enabled by default on a number of modern Linux distributions including Ubuntu, SUSE and Debian as of Debian 10 Buster. AppArmor is entirely based on per application policy files and does not require any file system labels or support.
Main differences between AppArmor and SELinux
In practice file system labels are the biggest difference between AppArmor and SELinux. AppArmor is purely based on policy files. A AppArmor policy file which allows access to certain files or file-trees is enough to make a application work as desired. SELinux requires a policy-file and the right file system labels. As an example, if you want both Samba and mpd to have access to your
/storage/public folder with SELinux you need to a) give that older the label
public_content_rw_t:s0 and set policies which allow access to
public_content_rw_t:s0 labelled files and folders for both Samba and mpd.
AppArmor has one clear advantage over SELinux when it comes to non-standard configuration: It is configured using easily understandable text files which can be used directly. SELinux requires somewhat cryptic policy files which have to be compiled into SELinux modules. Writing and deploying a AppArmor is easier.
AppArmor is enabled by default in kernels shipped in Ubuntu, SUSE and Debian as of Debian 10 Buster.
These configuration options are required to get kernel support for AppArmor:
and you should also enable two additional options which will enable AppArmor by default:
It is possible to enable AppArmor using the kernel boot parameters
apparmor=1 security=apparmor instead of enabling it in the kernels configuration.
AppArmor requires a user-space service which is in all distribution we've seen called
apparmor.service. This service is enabled by default on all the distributions using this frame-work. Disabling it and booting a kernel with AppArmor enabled is a bad idea.
aa-enabled will tell you if AppArmor is enabled and functioning.
apparmor_status is useful for viewing the status of AppArmor-enabled applications and their status. It has to be ran as root. It will tell you how many profiles are loaded and how many of those are used by applications. A program can either have AppArmor enabled in enforce mode or complain mode. There is a huge difference: enforce mode is what you want programs to use. This mode will simply deny access to files that are not permitted. complain mode does not actually provide any security. This mode makes AppArmor log ("complain") when applications are doing things they should not; it will not stop unauthorized actions. This is very useful when creating profiles but should not be used in live high-value deployments.
The "profiles" AppArmor uses to restrict applications live in the folder
/etc/apparmor.d/ and they are named according to the executable files paths with dots instead of
/usr/bin/thunderbird's profile is named
Most profiles include one or more use-case specific configuration files called abstractions which live in the folder
/etc/apparmor.d/abstractions/. These are files with specific rules which allow acc
ess to devices or services or libraries. As an example example, the
audio "abstraction" configuration file gives read and write access to
/dev/dsp* and a whole lot of other audio-related devices as well as read accses
/etc/sound/ and many other folders. A application-specific profile for a program using audio can simply
Profiles can be generated using the programs
aa-logprof with AppAromor set to "complain" and log actions. The AppArmor wiki has a page called "Profiling with tools" which explains how to use them to generate profiles. These profiles will not be prefect and may require some hand-editing. They do give a good starting-point.
You can, of course, write entire profiles yourself. The AppArmor wiki has a section on this called "Profiling by hand".
Profiles are deployed with the program
apparmor_parser. It's default action is to load and enable profiles in enforcement mode. A profile can alternatively be loaded in complain-mode using the
-C parameter. Updating a profile requires the option
-r to replace the current version of a profile with a new one. Profiles that are not longer required or desired can be removed with the
-R option. There are quite a few more options the apparmor_parser manual.