On 13/08/14 01:40 PM, Damjan Georgievski wrote: >>> anyway. is there a reason this is not enabled now? >>> all the mainstream distros hae it enabled now Fedora, RHEL/CentOS 7, >>> Ubuntu and Debian (at least on the backported kernel) >> >> I'd think about it, if the feature wasn't entirely useless. Despite the >> lack of official documentation, I found a document that described how it >> worked. After reading that document I concluded that the feature is a >> huge potential security risk with no actual benefit. > > What security risk exactly? There was one that I know of, and it was fixed. A dozen local root exploits based on unprivileged user namespaces have been disclosed. Fedora and grsecurity patch in a check to prevent unprivileged use of user namespaces. You can find many with a search like 'CVE user namespace linux'. The latest vulnerability is only a day old... >> If you give me a valid use case for USER_NS, I might reconsider, but >> every use case I can imagine is crushed by the limitations of the >> implementation. > > The use case is that you don't need root access to start a container. > I can run Firefox with a limited view to the filesystem for example, > as a normal user. > Or limited view to the network, for ex. just ipv4, just ipv6, just vpn. It's not possible to sandbox an X11 application externally, so Firefox isn't a good example. The ability to see the contents of every window, draw arbitrary stuff in the windows, capture every input event without focus, etc. completely breaks it. The AppArmor profiles in distributions like Ubuntu for graphical applications are security theater. There's a reason for the Chromium renderer sandbox proxying all rendering requests over a pipe. Even an OpenGL context is too much before dri3, and it's only *theoretically* possible for dri3 drivers to be secure in that context.
Attachment:
signature.asc
Description: OpenPGP digital signature
