AppArmor is a security layer which enforces access control on the filesystem resources applications can access, and the permissions they can access them with. It comprises a kernel module and user space profiles for each application, which define the resources an application expects to access. For more information, see the AppArmor home page. Apertis uses AppArmor for all applications and services.

Summary

Apparmor Profiles

Apparmor profiles are stored in /etc/apparmor.d and are named after the full path of the executable they confine, with / replaced by ..

For example, the gpsd executable can be found at /usr/sbin/gpsd. This executable has the apparmor profile /etc/apparmor.d/usr.sbin.gpsd.

Generating Profiles

For application development, the only work which needs to be done for AppArmor integration is to write and install a profile for the application.

Development Environment

The OSTree images do not offer a very friendly environment for development, it is best to perform such development using the apt based images. To use the tools mentioned below, the apparmor-utils package will need to be installed:

sudo apt install apparmor-utils

Creating Profiles

If starting from scratch, you can use aa-genprof to create a basic profile. This will then need to be worked to describe the functionality needed by the executable. Profiles should be as constrained as possible, following the principle of least privilege. See the AppArmor website for information on writing profiles.

The profiles can be loaded with the following command:

sudo apparmor_parser -r < /etc/apparmor.d/my.new.profile

Typically this is performed with the profile in complain rather than enforce mode. The status of the profiles can be determined by running sudo aa-status.

Validation

AppArmor profiles can be validated in two ways: at runtime and manually.

Runtime verification is automatic: AppArmor will deny access to files which violate the profile, emitting a message in the audit logs (audit.log), for example:

Feb 23 18:54:07 my-host kernel: [   24.610703] type=1400 audit(1393181647.872:15): apparmor="DENIED" operation="open" parent=1 profile="/usr/sbin/ntpd" name="/etc/ldap/ldap.conf" pid=1526 comm="ntpd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0

These can be found with the following commands:

sudo grep DENIED /var/log/audit/audit.log
sudo journalctl -b | grep DENIED

Such messages should be investigated, and may result in changes to the application (to prevent it making such accesses) or to the profile (to allow them). The AppArmor documentation covers the syntax in more detail.

Manual verification should be performed before each release, manually inspecting the profile against the list of changes made to the application since the last release, and checking that each entry is still relevant and correct, and that no new entries are needed.

Manual and runtime verification are complementary: manual verification ensures the profile is as small as possible; runtime verification ensures the profile is as big as it needs to be.

Installing Profiles

Once the profile is working as required add it to the relevant package (typically in the debian/apparmor.d directory) and submit it for review,

External links