Hi author here. Are you saying it doesn't allow a malicious/compromised container to reduce the pool size down to something which might cause other daemons to block, possibly indefinitely, which need "strong" entropy vs using /dev/urandom? Sure it's a really silly DoS, but it might matter in the right situations.
Thanks! It was a lot of hard work, I'm glad it's being well received and seems like people are generally finding it useful- the main point of writing it.
I would have liked to talk a lot more about other non-Linux solutions, but that's where most of the NCC Group consulting work has been, which was a main driver for why this info needs to be out there (companies not understanding container security or not "turning it up to 11" in places it needs to be). My background is also mainly Linux, so I stuck to what I know.
Hopefully someone else will release a similar paper on non-Linux solutions/unikernels/hybrid platforms?
Hi author here. I expected some folks who know a lot more about unikernels might have some feedback. I wanted to cover them because I think they're an interesting from a security perspective/they relate to containers but will admit I don't have much experiance with them. If you have time, I'm happy to fix the inaccuracies, feel free to DM me on twitter / email me? (first.last@nccgroup.trust) or (twitter.com/@dyn___). Thanks.
Hi author here, I'll admit I'm not super familiar with Mirage OS, I've only used it a bit, but I wanted to include some discussions of it. I had read it was related (somewhere I can't remember) but I'm happy to be corrected.
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.
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.
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.
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!
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.
Invoking the Trail of Tears to describe development hardship is, I think, inappropriate. Wish that guy would be a bit more cautious with his metaphors.
Given that you have affixed your name and have now heard of Jails and of Illumos (and SmartOS), you may want to consider amending your paper to state as such.
Also, Illumos was forked off Solaris, and I'm sure that you know of Solaris' security.
Looking forward to your amendment and revised paper.
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.
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.
Yes, that is what I was trying to say. I'll clarify it in a future version.
That's a good point, I'll include that! Thanks.