apparmor.d: more than 1500 AppArmor profiles for the core of a Linux system

The Android and ChromeOS model applied to Linux

AppArmor.d describes itself as a set of over 1500 AppArmor profiles whose aim is to confine most Linux based applications and processes. The interesting part is not the count but the selection rule, and the README is unusually explicit about where the idea comes from.

The project takes its inspiration from the Android and ChromeOS security model. In those systems a distribution treats the base image as immutable, with a carefully selected set of applications, and everything else is sandboxed. AppArmor.d applies that idea to a general Linux system: it confines the core applications you will always find on a machine, meaning the systemd services, Xwayland, networking, Bluetooth and the desktop environment, and it declares non-core user applications out of scope, on the grounds that those should be sandboxed with a dedicated tool such as minijail, bubblewrap or toolbox instead.

This is explicitly not how AppArmor is normally used on servers. The usual pattern is to confine only the applications that face the internet or the users, and leave the rest alone. AppArmor.d inverts that, which is why it targets desktops as its primary shape even though its goals also list servers.

The upstream project this grew from is Mikhail Morfikov's AppArmor profiles collection on GitLab, and the stated aim of this fork is to extend that work to more Linux distributions and more desktop environments.

What gets confined: root services, desktops and user plumbing

The README breaks the confinement targets into four groups, and the list reads as an inventory of what a modern Linux session is made of.

The first is all root processes, with examples given as the systemd tools, bluetooth, dbus, polkit, NetworkManager, OpenVPN, GDM, rtkit and colord. The second is all desktop environments. The third is all user services, with Pipewire, Gvfsd, dbus, xdg and xwayland named. The fourth is a smaller group of special user applications, described as web browsers and file managers among others.

Two things follow from that structure. The set is deliberately not exhaustive in the fourth group, and the first three groups are the ones that matter for a system whose users run ordinary applications. Confining systemd's own tools and the desktop session infrastructure is close to the ceiling of what policy can achieve for a general-purpose machine, since those are the processes with the widest reach.

One requirement is stated for every profile: it should not break normal usage of the confined software. That is a strong standard, and it is the reason the project maintains a test page and describes its test status as fully tested, with a separate link for the results. A profile that silently breaks a media player or a desktop session is worse than no profile at all.

Distribution and desktop environment coverage

The stated support policy is every distribution that supports AppArmor, and the README then names four with links into the install documentation: Arch Linux, Ubuntu 26.04, Debian 13 and openSUSE Tumbleweed. Each entry points at an anchor in the installation page, which means the project maintains separate packaging instructions per family rather than one generic script.

Desktop environments are covered by the display manager they use: Gnome through GDM, KDE through SDDM, and XFCE through Lightdm, which is marked as work in progress. That distinction matters in practice, because a desktop profile is mostly a profile of the display manager and the session components around it, and those differ substantially between the three environments. An XFCE user reading the README will find the coverage listed but not finished.

The overall goal is stated as targeting both desktops and servers, which is ambitious for a project whose confinement model is drawn from consumer operating systems. The repository also ships packaging material for more than the four named distributions: a debian directory, a PKGBUILD for Arch, a dists directory and a systemd directory. What each of those contains is not described in the README, so the safest reading is that the project builds artefacts for several distributions while documenting install steps for four.

How the profiles are built and packaged

The repository layout explains the shape of the project. The apparmor.d directory holds the policies themselves, share and systemd hold data that ends up on a system, debian and PKGBUILD carry distribution packaging, dists is the equivalent for other families, and tests and docs hold the test suite and the documentation sources.

The tooling around it is a mixture. Go code lives under cmd and pkg, and the module definition is small, which fits a tool that mostly moves files around rather than one that does heavy computation:

module github.com/roddhjav/apparmor.d

go 1.25.0

require (
	github.com/fsnotify/fsnotify v1.10.1
	gopkg.in/ini.v1 v1.67.3
)

Two direct dependencies tell you what the tooling does. fsnotify watches the filesystem, which is what a tool that reacts to configuration changes needs, and the ini library reads configuration files in the Windows-style INI format, which is how the project's own settings are stored. A Justfile provides the task runner, .golangci.yaml configures linting for the Go code, and .gitlab-ci.yml carries the continuous integration definition on the GitLab side of the project.

