6 ms·

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 imple

by vito 12y ago

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.

rst 12y ago
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.
- vito 12y ago
  Yep, setuid would make sense. Hopefully that's how people end up using it. (i.e. Rocket should document or distribute it that way)
- makomk 12y ago
  > 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.
- Rapzid 12y ago
  "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.
- deleted 12y ago
  [deleted]
- gizzlon 12y ago
  > 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/#slide-26 https://www.opensmtpd.org/presentations/asiabsdcon2013-smtpd... OpenSSH: Initial efort, 2002: http://www.citi.umich.edu/u/provos/ssh/privsep.html http://www.citi.umich.edu/u/provos/ssh/privsep.html http://www.openbsd.org/papers/openssh-measures-asiabsdcon2007-slides.pdf http://www.openbsd.org/papers/openssh-measures-asiabsdcon200... - Page 16 ->

by vito 12y ago

rst 12y ago

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.

vito 12y ago
Yep, setuid would make sense. Hopefully that's how people end up using it. (i.e. Rocket should document or distribute it that way)
makomk 12y ago
> 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.
Rapzid 12y ago
"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.
deleted 12y ago
[deleted]
gizzlon 12y ago
> 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/#slide-26 https://www.opensmtpd.org/presentations/asiabsdcon2013-smtpd... OpenSSH: Initial efort, 2002: http://www.citi.umich.edu/u/provos/ssh/privsep.html http://www.citi.umich.edu/u/provos/ssh/privsep.html http://www.openbsd.org/papers/openssh-measures-asiabsdcon2007-slides.pdf http://www.openbsd.org/papers/openssh-measures-asiabsdcon200... - Page 16 ->