User namespaces

Posted Sep 17, 2015 20:55 UTC (Thu) by ebiederm (subscriber, #35028)
In reply to: Quotes of the week by spender
Parent article: Quotes of the week

User namespaces are not a security feature unless your threat model is having a root user in a container. I do not know who has claimed otherwise.

What user namespaces are is a way to get around the ancient unix design bug which is setuid root applications. That design bug resulted in new kernel features being only available to the root user because of legitimate concerns of confusing setuid root applications.

Unfortunately code that is semantically reasonable for a non-root user to use if it was not for setuid-root applications typically has not been looked at closely, and contain bugs in the corner cases that people do not use.

And of course by it's very nature of dealing with security credentials practically any bug is a security issue.

I am human and I have made mistakes. I do not see those mistakes rising to the level of utter recklessness alleged.

For the primary use case of having a root user in a container user namespaces make things better.
If you have no need for new fangled features anything new is always unnecessary.

It is also true I have not found many of the security issues that have been found in the released code. What responsoble person releases code that has issues they know of. Most bugs in released software are in fact found by someone other than the developer.

If anyone has any strong feelings or concerns about the code please feel free to reach out to me. I am a finite human being with finite knowledge, creativity and time in which I endeavour to do the best thay I can. So I am happy to make improvements.

User namespaces

Posted Sep 17, 2015 21:43 UTC (Thu) by mjg59 (subscriber, #23239) [Link] (9 responses)

> For the primary use case of having a root user in a container user namespaces make things better.

Is this true? If a container is running some well-written code as root, there's no security concern - I can't subvert the code running as root to do what I want, so I'm left with whatever unprivileged execution paths I have within that container. With user namespaces all I need is unprivileged code execution in order to become "root", and as we've seen that has opened up various other avenues of attack.

User namespaces

Posted Sep 19, 2015 10:02 UTC (Sat) by ebiederm (subscriber, #35028) [Link] (8 responses)

By root user in a container I mean allowing someone else to run arbitrary code as root in a container.

Droppping a few capability bits and denying access to /proc files does not help much. User namespaces help a bit more.

User namespaces

Posted Sep 19, 2015 16:53 UTC (Sat) by mjg59 (subscriber, #23239) [Link] (7 responses)

Well sure, but in the process they made it easier for arbitrary unprivileged code to become arbitrary privileged code. Assuming that all the issues have been resolved, they're a security win, but that's a moderately large assumption.

User namespaces

Posted Sep 21, 2015 8:08 UTC (Mon) by ortalo (guest, #4654) [Link] (6 responses)

You are trying to adress setuid issues in the general case (or maybe the general problem of one-time delegation of access rights for privileged operations) ?
Under Unix, I thought the consensus was to try to reduce the needed setuid programs to a small and very controlled set. Like an annoying heritage.
It's not a criticism at all by the way. You are offering new features and visibly taking care of their security; that's already a lot.

But well, we should really all sit down around a table (possibly several tables), make a strong skill-oriented and trust-oriented screening check of everyone involved, and force each table to agree upon a modern set of security features for 21st century operating systems.

Maybe every group would come up with differents sets of features (esp. behind governemental closed doors) but at least we could go towards development-oriented people with a consistent security features set and without the permanent impression that the old (security) reference monitors of the 70s were more advanced than current software.

Or maybe I should just write mines somewhere for an (improbable) posterity...

User namespaces

Posted Sep 22, 2015 19:13 UTC (Tue) by walex (guest, #69836) [Link] (5 responses)

Under Unix, I thought the consensus was to try to reduce the needed setuid programs to a small and very controlled set. Like an annoying heritage.

That's the consequence of not understanding the UNIX protection model well. Also it is a consequence of one of the major design flaws in that protection model too, the lack of distinction between effective and real user/group ids for inode ownership, not just for processes. I have written a suitable summary here. That design flaw makes things harder, not impossible, though.

without the permanent impression that the old (security) reference monitors of the 70s were more advanced than current software.

That impression is entirely valid, current state of the art in OS design, and not just security architectures, has greatly regressed, largely thanks to Linux developers (many of whom seem to regard reading a few decades of extensive literature as something only cowards would do) who worship the Microsoft way, towards the early 60s (at best!), where MS-Windows NT mostly resides.

User namespaces

Posted Sep 22, 2015 19:40 UTC (Tue) by pizza (subscriber, #46) [Link] (1 responses)

> That impression is entirely valid, current state of the art in OS design, and not just security architectures, has greatly regressed, largely thanks to Linux developers (many of whom seem to regard reading a few decades of extensive literature as something only cowards would do) who worship the Microsoft way, towards the early 60s (at best!), where MS-Windows NT mostly resides.

[ citation needed ]

User namespaces

Posted Sep 23, 2015 14:27 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

epoll when kqueue already existed?

User namespaces

Posted Sep 22, 2015 20:20 UTC (Tue) by zlynx (guest, #2285) [Link] (1 responses)

Windows NT security is really pretty good. Such a shame that app developers hardly use it.

Your game client needs to download updates? Well, you could create a group and assign permissions to it ... nahhh, go Administrator!

User namespaces

Posted Oct 11, 2015 9:25 UTC (Sun) by Fowl (subscriber, #65667) [Link]

Steam (the very popular software distribution platform, now on Linux!) actually does this. Well not the group part.

Hurrah world writable binaries!

They have a system service as well, but I have no idea what it's used for because updates only occur whilst the client is running and installing a game still prompts for Admin credentials,. Installing software system wide probably /should/ require the permission of an administrator after all...

Hmm this has turned into a bit of a rant.

User namespaces

Posted Sep 22, 2015 20:26 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

> That's the consequence of not understanding the UNIX protection model well. Also it is a consequence of one of the major design flaws in that protection model too, the lack of distinction between effective and real user/group ids for inode ownership, not just for processes.
How can inode ownership make it possible to run utilities like "ping"?

User namespaces

Posted Sep 20, 2015 19:43 UTC (Sun) by pbonzini (subscriber, #60935) [Link]

Let's not forget that relatively few people actually build their own kernel. The distros act as a buffer and should disable features that, according to the target audience, provide more problems than benefits. For example RHEL7 disabled user namespaces.