Namespaces in operation, part 1: namespaces overview

Posted Jan 5, 2013 4:51 UTC (Sat) by dw (subscriber, #12017)
Parent article: Namespaces in operation, part 1: namespaces overview

I remember being very excited by the possibilities when reading about namespaces back in 2003 or so, but with the addition of per-container UIDs I can't help feel nothing but a case of extreme heebie-geebies about local security for the coming years.

Considering it wasn't until relatively recently that kernel code would routinely directly compare the UID field to determine root privilege, and given that it's already quite difficult to maintain a mental model of how the UID/PID namespaces work, I suspect strong apprehension is a legitimate response toward any kernel config that has these features enabled at least for the immediate future.

to post comments

Namespaces in operation, part 1: namespaces overview

Posted Jan 5, 2013 6:10 UTC (Sat) by ebiederm (subscriber, #35028) [Link] (3 responses)

Internal to the kernel the mental model is quite simple, you use kuids and kgids. The programming model is nice as simple as it has always been.

Right on the edges of user space kuids and kgids are translated to/from uids and gids, and you must use the translation functions because they are type incompatible.

As for the the kernel directly comparing the uid field to determine root privilege suid() and it's kin was replaced by capable calls internal to the kernel a decade or so ago.

Like any thing new there are reasons to be cautious, but getting the data types wrong is not one of those reasons. Similarly for system administrators there shouldn't really be any more challenge than using fake-root.

But please if you aren't comfortable with user namespaces please disable them in your kernel builds that is what the config option is for.

Namespaces in operation - root privileges

Posted Jan 6, 2013 1:50 UTC (Sun) by giraffedata (guest, #1954) [Link] (2 responses)

I'm bewildered by the mention in the article of user name spaces allowing one to have root privileges. "Root privileges" is a way of saying, "all the capabilities" and has almost nothing to do with uids. So how does this work? Does the uid name space feature really allow a process to hold a capability whose power is somehow limited to a subset of the system?

Described like this, I can certainly see it taking a lot of work to convince people there's nothing to be afraid of in this feature.

Namespaces in operation - root privileges

Posted Jan 8, 2013 8:53 UTC (Tue) by error27 (subscriber, #8346) [Link]

These days there root doesn't have all capabilities because of, for example, se-linux. We're sort of working to a goal where people can't load non-vendor modules or firmware without reconfiguring secure boot in the UEFI firmware. So there are all kinds of things which root will be restricted from doing by default.

One use of new namespace work would be to set up a chroot where people could install mysql and set up a webserver etc. It's cheaper than using KVM for virtualization.

Namespaces in operation - root privileges

Posted Jan 9, 2013 0:57 UTC (Wed) by hallyn (subscriber, #22558) [Link]

> So how does this work? Does the uid name space feature really allow a process to hold a capability whose power is somehow limited to a subset of the system?

Yes. In the past, we simply had the 'capable()' call, which checked whether the current task had, say, CAP_SYS_ADMIN. Now capabilities are targeted toward a particular user namespace, and the function to check for that ns_capable(). Importantly, any existing unconverted capable() call becomes a check targeted at the initial user namespace. Therefore if we haven't specifically said "that capability is ok to be allowed in a non-init userns", then it won't be allowed. Then, resources (say a network interface) belong to a namespace (a network ns, for the network interface), and each network namespace is owned by a user namespace, namely the userns from which the netns was created. So we to check CAP_NET_ADMIN for an action on a nic, we can check for permission to the user namespace which owns the netns which owns the nic.

(If you're asking more generally about the relation of root to capabilities, that has not changed - see the capabilities(7) man page, specifically searching for 'secbit'.)