Incorrect denial on umount with bind-mounted mount namespace

[Zygmunt Krynicki]

While developing snap-confine I found that unmount2("/path/to/namespace", 0) gives an incorrect denial with path / instead of /path/to/namespace when the given path describes a bind-mounted mount namespace.

An example denial (from the test program):

lis 30 16:45:27 fyke kernel: audit: type=1400 audit(1512056727.043:1162): apparmor="DENIED" operation="umount" profile="/usr/local/bin/trigger-bug" name="/" pid=23415 comm="trigger-bug"

The test program will be attached shortly.

[John Johansen (jjohansen)]

So yes and no. This is working exactly as the kernel presents this to apparmor, and there is nothing we can do about it at the moment.

specifically all nsfs paths are magic symlinks that resolve to a special kernel mount that does not exist in userspace and all of them resolve to '/'. There is currently nothing that can be done about this.

We have been working on some potential solutions but this is active investigation/dev work and not ready for use.

[John Johansen (jjohansen)]

To further explain, apparmor must do path construction post symlink resolution to avoid certain symlink based attacks. So apparmor is trying to resolve the /proc/<pid>/ns/ path post symlink resolution.

Stepping into /proc/<pid>/ns/ means traversing the magic symlink. Resulting in the weird behavior you see.