snap does not allow docker run --security-opt=no-new-privileges:true

[samc014111]

If docker is installed via snap then running
$ docker run -it --security-opt=no-new-privileges:true <IMAGE> sh
where <IMAGE> is an image fails with the following error:
standard_init_linux.go:211: exec user process caused "operation not permitted"

This error does not occur if docker is installed via apt.

In the logs i see
$ dmesg | grep audit
[28071.584927] audit: type=1400 audit(1608149352.653:224): apparmor="DENIED" operation="exec" info="no new privs" error=-1 profile="snap.docker.dockerd" name="/usr/bin/sh" pid=128356 comm="runc:[2:INIT]" requested_mask="x" denied_mask="x" fsuid=0 ouid=0 target="docker-default"

[Ian Johnson (anonymouse67)]

Unfortunately I believe that this is an inherent constraint we have with AppArmor, where during the process of dockerd executing the container, AppArmor doesn't allow you to set no-new-privileges (or NNP) for the new process because it's difficult for AppArmor to know specifically which sets of privilege transitions should be allowed with the specific policy that is in place at any given time for the dockerd service, and thus AppArmor just entirely denies NNP transitions (or something like this).

I've asked someone from our security team who is more knowledgeable about AppArmor to comment and perhaps provide a more refined explanation of the issue. AFAIK this is not something that we can support for snaps until AppArmor itself supports it.

[John Johansen (jjohansen)]

@anonymouse67 is correct this is an external constraint placed on AppArmor. However its not because AppArmor doesn't have the information needed to make the change.

When seccomp and NO_NEW_PRIVS where added to the kernel Linus declared that it would apply to LSM policy as well as seccomp. The LSMs were told to not allow policy changes once NO_NEW_PRIVS was set. Back in the day this wasn't such a problem but with everyone trying to use seccomp and set NO_NEW_PRIVS this has become a huge issue.

AppArmor has gradually loosed the restrictions on it policy transitions. Eg. Unconfined with NNP set is allowed to gain confinement. Tasks are allowed to add new elements to a stack, and now it allows changing part of a confinement stack as long as the confinement that was present at the time NNP was invoked doesn't change (this last one allows system containers to load a switch policy within their namespace while the host confinement is fixed). With all of these loosening the rule has been the same that confinement must provably be the same or a superset of what policy was when NNP was invoked.

Sadly all these changes are not sufficient, and there are cases where we just can't make policy and NNP work together correctly. This hasn't just been a problem for AppArmor it affects the other LSMs as well. SeLinux has been allowed to add override rules that allow them to specify NNP overrides for policy in certain places, and with SeLinux being allowed to do that AppArmor is going to try and upstream similar changes, where policy will be able to specify special overrides for NNP. Unfortunately the earliest this will land (assuming it is not naked) will be in 5.12 kernels with userspace support in 3.1 (or possibly 3.2).

There are things that can be done to help AppArmor work with NNP, but that requires applications to take an active role in AppArmor policy management. Eg. Transitioning policy to its final profile before invoking NNP instead of relying on exec. Setting up policy namespaces, and having the exec transitions occur in the policy namespace, while the host profile remains locked etc. But these solutions only work for some cases. And somethings just won't be possible until the full solution lands.