5 ms·

And now I wait for a poor soul to summarize those 100 pages in a paragraph or two.

by xori 11y ago

somethingnew 11y ago
Here's a summary from the Docker perspective https://blog.docker.com/2016/04/docker-security/ https://blog.docker.com/2016/04/docker-security/
- jsmthrowaway 11y ago
  The table from the report and Docker's championing thereof are also (nearly flagrantly) misleading, since Docker only supports image signing if you use the public hub. You cannot (repeat: cannot) sign Docker containers any other way, so it's barely a half feature and does not work for enterprises at all. But it says "strong defaults" in their table when describing this oddly useless feature, since enterprises are the ones most likely to invest in a serious key infrastructure and actually use signing: https://docs.docker.com/engine/security/trust/content_trust/ https://docs.docker.com/engine/security/trust/content_trust/ > Content trust is currently only available for users of the public Docker Hub. It is currently not available for the Docker Trusted Registry or for private registries. > Currently, content trust is disabled by default. You must enable it by setting the DOCKER_CONTENT_TRUST environment variable. How is the complete lack of image verification until explicitly enabled, and only on public images, a "strong default"? I'm also mystified by the row for SELinux, where rkt has Optional in scary yellow for some reason, and the other two do not. I suspect that table was the whole point of the independent review and it is fulfilling its purpose handily for Docker. I haven't even read the report and I can identify four suspicious discrepancies in that table alone. ETA: Compare how the author describes Docker to rkt (it's rkt, not Rkt, too): http://imgur.com/a/D6nEw http://imgur.com/a/D6nEw
  - dyn 11y ago
    Hi, author of paper here. Couple things: - I agree the requirement of using Docker hub or their private hub is an unfortunate requirement, but I'm talking purely about the technical implementation. "Does not work for enterprises at all", well, there are a number of large enterprises that would disagree with you ;) - For the table w/ SELinux row, Rkt is optional "scary" yellow because it only supports a single MAC implementation, it isn't very portable, and it's not enabled by default, vs LXC and Docker which both have quite strong MAC policies by default. Trying to parse all the info down into a table was honestly quite difficult (balancing being able to read it without a million footnotes for each point). Hopefully readers don't take all their take-aways from the table, and read the paper in full. - I used Rkt for the name and rkt for the command. Seemed to help consistency. Thanks for your feedback.
    - jsmthrowaway 11y ago
      Thanks for responding. I'm talking about the technical implementation, too. How is a feature hidden behind an environment variable a "strong default?" And Docker simply screenshot the table, so noble goal, but... I suppose I could remark upon MESOS, Rkt, and so on, and how getting names right is important because it characterizes the rest of your thoughts and analysis of the things you're studying, but I'll stick with the question I started with here.
    - mjg59 11y ago
      (Disclaimer: I added SELinux support to CoreOS) I'm a little confused around the SELinux issue. SELinux is inherently unportable - each distribution has its own policy (generally based on refpolicy, but sometimes fairly divergent), and it's basically impossible for an application to ship a policy that's compatible with more than one distribution. Rkt's SELinux design inherits from SVirt in such a way that in most cases it'll just work with a distribution's existing SELinux policy. It's fair to say that the number of distributions that ship policy that works with Docker is larger than for rkt, but this is fundamentally about distribution priorities rather than technological choices. On Fedora, rkt should provide identical SELinux confinement to Docker - on CoreOS it'll be better, since we support SELinux on overlayfs as well. Whether SELinux is enabled or not is (again) a distribution choice. Fedora ship with SELinux enabled by default, and both rkt and Docker will use it as a result.
  - bigmac 11y ago
    You cannot (repeat: cannot) sign Docker containers any other way, so it's barely a half feature and does not work for enterprises at all. What makes you think this? It is 100%, patently false. Private notary servers can be deployed alongside private registry servers without problem. See here for docs on how to do it: https://github.com/docker/notary/blob/master/docs/running_a_service.md https://github.com/docker/notary/blob/master/docs/running_a_...
    - jsmthrowaway 11y ago
      > What makes you think this? The docs I linked and quoted, written by your own organization and helpfully pasted into the point I made? I'm glad to see it's possible (if cumbersome), but I ruled Docker out for this purpose based on the exact link I just pasted. I also followed up and didn't see a "hey, you can sign private registries" bullet in your blog post responding to this paper, or much of anywhere, and Googling "docker sign private registries" doesn't go anywhere. I'm still unsure why I'd stand up several daemons to accomplish signing a file, but that's a side point. ---- ETA: I can no longer reply because I've burned my precious HN comment budget commenting upon this paper (sorry, blame HN), so here's what I would reply to you downthread: > 1. We have to host the signatures somewhere, so we host them in a store we call the notary server. We've had this solved for a long time with .asc files, and Docker is already shipping an HTTP server or six. Shit, extend the Docker format and put the signature on each layer. There's a lot of prior art from RPM and dpkg in particular on how this can be done without writing yet another Docker daemon to run. I'm sorry, I have to call bullshit, here. Docker is a very strong daemon-for-everything engineering culture, and that's the only reason it exists. It's also why folks are competing with you, because there are three or four different daemons in the Docker ecosystem that simply should not exist. Including dockerd. > Think serving an outdated container with known-vulnerable software. Sadly, most artifact signing systems do not mitigate this attack today, Because it's out of scope of a signature. That is conflating a signature with content revocation, which is a different problem altogether. A signature is an attestation of certain properties of data, and "is no longer valid content because circumstances changed after it was signed" is not one of them. The validity of the content is orthogonal to its signature. That known-vulnerable container is still a valid signature, and it's overreaching to expect a signature system to solve that problem. That is solvable in other ways. Known-bad OpenSSL is still signed in repositories. And valid. And that's fine, because it's a separation of concerns; you get non-repudiation, integrity, all that stuff from a signature scheme. Upgrading to gatekeeping content on top of signatures indicates to me a fundamental misunderstanding of the problem ("can I run this?" instead of "this is an authenticated, intact image that came from where I expect"), which concerns me. You can solve the problem you present in other ways. Mixing in the term "replay attack" is extremely confusing and I think diluting your point, because it is baffling me and really does not apply to what you are saying.
