[apparmor] Deny messages for systemd rule

John Johansen john.johansen at canonical.com
Tue Nov 25 08:51:52 UTC 2025


On 11/1/25 09:40, engelflorian at posteo.de wrote:
> Hi all,
> 
> Why do I get this deny rule
> 
> AVC apparmor="DENIED" operation="exec" class="file" info="no new privs" error=-1 profile="/nix/store/ksz6ygnl9f1l6jff3mwmjsmw7qyyxa59-systemd-257.7/**" name="/nix/store/s71mkxsqwlhgjvpdjgnz6wrcah1wfbk3-dhcpcd-10.1.0/sbin/dhcpcd" pid=872 comm="(dhcpcd)" requested_mask="x" denied_mask="x" fsuid=999 ouid=0 target="/nix/store/s71mkxsqwlhgjvpdjgnz6wrcah1wfbk3-dhcpcd-10.1.0/**
> 
> for the profile
> 
> profile /nix/store/ksz6ygnl9f1l6jff3mwmjsmw7qyyxa59-systemd-257.7/** {
>    capability,
>    network,
>    mount,
>    remount,
>    umount,
>    pivot_root,
>    ptrace,
>    signal,
>    dbus,
>    unix,
>    /** rwmklPux,
> }
> 
> Shouldn't x be allowed?

This is denied because no-new privs is being enforced and the transition would result in a policy change that can not be proven at run time to not grant additional privileges.

Unfortunately the nnp api has it applied before the exec instead of at exec which is problematic for LSMs that allow policy transitions at exec.
To deal with this you can use a stacked transition that keeps the original confinement and adds the additional confinement.

   /** Pux -> &@{profile_name},

Currently apparmor doesn't allow overriding the nnp restriction. selinux has add a special capability to allow overriding nnp, and apparmor will have to add a similar capability to allow for certain situations where stacking doesn't work





More information about the AppArmor mailing list