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.
- Write AppArmor profiles to be as constrained as possible.
- Validate the profiles manually before release, and during testing.
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
executable has the apparmor profile
For application development, the only work which needs to be done for AppArmor integration is to write and install a profile for the application.
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
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.
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
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 (
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.
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,