Hacker News Reader

Comment by Perceptes | Hacker News Reader

Any security folks have some specific practical examples of how running processes as root inside the container is dangerous? I understand how root in the container mapping to root on the host is risky (this is what user namespaces are for) but I don't have enough experience to know why it matters inside the container.

View on HN

Given the possibility of a container escape, it's far better for the escapee to find himself on the outside as a normal user. Just like with kernel exploits, most escapes rely on access to esoteric, complicated, or poorly understood devices or functions. Obviously, there are fewer of those in userspace. Imagine, for example, an escape that required arbitrary network control. That would be much harder to pull off (if not impossible) from userspace.

There have been and will continue to be parts of the kernel hard-coded to respect UID 0. Until these are all found and fixed (likely many years from now) using usernamespaces to remap root will not provide all the safety one might assume. It is super handy for other users though.

Full disclosure - I am both a hatter and a sec guy.

The attacker can install a keylogger as normal user and then wait for the sudo password. How much better is that, really?

How would a normal user go about installing this system-wde keylogger?

It wouldn't be system-wide. You'd need to compromise an interactive user account, install and run the keylogger as them, and wait for them to su or sudo. So it's a means of escalating privileges from a regular user account.

Right, and your daemons use sub-1000 UIDs and user UIDs start at 1000. In Debian, at least. Other distros have other starting points, but the concept remains the same.

Value for each delta will vary, but every extra step (the need to install a keylogger) or dependency requirement (that this be an interactive node and someone eventually logs in) will decrease your overall chance of penetration.

Almost no one has the resources to stand up to a targeted attack from even a mildly capable hacker. Therefore, the risk profile most administrators are working against are attacks of opportunity. In that race, as in the old joke about outrunning your friend instead of a lion, you need only be be some small amount more difficult to crack than the next potential victim.

The user under which the application is running shouldn't even be in the sudo group.

Can you speak to the security implications of building the container as a remapped root and running as a user?

My understanding is that the most important reason to have root in the container is to install software through the standard measures, but obviously, we don't want to have to run our build process for containers as root on the real host.

Given the comparatively restricted behavior, is this a good practice or are there implications of using a remapped root during container build time that would linger on to run time?

That should be fine. The only "lingering" effects would be possibly suid or SELinux labeling oddities, but those are easy to watch out for.

And I should have been clear that a remapped root that drops drops privileges and/or transitions into another user is still better than an unremapped root doing the same. It's just that the remapping is not a panacea.

Though things have improved considerably a while back with docker dropping most capabilities before starting a container, but without user namespacing on a shared kernel, ultimately root in the container == root in the host machine.

More specifically, uid 0 on the container == uid 0 on the host, so if container breakout occurs then you have root on the host.

As you mention, user namespaces and remapping the root user should solve this issue, but initial support for this was only released 7 days ago in docker 1.10.2 > https://github.com/docker/docker/commit/ed9434c5bb64f49db442...

[edit]: Preliminary support for user namespaces was added in 1.10, above commit is addressing a bug in userns support.

Apart from that Docker doesn't really utilize user namespaces until recently, user namespaces are tricky. There have historically been buts and ifs involved. Don't rely on it unless you really understand it!

But why would you want to run things as root anyway? You probably didn't before Docker, so why do it now? With Docker, there's even less reason to muck about with capabilities for binding low ports etc. It's absolutely an unnecessary risk to take.

If one use host volumes, Docker has no way to setup them in a way that are usable for non-root container. There are workarounds, but running as root is a simplest thing to do that I think many follow.

That is a strange thing to say. If a mounted volume is reason for you to do away with permissions, you're doing it wrong.

You can obviate almost all the issues by running docker with --drop-cap all to drop all capabilities. You still share the uid, but with the default seccomp policy blocking ptrace as well it is pretty secure. Obviously running as a user as well is better.

Reply on news.ycombinator.com