LWN: Comments on "Namespaces in operation, part 1: namespaces overview"

Namespaces in operation, part 1: namespaces overview

mkerrisk — Wed, 09 Jan 2013 01:44:26 +0000

Therefore, if I unshare a new pidns (and don't mount a new proc), I can look under the old /proc and see information on the tasks my the parent pidns. Or for that matter mount -t proc proc /mnt, and see the old proc under /proc and new proc under /mnt. (Note that one thing we don't (yet) have is an easy way to determine which tasks are the same.)

Oops, yes of course! I knew this, but somehow forgot as I wrote that piece. Thanks for the correction, Serge. I've added a small strikethrough in the article.

Namespaces in operation, part 1: namespaces overview

hallyn — Wed, 09 Jan 2013 01:17:04 +0000

Hi Michael, thanks for the great writeup. Wanted to point out one thing. I'm sure this will be expanded upon in a later article, but

> A process can see (e.g., view via /proc/PID and send signals with kill()) only processes contained in its own PID namespace and the namespaces nested below that PID namespace.

That's true in the process' own (newly mounted) procfs. But the contents of a procfs mount are determined by the superblock, which is determined by the pidns in which it was mounted. The contents of a procfs mount are not determined by the pidns of the reader.

Therefore, if I unshare a new pidns (and don't mount a new proc), I can look under the old /proc and see information on the tasks my the parent pidns. Or for that matter mount -t proc proc /mnt, and see the old proc under /proc and new proc under /mnt. (Note that one thing we don't (yet) have is an easy way to determine which tasks are the same.)

Namespaces in operation - root privileges

hallyn — Wed, 09 Jan 2013 00:57:25 +0000

> 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'.)

Namespaces in operation, part 1: namespaces overview

BenHutchings — Tue, 08 Jan 2013 21:06:11 +0000

Running a suid-root program still gives you all capabilities (normally). And this is still true inside a user namespace, although the capabilities are restricted to that namespace.

Namespaces in operation, part 1: namespaces overview

robbiew — Tue, 08 Jan 2013 19:36:58 +0000

Great LWN article and fantastic work Eric...happy we could help you with this effort.

Namespaces in operation - root privileges

error27 — Tue, 08 Jan 2013 08:53:36 +0000

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

giraffedata — Sun, 06 Jan 2013 01:50:59 +0000

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, part 1: namespaces overview

lab — Sat, 05 Jan 2013 10:42:16 +0000

Excellent overview, thanks. I now feel I actually have a bit of a handle on this, enough to follow the coming episodes, which I look greatly forward to.

Namespaces in operation, part 1: namespaces overview

ebiederm — Sat, 05 Jan 2013 06:39:02 +0000

I though you were asking about how the controls interact with the namespaces at the implementation level of objects, and at that level they are orgothogonal.

As for taking a slice of a control group hierarchy and making it visible in a container the best practical solution I have heard is to do a "mount --bind" of a slice of that hierarchy into a container. Something better was promised at the time control groups were merged but that has never appeared.

The design mistake of embedding a view of the system packed with global identifiers and silly unwarranted assumptions into a filesystem seems to be an easy mistake to make and is very annoying to deal with.

From what little time I have had to look at the control group interface to user space, and the control group model of controlling resources, and the direction all of that is evolving I really don't like the result. Still today control groups are the best solution we have in linux today to the recursive resource limiting problem.

I encourage people who care to help by looking at control groups, reporting bugs and usability problems, and even better writing and submitting patches.

Namespaces in operation, part 1: namespaces overview

ebiederm — Sat, 05 Jan 2013 06:10:23 +0000

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, part 1: namespaces overview

dw — Sat, 05 Jan 2013 04:51:04 +0000

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.

Namespaces in operation, part 1: namespaces overview

Cyberax — Fri, 04 Jan 2013 22:58:25 +0000

So how do they interact? Can I export a limited view of cgroups to a container?

Namespaces in operation, part 1: namespaces overview

ebiederm — Fri, 04 Jan 2013 20:56:53 +0000

Each network namespace is a logically a separate networking stack, with separate addresses, separate firewall rules, separate qos policies etc.

Network devices and sockets belong to a particular network namespace and everything else figures out which network namespace you are talking about from the socket or network device.

Namespaces in operation, part 1: namespaces overview

ebiederm — Fri, 04 Jan 2013 20:47:03 +0000

namespaces and cgroups are orthogonal by design.

Namespaces in operation, part 1: namespaces overview

luto — Fri, 04 Jan 2013 18:56:00 +0000

Doing this for a firewall would get messy -- a firewall thinks about packets, not endpoints.

If the kernel had programmable policy for what tasks could listen, accept, and connect on which sockets to which endpoints, on the other hand, firewalls could (on non-routers, anyway) go away and everything would get simpler and faster.

And no, selinux doesn't count in my book. Try actually programming the policy.

Namespaces in operation, part 1: namespaces overview

dskoll — Fri, 04 Jan 2013 15:16:28 +0000

I believe you can have separate iptables rules in each namespace. I'm running an LXC container and it has it's own view of iptables separate from the host system.

Namespaces in operation, part 1: namespaces overview

dwmw2 — Fri, 04 Jan 2013 14:26:18 +0000

Network namespaces are sometimes useful for VPNs too. Instead of playing with 'split tunnelling' and having DNS tricks to look up certain domains on the VPN and others normally, you can put the VPN connection entirely into a namespace of its own. A trivial way of doing this (for which a vpnc-script already exists for use with vpnc and openconnect) is to make the namespace, put the vpn interface in it, run a new instance of sshd in that namespace and then connect to it with 'ssh -D 1080' to open a SOCKS proxy. Then you have full access to the VPN via SOCKS.

W.r.t. user namespaces, it should be pointed out that uid 0 doesn't necessarily mean that you have "full root privileges". Those were separated out by capabilities long ago...

Namespaces in operation, part 1: namespaces overview

Fats — Fri, 04 Jan 2013 11:53:44 +0000

What is not clear to me is if the network namespaces also abstracts the firewall; e.g. is it possible to have separate firewall rules in each of the network namespaces or is OpenVZ still needed for that ?

Thanks

ncm — Fri, 04 Jan 2013 09:21:20 +0000

Articles like this keep me renewing my LWN subscription.

Namespaces in operation, part 1: namespaces overview

Cyberax — Fri, 04 Jan 2013 04:10:37 +0000

How do they interact with cgroups? Is it possible to have, for example, a child container with its own memory control cgroup?