The documentation has its own toolchain. A requirements.txt with a single entry is the dependency list for the documentation generator, and zensical.toml configures it:

zensical

The project is developed primarily on GitLab, where the CI pipeline, the badges and the upstream and mirror links all point, with this GitHub repository serving as the other home for the same code.

Getting it onto a machine

The README does not contain installation commands, and it does not pretend to. Installation, configuration and usage are each a page on the project website, at apparmor.pujol.io/install, apparmor.pujol.io/configuration and apparmor.pujol.io/usage, and the README sends you there rather than duplicating instructions that would go stale across four distribution families.

That is a reasonable division, but it does mean the choice of how to install is made on the website rather than in the repository, and the README gives you only the entry point. The per-distribution pages it links to are the place to find whether your system installs the profiles as a package, from a repository, or by copying files into the AppArmor configuration directory.

For evaluation, the project offers something unusual: a live demo at play.pujol.io, described as an AppArmor play machine where you can try the advanced usage and the security it provides without installing anything on your own machine. Given the destructive nature of enabling confinement on a working desktop, that is a sensible way to form a first impression, and the same author's talk at Linux Security Summit North America 2025 was specifically about lessons learned while building that machine.

Contributions run through the same website, with a development section covering the process, and there is a Matrix chat room linked from the README for day-to-day discussion.

Where apparmor.d is the wrong tool

The clearest limitation is stated by the project itself. Non-core user applications are out of scope, and the README is direct that they should be sandboxed with a dedicated tool such as minijail, bubblewrap or toolbox. If your goal is to confine a specific application that faces the internet, the conventional AppArmor approach of writing one targeted profile for that application is a better fit than installing fifteen hundred policies that leave your actual target alone.

The second limitation is the maturity warning. The README opens with a notice that the project is still in its early development, and that is worth weighing against the fact that the profile count is in the thousands. A large policy set with an early-stage project is a combination where a single bad profile can take down a session, and the standard of not breaking normal usage is the thing most likely to still be under active refinement.

Coverage is uneven in a third way. XFCE support through Lightdm is listed as work in progress, and the supported distributions are four, with packaging directories for others whose contents the README does not describe. A system on a distribution that is not among the four will find the profiles present in the repository but no documented path to a working install.

Finally, there is a scope mismatch worth naming for server operators. The model is drawn from consumer operating systems, where the base system is fixed and known, and it targets desktops and servers together, but the profiles that matter most, desktops and media pipelines, are desktop concerns. On a headless server the set of core services overlaps with ordinary AppArmor practice, and the parts that would protect an internet-facing application are explicitly delegated to other tools.

Provenance, releases and licence

The project states that it was initially based on Mikhail Morfikov's AppArmor profiles project and therefore carries the same licence, GPL-2.0, with a LICENSE file at the repository root. GPL-2.0 is copyleft, so modified profiles that you distribute remain under the same terms. This is a description of the licence and not legal advice, and the licence question for a profile set that a distribution may repackage is worth raising with your own legal review.

The repository is not archived and the last push was on 2026-10-12. Recent releases are v0.4914.0 on 2026-09-15, v0.4913.0 on 2026-09-08 and v0.4912.0 on 2026-08-30, which shows a roughly weekly cadence. The version numbering carries four components and grows with each release, consistent with a project whose releases track the size of the policy set rather than a conventional semantic version.

The authorship is concentrated but visible. Alexandre Pujol of Linagora maintains the project, presented the largest set of AppArmor profiles at Linux Security Summit North America 2023 and the play machine lessons at the 2025 edition, and spoke at Ubuntu Summit 2023. The project also carries a development chat, a code of conduct and a contribution process, and it invites help directly, which fits a project of this size whose growth depends on people writing profiles for the applications they use.

Editorial conclusion

Adopt apparmor.d if you run a desktop Linux system, or a server built from the same distribution families, and you want the base system confined by policy rather than by convention, with per-distribution install instructions already written. Do not adopt it expecting general application sandboxing, since non-core user applications are explicitly out of scope, and treat it as experimental work rather than a finished policy set. Verify first that your distribution appears in the install documentation, that the desktop environment you use has a completed profile rather than a work in progress, and that the test status page shows the services you rely on as working before you enable them system-wide.

Frequently asked questions

Official sources

1. License: GPL-2.0
2. Project website
3. README
4. Releases
5. roddhjav/apparmor.d on GitHub