Can't create nested AppArmor namespaces

[Tyler Hicks]

A user with CAP_MAC_ADMIN in the init namespace can create an AppArmor policy namespace and load a profile belonging to that AppArmor namespace. Once that's done, the user can confine a process with that namespaced AppArmor profile and enter into a user namespace. That process can then load additional AppArmor profiles inside of the AppArmor and user namespace. Here's an example:

We need to set up the namespace, n1, and load the profile, p1.
$ export rules="file, signal, unix, dbus, ptrace, mount, pivot_root, capability,"
$ sudo mkdir /sys/kernel/security/apparmor/policy/namespaces/n1
$ echo "profile p1 { $rules }" | sudo apparmor_parser -qrn n1

Now we enter into confinement using the AppArmor namespace and profile and then enter into an unprivileged user namespace
$ aa-exec -n n1 -p p1 -- unshare -Ur

We can now load profiles as the privileged user inside of the unprivileged user namespace
# echo "profile test {}" | apparmor_parser -qr

The reason for this bug report is that we cannot create a nested AppArmor policy namespace inside of the unprivileged user namespace

# mkdir /sys/kernel/security/apparmor/policy/namespaces/n1/namespaces/p1
mkdir: cannot create directory ‘/sys/kernel/security/apparmor/policy/namespaces/n1/namespaces/p1’: Permission denied

If that worked, we could adjust LXD to read /sys/kernel/security/apparmor/.ns_name to get the current AppArmor namespace, then create a new namespace under the current namespace, and leverage the nested namespace for its nested containers.

[Brad Figg (brad-figg)]

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1652101

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Tyler Hicks (tyhicks)]

This is a feature bug that the security team is using for tracking. Moving the bug status back to confirmed.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[brian mullan (bmullan)]

From what I understand, LXD is moving toward SNAP LXD as a default, so not being able to run SNAP in an LXD container configured for "nesting":

re -

lxc config set <container> security.nesting true

Is basically going to prevent LXD from being used for Nested Containers.

[brian mullan (bmullan)]

how does this get assigned to someone so it might get fixed?

[John Johansen (jjohansen)]

It is fixed to the degree it can be fixed until upstream agrees on changes in the LSM layer.

The apparmor devs certainly can do the work of proposing new hooks, etc that are necessary but it hasn't been the highest priority item. I will note that this is a high priority item, just that others have been ranked higher.

There is hope that someone can return to this soon.