4 ms·

Got the same impression. Now what is needed is to split the docker daemon into little parts with least privileges. An example of that, yesterday while trying t

by zimbatm 12y ago

Got the same impression. Now what is needed is to split the docker daemon into little parts with least privileges. An example of that, yesterday while trying to see if I could implement `docker build` using available commands, I found out that the docker daemon is shelling out to git on the server side if a remote url is given. It seems risky since the server is running with a lot of privileges that aren't needed for that task. https://github.com/docker/docker/blob/master/builder/job.go#L79 https://github.com/docker/docker/blob/master/builder/job.go#...

jlhawn 12y ago
> trying to see if I could implement `docker build` using available commands This should be possible soon! The only command missing is a symmetric `docker cp`. I've got most of the implementation ready to be reviewed in a pull request [1] (closed now, but I will reopen it soon). [1] https://github.com/docker/docker/pull/10198#issuecomment-73336761 https://github.com/docker/docker/pull/10198#issuecomment-733...
shykes 12y ago
The split into smaller binaries is something I'm very open to. We just want to make sure the user experience doesn't get sacrificed. Here's a recent discussion thread on the subject: https://groups.google.com/forum/#!topic/docker-dev/mzpAga_XZ-Y https://groups.google.com/forum/#!topic/docker-dev/mzpAga_XZ...
- eropple 12y ago
  The way you phrase that suggests that user experience is more important than security. Care to clarify?
  - Rapzid 12y ago
    That's a ridiculously loaded question. User experience is balanced against security all the time.
  - darkarmani 12y ago
    > The way you phrase that suggests that user experience is more important than security Of course it is. Steve Yegge put it best: > But I'll argue that Accessibility is actually more important than Security because dialing Accessibility to zero means you have no product at all, whereas dialing Security to zero can still get you a reasonably successful product such as the Playstation Network. Ha ha. You can always layer security around how use use Docker, but without any usability what do you have? Chop the network cable and you get the tradeoff you are looking for.
    - eropple 12y ago
      Your response is terrifying. Comparing core, must-not-fail infrastructural systems the same in terms of security needs as a consumer-facing video game platform is, to me, very much misguided, and I think it betrays the difference in mindset between "product people" and "platform people": as a platform people, my stuff must not fucking break and vendors that build stuff that make things more likely to break are poisonous. The continually lackadaisical approach to security and reliability (basic features around reliability being post-1.0 is unconscionably bad, and user privilege segmentation, as noted, still hasn't happened), in ways I can't patch around, is one of the reasons I'm honestly hoping for a Docker competitor to arise that would trade that growth-fuel "user experience" for security, reliability, and a less compromised ethos. (I am considering a move of my systems to OpenBSD, but in AWS that's difficult.) This leads me to thinking about a larger problem in the current ecosystem: core infrastructure being tied to a VC-backed, growth-as-a-prerequisite startup (where you really can convince yourself that making it easy is more important than making it popular) scares me deeply, because building the right thing becomes less incentivized than building the popular thing. I hope this is not the way of the future, because things already work poorly enough and are insecure enough as it is. =/
      - shykes 12y ago
        I'm happy to address any specific concerns you have about security. It's an important topic for me. In this particular comment I could only spot one specific criticism: the lack of built-in user segmentation, so I will talk about that. I agree that this would be a nice feature. But we decided to not rush it, and instead tell operators to rely on the underlying system features for authentication, segmentation etc. In practice that means: * If you have an https auth infrastructure in production, drop the appropriate middleware in front of your docker daemon, and rely on that. * If you rely on ssh keys and unix access control in production, keep the default configuration of listening on a unix socket, and use regular unix users to decide who gets to talk to the socket. * If you run trusted payloads, or if you run untrusted payloads with acceptable mitigation in place (no root inside the container, apparmor/selinux, inter-container networking disabled etc.), then go ahead and pool all your machines into a single swarm. * If you run untrusted payloads, then map each trust domain to an isolated group of underlying machines. This is what Amazon, Google and others do when running customer payloads on Docker for example. It would be a nice feature to segment Docker API endpoints by user, so that different users have different views (and different levels of access) of the same underlying daemon. But that requires implementing an authentication and authorization layer, and it requires changing some aspects of the Docker API which imply privileged access to the system. For example, the 'docker run -v /foo:/bar'. This represents serious engineering work, and as much as I would like to make you happy tomorrow, I don't think you will be any happier if we ship an unfinished feature.

