AppArmor
AppArmor is a Mandatory Access Control (MAC) system, implemented upon the Linux Security Modules (LSM).
AppArmor, like most other LSMs, supplements rather than replaces the default Discretionary Access Control (DAC). As such it is impossible to grant a process more privileges than it had in the first place.
Ubuntu, SUSE and a number of other distributions use it by default. RHEL (and its variants) use SELinux which requires good userspace integration to work properly. SELinux attaches labels to all files, processes and objects and is therefore very flexible. However configuring SELinux is considered to be very complicated and requires a supported filesystem. AppArmor on the other hand works using file paths and its configuration can be easily adapted.
AppArmor proactively protects the operating system and applications from external or internal threats and even zero-day attacks by enforcing a specific rule set on a per application basis. Security policies completely define what system resources individual applications can access, and with what privileges. Access is denied by default if no profile says otherwise. A few default policies are included with AppArmor and using a combination of advanced static analysis and learning-based tools, AppArmor policies for even very complex applications can be deployed successfully in a matter of hours.
Every breach of policy triggers a message in the system log, and AppArmor can be configured to notify users with real-time violation warnings popping up on the desktop.
Installation
AppArmor is available in all officially supported kernels.
Install apparmor for userspace tools and libraries to control AppArmor. To load all AppArmor profiles on startup, enable apparmor.service
.
To enable AppArmor as default security model on every boot, set the following kernel parameter:
lsm=landlock,lockdown,yama,integrity,apparmor,bpf
lsm=
kernel parameter sets the initialization order of Linux security modules. The kernel's configured lsm=
value can be found with zgrep CONFIG_LSM= /proc/config.gz
and the current value with cat /sys/kernel/security/lsm
.
- Make sure that
apparmor
is the first "major" module in the list.[1] Examples of valid values and their order can be found in security/Kconfig. capability
should be omitted fromlsm=
as it will always get included automatically.
Custom kernel
When compiling the kernel, it is required to set at least the following options:
CONFIG_SECURITY_APPARMOR=y CONFIG_AUDIT=y
To enable the AppArmor Linux security model by default and omit the need to set kernel parameters, additionally set the CONFIG_LSM
option and specify apparmor
as the first "major" module in the list:
CONFIG_LSM="landlock,lockdown,yama,integrity,apparmor,bpf"
Usage
Display current status
To test if AppArmor has been correctly enabled:
$ aa-enabled
Yes
To display the current loaded status use aa-status(8):
# aa-status
apparmor module is loaded. 44 profiles are loaded. 44 profiles are in enforce mode. ... 0 profiles are in complain mode. 0 processes have profiles defined. 0 processes are in enforce mode. 0 processes are in complain mode. 0 processes are unconfined but have a profile defined.
Parsing profiles
To load (enforce or complain), unload, reload, cache and stat profiles use apparmor_parser
. The default action (-a
) is to load a new profile in enforce mode, loading it in complain mode is possible using the -C
switch, in order to overwrite an existing profile use the -r
option and to remove a profile use -R
. Each action may also apply to multiple profiles. Refer to apparmor_parser(8) man page for more information.
Disabling loading
Disable AppArmor by unloading all profiles for the current session:
# aa-teardown
To prevent AppArmor profiles from loading at the next boot disable apparmor.service
. To prevent the kernel from loading AppArmor, remove the lsm=
kernel parameter that was added when setting up AppArmor.
Configuration
Auditing and generating profiles
To create new profiles the Audit framework should be running. This is because Arch Linux adopted systemd and does not do kernel logging to file by default. AppArmor can grab kernel audit logs from the userspace auditd daemon, allowing you to build a profile.
New AppArmor profiles can be created by utilizing aa-genprof(8) or aa-autodep(8). The profile is first created in complain mode: in this mode policy violations are only reported but not enforced. The rules are interactively created by the aa-logprof(8) tool available in apparmor package. Finally the profile should be set into enforce mode with aa-enforce(8). In this mode the policy defined by the rules in the respecting profile are enforced. If necessary, additional rules can be added by repeatedly executing aa-logprof(8), or the profile can be set back to complain mode with aa-complain(8). Detailed guide about using those tools is available at AppArmor wiki - Profiling with tools.
Note that aa-logprof(8) also offers deny rules which are actually not strictly necessary as according to the basic AppArmor logic everything is forbidden which is not explicitly allowed by a rule. However, deny rules serve two purposes:
- deny rules take precedence over allow rules. They are often used in many abstractions located in
/etc/apparmor.d/abstractions
in order to block any access to important folders/files. This makes sure that inadvertently created allow rules do not make a profile too permissive. - deny rules silence logging and make subsequent runs of aa-logprof less noisy. It is important to keep in mind that deny rules are enforced also in complain mode - hence, if an application does not work properly even in complain mode it should be checked if a deny rule in the profile or in one of the included abstractions is the culprit.
Alternatively profiles may be also created manually, see guide available at AppArmor wiki - Profiling by hand.
In addition to the default profiles in /etc/apparmor.d/
, there are more predefined profiles in /usr/share/apparmor/extra-profiles/
. Note that those are not necessarily deemed production-ready, so manual intervention or usage of aa-logprof(8) may be required.
Another set of AppArmor profiles can be found in the apparmor.d project, however, as of writing, the project is not currently stable.
Understanding profiles
Profiles are human readable text files residing under /etc/apparmor.d/
describing how binaries should be treated when executed. A basic profile looks similar to this:
/etc/apparmor.d/usr.bin.test
#include <tunables/global> profile test /usr/lib/test/test_binary { #include <abstractions/base> # Main libraries and plugins /usr/share/TEST/** r, /usr/lib/TEST/** rm, # Configuration files and logs @{HOME}/.config/ r, @{HOME}/.config/TEST/** rw, }
Strings preceded by a @
symbol are variables defined by abstractions (/etc/apparmor.d/abstractions/
), tunables (/etc/apparmor.d/tunables/
) or by the profile itself. #include
includes other profile-files directly. Paths followed by a set of characters are access permissions. Pattern matching is done using AppArmor's globbing syntax.
Most common use cases are covered by the following statements:
r
— read: read dataw
— write: create, delete, write to a file and extend itm
— memory map executable: memory map a file executablex
— execute: execute file; needs to be preceded by a qualifier
Remember that those permission do not allow binaries to exceed the permission dictated by the Discretionary Access Control (DAC).
This is merely a short overview, for a more detailed guide be sure to have a look at the apparmor.d(5) man page and documentation.
Tips and tricks
Get desktop notification on DENIED actions
The notification daemon displays desktop notifications whenever AppArmor denies a program access. To automatically start aa-notify daemon on login follow below steps:
Install the Audit framework and enable and start the userspace Linux Audit daemon. Allow your desktop user to read audit logs in /var/log/audit
by adding it to audit
user group:
# groupadd -r audit # gpasswd -a user audit
Add audit
group to auditd.conf
:
/etc/audit/auditd.conf
log_group = audit
wheel
or adm
.Install python-notify2 and python-psutil.
Create a desktop launcher with the below content:
~/.config/autostart/apparmor-notify.desktop
[Desktop Entry] Type=Application Name=AppArmor Notify Comment=Receive on screen notifications of AppArmor denials TryExec=aa-notify Exec=aa-notify -p -s 1 -w 60 -f /var/log/audit/audit.log StartupNotify=false NoDisplay=true
Reboot and check if the aa-notify
process is running:
$ pgrep -ax aa-notify
For more information, see aa-notify(8).
Speed-up AppArmor start by caching profiles
Since AppArmor has to translate the configured profiles into a binary format it may significantly increase the boot time. You can check current AppArmor startup time with:
$ systemd-analyze blame | grep apparmor
To enable caching AppArmor profiles, uncomment:
/etc/apparmor/parser.conf
## Turn creating/updating of the cache on by default write-cache
To change default cache location add:
/etc/apparmor/parser.conf
cache-loc=/path/to/location
/var/cache/apparmor/
, previously it was /etc/apparmor.d/cache.d/
.Reboot and check AppArmor startup time again to see improvement:
$ systemd-analyze blame | grep apparmor
Troubleshooting
Failing to start Samba SMB/CIFS server
See Samba#Permission issues on AppArmor.
No events caught by aa-logprof
Audit framework logs may have the special character 0x1d
[2]. There is a AppArmor bug report, but a workaround is to run:
# aa-logprof -f <(sed 's/\x1d.*//' < /var/log/audit/audit.log)
See also
- Wikipedia:AppArmor
- AppArmor wiki
- AppArmor Core Policy Reference — Detailed description of available options in a profile
- Ubuntu Tutorial — General overview of available utilities and profile creation
- Ubuntu Wiki — Basic command overview
- AppArmor Versions — Version overview and links to the respective release notes
- Kernel Interfaces — Low level interfaces to the AppArmor kernel module
- wikipedia:Linux Security Modules — Linux kernel module on which basis AppArmor is build upon
- AppArmor in openSUSE Security Guide