Comment 115 for bug 2046844

@jorge-lavila,

Its not a theoretical case, they have been used by multiple exploits every year (including this one) since landing in the kernel. Ubuntu is not the only ones looking at restricting them. SELinux has also picked up the ability but they haven't really rolled it out in policy, there are also discussions in other security forms (eg. the OSS security list) about how to disable them better than the giant sysctl that turns them off for everything.

The apparmor solution allows doing it on a per application basis. Yes it deliberately requires a privileged operation, otherwise the restriction could be trivially by-passed by exploit code. We know the experience is not user friendly atm, and are working on improving it. Improving both the flexibility on what is mediated on how the user can by-pass/disable the restriction. On the GUI side the end goal is something similar to what you get on MacOS where the user gets notified, and has to go to the security center to enable running an untrusted application.

There is in fact a profile coming for bwrap, and unshare, but not the unconfined profile that is being generically used to disable the restriction. The profile will restrict certain modes of operation, and prevent applications launch by it from having privilege within the user namespace. It will open the ubuntu shipped versions up for regular users again for many of its use cases.

Unfortunately untrusted code, which is the case of code downloaded into the home dir, will require a privileged operation to be able to use user namespaces. That could be the use of sudo when using the application, or creating a profile for the application, which then allows the user to subsequently use the application without a privileged operation.