by zimbatm 12y ago

jlhawn 12y ago

> trying to see if I could implement `docker build` using available commands This should be possible soon! The only command missing is a symmetric `docker cp`. I've got most of the implementation ready to be reviewed in a pull request [1] (closed now, but I will reopen it soon). [1] https://github.com/docker/docker/pull/10198#issuecomment-73336761 https://github.com/docker/docker/pull/10198#issuecomment-733...

shykes 12y ago

The split into smaller binaries is something I'm very open to. We just want to make sure the user experience doesn't get sacrificed. Here's a recent discussion thread on the subject: https://groups.google.com/forum/#!topic/docker-dev/mzpAga_XZ-Y https://groups.google.com/forum/#!topic/docker-dev/mzpAga_XZ...

eropple 12y ago
The way you phrase that suggests that user experience is more important than security. Care to clarify?
- Rapzid 12y ago
  That's a ridiculously loaded question. User experience is balanced against security all the time.
- darkarmani 12y ago
  > The way you phrase that suggests that user experience is more important than security Of course it is. Steve Yegge put it best: > But I'll argue that Accessibility is actually more important than Security because dialing Accessibility to zero means you have no product at all, whereas dialing Security to zero can still get you a reasonably successful product such as the Playstation Network. Ha ha. You can always layer security around how use use Docker, but without any usability what do you have? Chop the network cable and you get the tradeoff you are looking for.
  - eropple 12y ago
    Your response is terrifying. Comparing core, must-not-fail infrastructural systems the same in terms of security needs as a consumer-facing video game platform is, to me, very much misguided, and I think it betrays the difference in mindset between "product people" and "platform people": as a platform people, my stuff must not fucking break and vendors that build stuff that make things more likely to break are poisonous. The continually lackadaisical approach to security and reliability (basic features around reliability being post-1.0 is unconscionably bad, and user privilege segmentation, as noted, still hasn't happened), in ways I can't patch around, is one of the reasons I'm honestly hoping for a Docker competitor to arise that would trade that growth-fuel "user experience" for security, reliability, and a less compromised ethos. (I am considering a move of my systems to OpenBSD, but in AWS that's difficult.) This leads me to thinking about a larger problem in the current ecosystem: core infrastructure being tied to a VC-backed, growth-as-a-prerequisite startup (where you really can convince yourself that making it easy is more important than making it popular) scares me deeply, because building the right thing becomes less incentivized than building the popular thing. I hope this is not the way of the future, because things already work poorly enough and are insecure enough as it is. =/
    - shykes 12y ago
      I'm happy to address any specific concerns you have about security. It's an important topic for me. In this particular comment I could only spot one specific criticism: the lack of built-in user segmentation, so I will talk about that. I agree that this would be a nice feature. But we decided to not rush it, and instead tell operators to rely on the underlying system features for authentication, segmentation etc. In practice that means: * If you have an https auth infrastructure in production, drop the appropriate middleware in front of your docker daemon, and rely on that. * If you rely on ssh keys and unix access control in production, keep the default configuration of listening on a unix socket, and use regular unix users to decide who gets to talk to the socket. * If you run trusted payloads, or if you run untrusted payloads with acceptable mitigation in place (no root inside the container, apparmor/selinux, inter-container networking disabled etc.), then go ahead and pool all your machines into a single swarm. * If you run untrusted payloads, then map each trust domain to an isolated group of underlying machines. This is what Amazon, Google and others do when running customer payloads on Docker for example. It would be a nice feature to segment Docker API endpoints by user, so that different users have different views (and different levels of access) of the same underlying daemon. But that requires implementing an authentication and authorization layer, and it requires changing some aspects of the Docker API which imply privileged access to the system. For example, the 'docker run -v /foo:/bar'. This represents serious engineering work, and as much as I would like to make you happy tomorrow, I don't think you will be any happier if we ship an unfinished feature.