LWN: Comments on "User namespaces progress"

User namespaces progress

kevinm — 2013-01-04T02:00:22+00:00

Thanks Eric.

So from this it sounds like all the other types of namespaces (net, pid, mount...) are "owned" by a user namespace (the one in which they were created). When a permission check is done, it is done using the user namespace that owns that namespace that the relevant resource is in - for example, when I try to bind a privileged port, the permission check is done using the user namespace that owns the current network namespace (not the user namespace of the current process, which might well be different). Does that sound like the right concept?

User namespaces progress

Cyberax — 2013-01-03T21:24:01+00:00

Doesn't work with Java, just tried it on my system (it's Debian Stable).

User namespaces progress

andresfreund — 2013-01-03T21:21:29+00:00

Hm, I don't really see that as a problem. But anyway:

sudo /sbin/capsh --caps=cap_net_bind_service+pei == --user=andres -- -c "nc -l 434"

Yes. Ugly. But it works. (capsh is/was a demo tool)

User namespaces progress

Cyberax — 2013-01-03T21:09:08+00:00

That's much better than setting caps for executable files, but still has the problem of non-locality. It's impossible to understand from the daemon's command line that it magically acquires additional caps.

User namespaces progress

andresfreund — 2013-01-03T21:05:20+00:00

> By copying a binary.
> Beautiful. Not.

I only copied the binary because I do *not* want my normal nc to have the capability to bind to root-only ports.

> In many scenarios you probably will end up using something like capsh or pam-cap.

libpam-cap is probably easier for you:
apt-get install libpam-cap
pam-auth-update (enable "capabilities management")
sensible-editor /etc/security/capability.conf
# add "cap_net_bind_service cyberax"

It should be rather similar for other distributions.

Then start a new shell as your user (*not* via sudo "su - cyberax", use sudo -u cyberax, or su - cyberax from *your* user or such, pam_rootok makes a pretty unfortunate shortcut there) and voila:
andres@alap2:~$ sudo -u andres nc -l 434
^C

User namespaces progress

Cyberax — 2013-01-03T19:18:18+00:00

By copying a binary.

Beautiful. Not.

> In many scenarios you probably will end up using something like capsh or pam-cap.
I'll gladly send you a beer if you can give me a command line that actually works. I have tried all sorts of capsh command variations, but NONE of them works.

User namespaces progress

Cyberax — 2013-01-03T19:15:41+00:00

And now all Java programs have this privilege. Which is not that bad, since this restriction is brain-dead in the first place. But it also breaks during updates and is totally non-transparent (NOBODY checks file caps).

You might actually notice that I have an answer in the thread you've linked: http://stackoverflow.com/a/7701793/625001 However, while it works for erlang it somehow fails for Java. Don't ask me why.

User namespaces progress

andresfreund — 2013-01-03T17:44:32+00:00

It depends a bit on how you want to start java, but in general you can do stuff like:
$ nc -l 234
nc: Permission denied
$ cp `which nc` /tmp/nc && sudo setcap cap_net_bind_service+ep /tmp/nc
$ /tmp/nc -l 234
^C

In many scenarios you probably will end up using something like capsh or pam-cap.

User namespaces progress

man_ls — 2013-01-03T17:40:10+00:00

Have you tried setcap?

setcap 'cap_net_bind_service=+ep' /path/to/program

It worked for me but it was not Java; in your case run setcap for the java binary.

User namespaces progress

Cyberax — 2013-01-03T17:21:58+00:00

Ok. I have a Java application that needs to listen on port 80.

How do I do it? I've actually tried multiple ways and all of them failed.

User namespaces progress

andresfreund — 2013-01-03T17:18:47+00:00

Err, no. They can change their uid away after start without any problems. Or they can get an additional CAP_NET_BIND_SERVICE without all the rest of root's powers.

User namespaces progress

Cyberax — 2013-01-03T16:42:45+00:00

And forces you to run daemons under the freaking root user. Great improvement, yes.

User namespaces progress

ebiederm — 2013-01-03T07:59:20+00:00

Privileged ports keep those pesky users off of the ports where you run your servers.

User namespaces progress

ebiederm — 2013-01-03T07:57:12+00:00

When entering a user namespace you drop privileges.

The best way I can explain it is to describe an April Fool's day joke that you can play on your friendly local sysadmin.

Create a binary and call it something like $HOME/bin/su. Have that binary
call unshare(CLONE_NEWUSER) and write to /proc/[pid]/uid_map and /proc/[pid]/gid_map so that 0 in the current user namespace maps to the current uid and gid. Have this binary exec $SHELL. No privileges required.

Report that su is working without requiring root privileges in your account.

You can look around in /proc/self/status and see that your uid and gid are 0 and that you have all privs.

Extra points if you can get your local sysadmin to start trying to do things and from your $HOME/bin/su, because things really won't work and if you don't realize what is going on you are likely to be quite frustrated.
Services won't restart. You can't kill processes owned by other users etc.

Having a pam module set it up so that the user that looks like root has a distinct uid from everyone else is trickier to setup but could be more entertaining.

So while you have CAP_NET_BIND and can bind to any port in any network namespace you create, creating a network namespace won't do you much good because that network namespace is not connected to any other network namespace.

User namespaces progress

quotemstr — 2013-01-03T05:50:56+00:00

Besides: is the concept of a "privileged port" even relevant these days? It's a bad idea to make a security decision based on whether an incoming packet has a source port below 1024.

User namespaces progress

mkerrisk — 2013-01-03T03:31:35+00:00

So, what stops an unprivileged process from creating a new user namespace, so acquiring CAP_BIND in the new namespace, then binding a privileged port?

I think the answer there is that while the unprivileged process that creates a user namespace gets all privileges for operations inside the namespace, that doesn't give it privilege for operations on objects (e.g., a network namespace) outside the user namespace. To do what you are thinking of would require creating a network namespace inside the user namespace; you could then bind to privileged ports inside that network namespace.

User namespaces progress

kevinm — 2013-01-03T01:56:40+00:00

So, what stops an unprivileged process from creating a new user namespace, so acquiring CAP_BIND in the new namespace, then binding a privileged port?

Or does the creation of a new user namespace force the creation of a new namespace of all the other types at the same time?

User namespaces progress

luto — 2012-12-13T19:41:45+00:00

This article just inspired me to do some review :)

http://lkml.kernel.org/r/<50CA2B55.5070402@amacapital.net>

(That link is currently broken. I think it will come to life soon.)

User namespaces progress

rfrancoise — 2012-12-13T13:55:50+00:00

Allowing non-privileged users to create new network/ns/pid namespaces via userns is absolutely great. At the moment, Chrome/Chromium ships with a setuid-root helper to create pid/network namespaces to run the renderers into, it will become unnecessary once this work becomes available.

Combined with the new "mode 2" seccomp implementation it makes Linux a platform with strong sandboxing support!