AppArmor

From ArchWiki
Jump to: navigation, search

AppArmor is a Mandatory Access Control (MAC) system, implemented upon the Linux Security Modules (LSM).

Installation

Kernel

When compiling the kernel, it needs the following options:

 CONFIG_SECURITY_APPARMOR=y
 CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE=1
 CONFIG_DEFAULT_SECURITY_APPARMOR=y
 CONFIG_AUDIT=y

Instead of setting CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE and CONFIG_DEFAULT_SECURITY_APPARMOR, you can also set kernel boot parameters: apparmor=1 security=apparmor.

There also is a stock kernel with AppArmor: linux-apparmorAUR[broken link: archived in aur-mirror]. However, as of May 2015, the kernel is outdated.

Userspace Tools

The userspace tools and libraries to control AppArmor are supplied by the apparmorAUR package.

The package is a split package which consists of following sub-packages:

  • apparmor (meta package)
  • apparmor-libapparmor
  • apparmor-utils
  • apparmor-parser
  • apparmor-profiles
  • apparmor-pam
  • apparmor-vim

To load all AppArmor profiles on startup, the apparmorAUR package includes a systemd unit:

# systemctl enable apparmor

Testing

After reboot you can test if AppArmor is really enabled using this command as root:

 # cat /sys/module/apparmor/parameters/enabled 
 Y

(Y=enabled, N=disabled, no such file = module not in kernel)

Note: Since AppArmor builds and installs a kernel module it must be rebuilt against the current kernel on each update

Disabling

To disable AppArmor temporarily, you can add apparmor=0 security="" to the kernel boot parameters.

Alternatively run

# systemctl stop apparmor.service

to disable it for the current session.

Creating new profiles

To create new profiles using aa-genprof, auditd.service from the package audit must be running. This is because Arch Linux adopted systemd and doesn't do kernel logging to file by default. Apparmor can grab kernel audit logs from the userspace auditd daemon, allowing you to build a profile. To get kernel audit logs, you'll need to have create rules. See this section: Audit framework#Adding rules.

Be sure to stop the service afterwards (and maybe clear /var/log/audit/audit.log) because it causes overhead.

Security considerations

Preventing circumvention of path-based MAC via links

AppArmor can be circumvented via hardlinks in the standard POSIX security model. However, the kernel included the ability to prevent this vulnerability via the following settings:

/usr/lib/sysctl.d/50-default.conf
...
fs.protected_hardlinks = 1
fs.protected_symlinks = 1

Patches distributions like Ubuntu have applied to their kernels as workarounds as not needed anymore.

Tips and tricks

Get desktop notification on DENIED actions

To get a notification on your desktop whenever AppArmor enters a "DENIED" log entry start the notify daemon by

# aa-notify -p --display $DISPLAY

This daemon must be started at each boot.

More Info

AppArmor, like most other LSMs, supplements rather than replaces the default Discretionary access control. As such it's 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 it's variants) use SELinux which requires good userspace integration to work properly. People tend to agree that it is also much much harder to configure correctly.

Taking a common example - A new Flash vulnerability: If you were to browse to a malicious website AppArmor can prevent the exploited plugin from accessing anything that may contain private information. In almost all browsers, plugins run out of process which makes isolating them much easier.

AppArmor profiles (usually) get stored in easy to read text files in /etc/apparmor.d

Every breach of policy triggers a message in the system log, and many distributions also integrate it into DBUS so that you get real-time violation warnings popping up on your desktop.

Links

See also