mikecb 11y ago
There's TL;drs at the end of some sections.
fabulist 11y ago
This is not a sound security strategy.
otterley 11y ago
The whole paper is worth reading and is largely factually and historically correct. People often pay analysts hundreds of dollars for papers like this. Consider it a gift.
- jsmthrowaway 11y ago
  > The whole paper is worth reading and is largely factually and historically correct. I found six inaccuracies in as many minutes after opening the PDF and scrolling to random pages. So I'm not sure that's true. I'm also not the only one making that claim, `spender has too: https://twitter.com/grsecurity/status/722935691114512385?lang=en https://twitter.com/grsecurity/status/722935691114512385?lan... I don't want to knock the paper too hard without actually sitting down and reading it (which I'm going to do tonight, and I won't dump raw notes on HN until I've given the paper a serious chance), but I'm not encouraged right off the bat. I've been deep in the rkt integration hole and a lot of stuff referring to rkt is very rough and surface-level and, in five of the cases I mentioned, blatantly factually inaccurate. Same with Docker, too, actually, though the paper is quite obviously partisan (see http://imgur.com/a/D6nEw http://imgur.com/a/D6nEw for example).
  - dyn 11y ago
    Hi, Author of the paper here. After seeing the email Spender sent me, I can say most of his fixes/recommendations don't change a lot of the core messages/points/etc, even on grsec related sections. I'll be releasing a new version soon-ish merging in some of his feedback. I tried extremely hard to not be "partisan", and I don't think I am kind to any container platform, but it's hard to argue where Docker is vs Rkt in terms of security (apart from possibly hw virtualization in Rkt Stage 1). I agree some of the Rkt stuff is higher level, mostly because after a large number of container assessments at some major companies, I have yet to come across Rkt. Most of my research comes from my own brief analysis, and the analysis of some peers. Maybe a future version will cover it more in-depth.
    - lawnchair_larry 11y ago
      Despite the criticisms, this is a much needed analysis in this space, and looks very thorough. I've met countless development teams jumping in to these stacks and trying to find good security advice, or some kind of whitepaper to spell it all out. Looking forward to the updated version, and I believe this will help a lot of people with their projects.
nisa 11y ago
TL;DR: Pay attention to arcane details or don't use containers for security related stuff. Also grsecurity. Honest question: Are illumos zones or FreeBSD jails better designed or is just nobody looking for kernel bugs there? From a usability perspective both win (IMHO) against this Linux mess. This document is really great through.
- dyn 11y ago
  Author of the paper here. Thanks. As for Jails and Illumos, I would be willing to bet it's people not looking, but I haven't looked, so I can't really say. I agree it's kind of a mess, but it's getting better!
  - ktzar 11y ago
    Is there a chance a repo with a .md version or an epub can be shared? It's quite hard to read a 100+ PDF document without printing it.
    - voidz 11y ago
      I'd like this too. An .epub would be nice for e-ink readers like Pocketbook, Kobo, and Kindle.
  - voidz 11y ago
    Is it possible to get notified (via email) when this paper has been updated?
  - Annatar 11y ago
    You would lose that bet so fast your head would be both spinning and smoking: zones have been hardened and worked on for enterprises since 2006, and in ten years have had three known vulnerabilities, the last two having already been fixed in illumos (and not exploitable without being able to be explicitly run by a user inside of a hypervisor). As Bryan Catrill has said in one of his talks: "we walked the trail if tears since our customers were very large companies; if they had a problem, we had a problem!" The illumos and smartos mailing lists are hyperactive, with bugs being fixed, and new functionality added, which even Oracle Solaris doesn't have -- just subscribe to those two mailing lists and see for yourself. I warn you in advance: be prepared to be buried under the vortex of e-mails.

And now I wait for a poor soul to summarize those 100 pages in a paragraph or two.

by xori 11y ago

And now I wait for a poor soul to summarize those 100 pages in a paragraph or two.

Here's a summary from the Docker perspective https://blog.docker.com/2016/04/docker-security/ https://blog.docker.com/2016/04/docker-security/

jsmthrowaway 11y ago
The table from the report and Docker's championing thereof are also (nearly flagrantly) misleading, since Docker only supports image signing if you use the public hub. You cannot (repeat: cannot) sign Docker containers any other way, so it's barely a half feature and does not work for enterprises at all. But it says "strong defaults" in their table when describing this oddly useless feature, since enterprises are the ones most likely to invest in a serious key infrastructure and actually use signing: https://docs.docker.com/engine/security/trust/content_trust/ https://docs.docker.com/engine/security/trust/content_trust/ > Content trust is currently only available for users of the public Docker Hub. It is currently not available for the Docker Trusted Registry or for private registries. > Currently, content trust is disabled by default. You must enable it by setting the DOCKER_CONTENT_TRUST environment variable. How is the complete lack of image verification until explicitly enabled, and only on public images, a "strong default"? I'm also mystified by the row for SELinux, where rkt has Optional in scary yellow for some reason, and the other two do not. I suspect that table was the whole point of the independent review and it is fulfilling its purpose handily for Docker. I haven't even read the report and I can identify four suspicious discrepancies in that table alone. ETA: Compare how the author describes Docker to rkt (it's rkt, not Rkt, too): http://imgur.com/a/D6nEw http://imgur.com/a/D6nEw
- dyn 11y ago
  Hi, author of paper here. Couple things: - I agree the requirement of using Docker hub or their private hub is an unfortunate requirement, but I'm talking purely about the technical implementation. "Does not work for enterprises at all", well, there are a number of large enterprises that would disagree with you ;) - For the table w/ SELinux row, Rkt is optional "scary" yellow because it only supports a single MAC implementation, it isn't very portable, and it's not enabled by default, vs LXC and Docker which both have quite strong MAC policies by default. Trying to parse all the info down into a table was honestly quite difficult (balancing being able to read it without a million footnotes for each point). Hopefully readers don't take all their take-aways from the table, and read the paper in full. - I used Rkt for the name and rkt for the command. Seemed to help consistency. Thanks for your feedback.
  - jsmthrowaway 11y ago
    Thanks for responding. I'm talking about the technical implementation, too. How is a feature hidden behind an environment variable a "strong default?" And Docker simply screenshot the table, so noble goal, but... I suppose I could remark upon MESOS, Rkt, and so on, and how getting names right is important because it characterizes the rest of your thoughts and analysis of the things you're studying, but I'll stick with the question I started with here.
  - mjg59 11y ago
    (Disclaimer: I added SELinux support to CoreOS) I'm a little confused around the SELinux issue. SELinux is inherently unportable - each distribution has its own policy (generally based on refpolicy, but sometimes fairly divergent), and it's basically impossible for an application to ship a policy that's compatible with more than one distribution. Rkt's SELinux design inherits from SVirt in such a way that in most cases it'll just work with a distribution's existing SELinux policy. It's fair to say that the number of distributions that ship policy that works with Docker is larger than for rkt, but this is fundamentally about distribution priorities rather than technological choices. On Fedora, rkt should provide identical SELinux confinement to Docker - on CoreOS it'll be better, since we support SELinux on overlayfs as well. Whether SELinux is enabled or not is (again) a distribution choice. Fedora ship with SELinux enabled by default, and both rkt and Docker will use it as a result.
- bigmac 11y ago
  You cannot (repeat: cannot) sign Docker containers any other way, so it's barely a half feature and does not work for enterprises at all. What makes you think this? It is 100%, patently false. Private notary servers can be deployed alongside private registry servers without problem. See here for docs on how to do it: https://github.com/docker/notary/blob/master/docs/running_a_service.md https://github.com/docker/notary/blob/master/docs/running_a_...
  - jsmthrowaway 11y ago
    > What makes you think this? The docs I linked and quoted, written by your own organization and helpfully pasted into the point I made? I'm glad to see it's possible (if cumbersome), but I ruled Docker out for this purpose based on the exact link I just pasted. I also followed up and didn't see a "hey, you can sign private registries" bullet in your blog post responding to this paper, or much of anywhere, and Googling "docker sign private registries" doesn't go anywhere. I'm still unsure why I'd stand up several daemons to accomplish signing a file, but that's a side point. ---- ETA: I can no longer reply because I've burned my precious HN comment budget commenting upon this paper (sorry, blame HN), so here's what I would reply to you downthread: > 1. We have to host the signatures somewhere, so we host them in a store we call the notary server. We've had this solved for a long time with .asc files, and Docker is already shipping an HTTP server or six. Shit, extend the Docker format and put the signature on each layer. There's a lot of prior art from RPM and dpkg in particular on how this can be done without writing yet another Docker daemon to run. I'm sorry, I have to call bullshit, here. Docker is a very strong daemon-for-everything engineering culture, and that's the only reason it exists. It's also why folks are competing with you, because there are three or four different daemons in the Docker ecosystem that simply should not exist. Including dockerd. > Think serving an outdated container with known-vulnerable software. Sadly, most artifact signing systems do not mitigate this attack today, Because it's out of scope of a signature. That is conflating a signature with content revocation, which is a different problem altogether. A signature is an attestation of certain properties of data, and "is no longer valid content because circumstances changed after it was signed" is not one of them. The validity of the content is orthogonal to its signature. That known-vulnerable container is still a valid signature, and it's overreaching to expect a signature system to solve that problem. That is solvable in other ways. Known-bad OpenSSL is still signed in repositories. And valid. And that's fine, because it's a separation of concerns; you get non-repudiation, integrity, all that stuff from a signature scheme. Upgrading to gatekeeping content on top of signatures indicates to me a fundamental misunderstanding of the problem ("can I run this?" instead of "this is an authenticated, intact image that came from where I expect"), which concerns me. You can solve the problem you present in other ways. Mixing in the term "replay attack" is extremely confusing and I think diluting your point, because it is baffling me and really does not apply to what you are saying.

mikecb 11y ago

There's TL;drs at the end of some sections.

fabulist 11y ago

This is not a sound security strategy.

otterley 11y ago

The whole paper is worth reading and is largely factually and historically correct. People often pay analysts hundreds of dollars for papers like this. Consider it a gift.

jsmthrowaway 11y ago
> The whole paper is worth reading and is largely factually and historically correct. I found six inaccuracies in as many minutes after opening the PDF and scrolling to random pages. So I'm not sure that's true. I'm also not the only one making that claim, `spender has too: https://twitter.com/grsecurity/status/722935691114512385?lang=en https://twitter.com/grsecurity/status/722935691114512385?lan... I don't want to knock the paper too hard without actually sitting down and reading it (which I'm going to do tonight, and I won't dump raw notes on HN until I've given the paper a serious chance), but I'm not encouraged right off the bat. I've been deep in the rkt integration hole and a lot of stuff referring to rkt is very rough and surface-level and, in five of the cases I mentioned, blatantly factually inaccurate. Same with Docker, too, actually, though the paper is quite obviously partisan (see http://imgur.com/a/D6nEw http://imgur.com/a/D6nEw for example).
- dyn 11y ago
  Hi, Author of the paper here. After seeing the email Spender sent me, I can say most of his fixes/recommendations don't change a lot of the core messages/points/etc, even on grsec related sections. I'll be releasing a new version soon-ish merging in some of his feedback. I tried extremely hard to not be "partisan", and I don't think I am kind to any container platform, but it's hard to argue where Docker is vs Rkt in terms of security (apart from possibly hw virtualization in Rkt Stage 1). I agree some of the Rkt stuff is higher level, mostly because after a large number of container assessments at some major companies, I have yet to come across Rkt. Most of my research comes from my own brief analysis, and the analysis of some peers. Maybe a future version will cover it more in-depth.
  - lawnchair_larry 11y ago
    Despite the criticisms, this is a much needed analysis in this space, and looks very thorough. I've met countless development teams jumping in to these stacks and trying to find good security advice, or some kind of whitepaper to spell it all out. Looking forward to the updated version, and I believe this will help a lot of people with their projects.

nisa 11y ago

TL;DR: Pay attention to arcane details or don't use containers for security related stuff. Also grsecurity. Honest question: Are illumos zones or FreeBSD jails better designed or is just nobody looking for kernel bugs there? From a usability perspective both win (IMHO) against this Linux mess. This document is really great through.

dyn 11y ago
Author of the paper here. Thanks. As for Jails and Illumos, I would be willing to bet it's people not looking, but I haven't looked, so I can't really say. I agree it's kind of a mess, but it's getting better!
- ktzar 11y ago
  Is there a chance a repo with a .md version or an epub can be shared? It's quite hard to read a 100+ PDF document without printing it.
  - voidz 11y ago
    I'd like this too. An .epub would be nice for e-ink readers like Pocketbook, Kobo, and Kindle.
- voidz 11y ago
  Is it possible to get notified (via email) when this paper has been updated?
- Annatar 11y ago
  You would lose that bet so fast your head would be both spinning and smoking: zones have been hardened and worked on for enterprises since 2006, and in ten years have had three known vulnerabilities, the last two having already been fixed in illumos (and not exploitable without being able to be explicitly run by a user inside of a hypervisor). As Bryan Catrill has said in one of his talks: "we walked the trail if tears since our customers were very large companies; if they had a problem, we had a problem!" The illumos and smartos mailing lists are hyperactive, with bugs being fixed, and new functionality added, which even Oracle Solaris doesn't have -- just subscribe to those two mailing lists and see for yourself. I warn you in advance: be prepared to be buried under the vortex of e-mails.