parser fails to unload profile via "aa-disable" on autopkgtest.u.c (armhf) - "Permission denied"

[Sergio Durigan Junior]

This bug affects django-auth-ldap and other packages that call "aa-disable" in a dep8 test. For some reason that I wasn't able to determine, the command fails when it's executed on autopkgtest.ubuntu.com, but only when run on armhf.

The error looks like this:

ERROR: /sbin/apparmor_parser: Unable to remove "/usr/sbin/slapd". Permission denied; attempted to load a profile while confined?

Disabling /usr/sbin/slapd.

https://autopkgtest.ubuntu.com/results/autopkgtest-kinetic/kinetic/armhf/d/django-auth-ldap/20220927_015039_0a1ae@/log.gz

I wasn't able to reproduce the problem. I believe it's something specific to how autopkgtest.u.c launches the armhf containers.

[Christian Boltz (cboltz)]

aa-disable calls apparmor_parser, so this is most likely a problem between apparmor_parser and the kernel. I've updated the summary accordingly.

[John Johansen (jjohansen)]

Is there anymore info for this? Any kernel messages?

From the error itself we can determine
The parser has root/admin privileges as it passed an early check for that without giving an error.
It was able to open the kernel interface to remove the profile.
The likely error here is that it is not policy_admin_capable in the current namespace (ie. container).

AppArmor would log a message to the kernel that the task does not have cap MAC_ADMIN if this is the case.

If this is the case the container will need to be setup to have that capability.

[Andreas Hasenack (ahasenack)]

> Is there anymore info for this? Any kernel messages?

Can't run dmesg in that container :(

I did run aa-status (after altering the dep8 test, rebuilding, retesting, etc), got this:

autopkgtest [20:25:06]: test smbk5pwd: [-----------------------
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
adding new entry "cn=samba,cn=schema,cn=config"

SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
adding new entry "cn=hdb,cn=schema,cn=config"

apparmor_parser: Unable to replace "/usr/sbin/slapd". Permission denied; attempted to load a profile while confined?
Failed to reload the profile, let's get some info and continue
apparmor module is loaded.
You do not have enough privilege to read the profile set.
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "cn=module{0},cn=config"

adding new entry "olcOverlay=smbk5pwd,olcDatabase={1}mdb,cn=config"

autopkgtest [20:25:09]: test smbk5pwd: -----------------------]
autopkgtest [20:25:14]: test smbk5pwd: - - - - - - - - - - results - - - - - - - - - -
smbk5pwd PASS (superficial)

The code for the above was:

        apparmor_parser -r -W -T /etc/apparmor.d/usr.sbin.slapd || {
            echo "Failed to reload the profile, let's get some info and continue"
            aa-status || :
        }

All of this points at a specific restriction in the Canonical infrastructure that runs the armhf DEP8 tests.

[John Johansen (jjohansen)]

so some potential low level interfaces you can try probing for more info.

   /sys/module/apparmor/parameters/enabled

with the aa-status reporting apparmor module is loaded. I expect you have access to this directory. Which means you can also check

  /sys/module/apparmor/parameters/mode

to verify the mode apparmor is in. In addition you still might be able to get access to

  /sys/kernel/security/lsm

which would indicate that securityfs is available in the container. You could then check

  /sys/kernel/security/apparmor/

which would indicate the apparmorfs interface is available in the container. If that is available you can try

  /sys/kernel/security/apparmor/policy/profiles/