It does seem that way. The problem is the design of unprivileged user namespaces, it gives unprivileged applications access to a lot of kernel surface that they usually don't have access to. This has been used to elevate kernel bugs from root exploitable to being exploitable by unprivileged users.
So when used responsibly they can be used to reduce privileges, which we want to allow. But exploit code can leverage them to gain full kernel privileges. Unfortunately its impossible to distinguish between the two cases except to go through and identify the known good users. That leaves us in the situation where we can 1. just ignore the very real problem, that has been used by dozens of exploits 2. Disable unprivileged user namespaces completely 3. Try to selectively enable/disable unprivileged user namespaces. From a security pov allow listing (selective enablement) is the correct approach, because you can never deny list all combinations of exploits. This does unfortunately also mean that enabling unprivileged user namespaces for an application must be a privileged action, other wise an exploit only has to take an extra step to by-pass the restriction. Hence why we won't by default enable a profile for an application in a location that is run from a user writable location. A user doing said enablement local is at much lower risk than a distro doing so. Note that Ubuntu won't be the only ones restriting unprivileged user namespaces. The ability to control them is coming to capabilities and selinux as well. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2056555 Title: Allow bitbake to create user namespace To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2056555/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
