Hacker News Reader

Comment by vito | Hacker News Reader

The post mentions not having a daemon running as root, but then you have to run `rkt` as root anyway. Won't this just mean that instead of having a single implementation of a Rocket daemon running as root, there is now one custom one every time it needs to be automated?

It's great to see this problem broken up into reusable pieces though. It totally makes sense to function without a daemon, especially out of the box.

View on HN

There actually is a significant difference between having 'rkt' as a setuid-root process that's invoked from the command line, and having a docker server always running waiting for commands. There are more ways for a potential attacker to get at the server. So, Rocket at least looks like they're trying to shrink the attack surface.

> There are more ways for a potential attacker to get at the server. So, Rocket at least looks like they're trying to shrink the attack surface.

hm.. I don't think that's a given at all! There's been many issues with setuid-root programs. And I've seen that the OpenBSD guys favor privilege separation by breaking breaking up daemons into several parts that communicate using a very strict set of commands. For example a dockerd that does most of the work, but talks to another daemon (dockerd-root) when it needs to do anything privileged.

OpenSMTPD example: https://www.opensmtpd.org/presentations/asiabsdcon2013-smtpd...

OpenSSH: Initial efort, 2002: http://www.citi.umich.edu/u/provos/ssh/privsep.html

http://www.openbsd.org/papers/openssh-measures-asiabsdcon200... - Page 16 ->

"Looks like" is usually about as far as people get when they start down this road. If they make it down the road, they arrive at mess. Just look at what OpenStack has been through :)

So then, I guess docker could just run the two servers, one internal as root and one public as not? That's a pretty quick fix.

> There actually is a significant difference between having 'rkt' as a setuid-root process that's invoked from the command line, and having a docker server always running waiting for commands. There are more ways for a potential attacker to get at the server.

Wrong. With a server, the only thing an attacker has control over is its input. With a setuid-root binary, they still have control over its input, but they also have control over the entire environment under which it executes, including many things that developers generally assume an attacker can't control. Setuid binaries are incredibly scary from a security perspective and much harder to get right than servers.

Yep, setuid would make sense. Hopefully that's how people end up using it. (i.e. Rocket should document or distribute it that way)

Reply on news.ycombinator.com