Skip to content

Add AppArmor Support - #53

Open
simonwalz-work wants to merge 8 commits into
developmentfrom
feat-apparmor
Open

Add AppArmor Support#53
simonwalz-work wants to merge 8 commits into
developmentfrom
feat-apparmor

Conversation

@simonwalz-work

Copy link
Copy Markdown
Contributor

Add AppArmor support for OS and basic docker containers

@simonwalz
simonwalz force-pushed the feat-apparmor branch 2 times, most recently from ad47167 to c0b4d69 Compare September 9, 2026 22:03
Signed-off-by: Simon Walz <contact@simonwalz.de>
Profiles are loaded into the host's kernel, and a container cannot load
its own - that needs AppArmor namespaces and a writable
/sys/kernel/security/apparmor. On the LXC platform apparmor.service
would only fail, and what confines the guest is the host's business.

Not built yet.

Signed-off-by: Simon Walz <contact@simonwalz.de>
A valueless boolean module parameter most likely parses as true, but
apparmor=1 is the documented form and leaves nothing to read twice.

No security=apparmor alongside it: Debian's kernel already carries
apparmor in CONFIG_LSM, and security= would override that whole list and
drop landlock and yama with it.

The installer ISO keeps apparmor=0 and now says why - it is a separate
image without the apparmor package, so there is nothing to load there.

Not built yet.

Signed-off-by: Simon Walz <contact@simonwalz.de>
Every other unit in these images is enabled or disabled by hand rather
than left to the maintainer scripts; apparmor.service now is too.

The one profile Debian gives us for free is also the one that breaks
here. isc-dhcp-client ships /etc/apparmor.d/usr.sbin.dhclient, which
allows

  /var/lib/dhcp{,3}/dhclient* lrw,

but /var/lib/dhcp is a symlink to /data/dhcp, and AppArmor mediates the
resolved path. The write lands on /data/dhcp/dhclient.leases, no rule
covers it, and dhclient loses its lease. The rule goes into the profile's
local/ include, which is what it is for and survives a package upgrade.

Not built yet - neither the unit state nor the denial is verified on a
running system.

Signed-off-by: Simon Walz <contact@simonwalz.de>
It came with the initial import (4188543) and nothing ever enabled
SELinux: no selinux= on any kernel command line, no policy loaded. With
AppArmor now the LSM, two half-installed stacks are worse than one
chosen.

The installer factory still installs it; that image is untouched here.

Not built yet.

Signed-off-by: Simon Walz <contact@simonwalz.de>
docker-default is what AppArmor is here for - it is the only thing
confining the application container, and dockerd loads it silently or not
at all. The check fails on an LSM that is off, on a missing
docker-default, and on one loaded in complain mode, where it would look
present and confine nothing. Skipped in a container, like subvolumes and
network.

Tests: 43 pass, shellcheck clean. Never run on a booted system.
Signed-off-by: Simon Walz <contact@simonwalz.de>
Three profiles are loaded and only one of them matters. The page says so,
names the four places that stay unconfined and why - the privileged
updater above all - and records the /data trap: apparmor mediates the
resolved path, so a stock profile written against /var/lib/... denies the
write that lands in /data.

Signed-off-by: Simon Walz <contact@simonwalz.de>
Same dead weight as in the system images (f0a1b0c): nothing enabled
SELinux, and the installer has even less reason to carry a policy than
the system does. The #-selinux-policy-default marker in Dockerfile.lxc
goes with it - it pointed at a line that no longer exists.

Not built yet.

Signed-off-by: Simon Walz <contact@simonwalz.de>
@simonwalz
simonwalz force-pushed the feat-apparmor branch 2 times, most recently from 6282a63 to d163a5a Compare September 9, 2026 22:24
@simonwalz
simonwalz changed the base branch from main to development September 13, 2026 23:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants