10 ms·

Understanding and Hardening Linux Containers [pdf]

196 points by secalex 10y ago

xori 10y ago
And now I wait for a poor soul to summarize those 100 pages in a paragraph or two.
- somethingnew 10y 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 10y 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 10y 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 10y 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 10y 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.
- mikecb 10y ago
  There's TL;drs at the end of some sections.
- fabulist 10y ago
  This is not a sound security strategy.
- otterley 10y 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 10y 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 10y 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 10y 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 10y 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 10y 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 10y 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 10y ago
        I'd like this too. An .epub would be nice for e-ink readers like Pocketbook, Kobo, and Kindle.
    - voidz 10y ago
      Is it possible to get notified (via email) when this paper has been updated?
    - Annatar 10y 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.
ishtu 10y ago
"Containers are great. It's a shame Linux doesn't have any."
geggam 10y ago
This..... this is the thing every architect attempting to roll containers out to production needs to read and re read Complexity at scale: Orchestration frameworks (Rancher, MESOS/Aurora, Docker Swarm, LXD, OpenStack Containers, Kubernetes/Borg, etc) are only recently catching up to the container craze, there are too many competing models to list. Many have questionable or unaudited security or leave major requirements out, such as secret management. While containers may be easy to get working within a workstation or a few servers, scaling them up to production deployment is another challenge altogether, even assuming your application stack can be properly ``containerized''
- dmpk2k 10y ago
  My experience with Joyent's Triton stack has been both simple and positive. Much of the stuff in Section 10 either doesn't apply to the Triton stack (e.g. their implementation of the Docker server doesn't leave sockets lying around), or has already been solved there (e.g. their container implementation has already been hardened over a decade, and actually works well). I'm obviously quite the fan. This document is more an indictment of the current state of the Linux container ecosystem, rather than containers themselves. Don't conflate the two.
  - geggam 10y ago
    Reading more and more of the document ... you might change your mind if you do so :)
    - dmpk2k 10y ago
      Yes, that's true. I was being a bit unfair.
- kyrra 10y ago
  The opinions stated here are my own, not necessarily those of Google. From my understanding Google was one of the main contributors of the core features that have allowed containers on Linux. Specifically cgroups and LXC. And they have have been running containers for 10 years: https://research.google.com/pubs/pub43438.html https://research.google.com/pubs/pub43438.html I'm not sure what you consider new, but it's definitely not super new to Google. I'm guessing your issue is that it's fairly new to being used in production across many companies, so security researchers are just starting to work on finding holes in it.
tyingq 10y ago
"While Linux Container systems (LXC, Docker, CoreOS Rocket, etc) have undergone fast deployment and development, security knowledge has lagged behind. The number of people focused on container security...seems disproportionately small" I agree with this part. Most containers aren't running as an unprivileged user. Those environments that do support it only support it in a very limited set of os/kernel/whatever versions. Somewhat concerning since containers are getting traction almost everywhere.
- cyphar 10y ago
  Oddly enough, quite a few people in the runC community (including myself) are working on implementing the ability to start containers without root. If we can get this to work, it will be brought to Docker and you'll be able to start containers without even needing a daemon running as root (although you'd lose some functionality due to deficiencies in some of the kernel interactions with user namespaces -- but it should be more secure than it is now). It does bother me that the Linux kernel community entirely ignored other container implementations.
  - tyingq 10y ago
    Yes, I've been following the progress, and I see the disconnects across the space. Like this issue: https://github.com/systemd/systemd/issues/321 https://github.com/systemd/systemd/issues/321 Appreciate your efforts. It is good to know that there are people pushing to get this working.
    - cyphar 10y ago
      If you're interested, I've got a WIP branch of runC that actually implements working rootless containers. This is really exciting. I'll be writing a blog post soon. https://github.com/opencontainers/runc/pull/774 https://github.com/opencontainers/runc/pull/774
molecule 10y ago
@ 100+ pages, it would be great to get this in mobi or epub format.
X86BSD 10y ago
Obviously the author put a lot of effort into this paper. Hard work shows throughout. Kudos to you sir! Granted I realize the title is "Understanding and Hardening Linux Containers". However, personally, this just illustrates my frustration and the frustration of others with the Linux world. They exist in their own little echo chamber. Linux was not the first to create "containers" that are secure. There is no inclusion of other solutions outside Linux. The reason other solutions do not have these problems is because the authors actually thought about the problem. And if the Linux camp would simply look outside their echo chamber long enough to see how others solved these problems before them this paper might not have been written. It's just simply frustrating to watch Linux reinvent some wheels, poorly, time after time. Flame on!
- heroprotagonist 10y ago
  I see nothing wrong with this. I think it's good to be specific. The Linux implementation is different from many other containerization solutions (eg, Solaris Zones, AIX WPAR, HPUX partitions, etc, so forth). The scope of "all container solutions for every platform" is too broad to be able to provide much depth, and the audience of people interested in container information for all platforms instead of a specific platform is fairly narrow. There's plenty of room for someone to make a document specific to other platforms for a different audience. There's even room for someone to make a comparison of all platforms. It depends on your goal, your knowledge, and your intended audience.
  - X86BSD 10y ago
    It's not that the paper is wrong for only focusing on Linux "containers". It's that the paper, while describing the security short comings of the various solutions, illustrates the echo chamber I refer to. "We have these security issues, that others do not have, but we are not going to look at how they solved these issues because, well, Linux!" The paper, IMO, would have better served the audience had it included ideas and/or solutions people outside Linux-land developed to solve some of these issues that were written before Linux even attempted a "container". You are free to disagree.
kazinator 10y ago
Harden this container! http://regex.info/i/pic/2005-09-06_16:03.28__00002.jpg http://regex.info/i/pic/2005-09-06_16:03.28__00002.jpg Ideas: Cross-linked polymer? Switch to glass? Too heavy. Carbon fiber, epoxy resin composite?
- peterwwillis 10y ago
  A unix hacker would wrap it tightly in plastic wrap. Once you're done with the application you can re-use the wrapper.
  - kazinator 10y ago
    I'm with you: plus the plastic wrap is a small self-contained tool that sort of does one job half-well.
tptacek 10y ago
Exposing /dev/random in containers does not put the system entropy pool at risk. That claim is repeated twice in the paper, and is false.
- mfukar 10y ago
  It will never stop being repeated, will it?
- josh-wrale 10y ago
  Could you link to supporting reference? Is there some smarts in the kernel to namespace, block or limit draining?
  - throwaway2048 10y ago
    "Draining" is a fantasy, statistics about it are manufactured by the kernel randomness subsystems. Are you concerned with your ssh keys "running out" too?
    - raesene6 10y ago
      excuse my potential ignorance, but I thought that /dev/random was at risk of exhaustion in the general case, with /dev/urandom not being so... e.g. http://www.onkarjoshi.com/blog/191/device-dev-random-vs-urandom/ http://www.onkarjoshi.com/blog/191/device-dev-random-vs-uran... or http://security.stackexchange.com/a/14293/37 http://security.stackexchange.com/a/14293/37
      - cyphar 10y ago
        I got schooled about this a few days ago. Here's the thread: https://news.ycombinator.com/item?id=11485832 https://news.ycombinator.com/item?id=11485832. The tl;dr is that basically you should just use /dev/urandom unless you're in very weird circumstances. Entropy doesn't "run out" in that sense.
        10y ago
fpoling 10y ago
The article contains the best explanation of Linux capabilities that I have seen. Too bad that Docker and other container solutions defaults to rather broad set of capabilities requiring to use things like --cap-drop=ALL --cap-add=NET_BIND_SERVICE ... with typical container invocations to minimize a chance of container escape.
nicolast 10y ago
> and a number of other systems such as Mirage OS (a reimplementation of Solaris Zones). I'd say that's not entirely correct. At all.
- amirmc 10y ago
  Yeah, there are a number of statements about unikernels that are ... somewhat inaccurate.
  - dyn 10y ago
    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.
- floatboth 10y ago
  Also: > Joanna is also a core contributor and author of the high security Xen hypervisor desktop "CubesOS". it's Qubes, not Cubes. Spelled correctly right in the URL the paper link to.
  - dyn 10y ago
    Author here. Oops, will fix, thanks.
- dyn 10y ago
  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.
stcredzero 10y ago
Has there been a writeup of the history of Container technology? How did these features find their way into the Linux kernel in the first place? What was the original motivation? (Sandboxing, I would guess.) Who were the stakeholders who pushed those features, and why? It's weird and wonderful that such technology infrastructure arose and such innovation happens. I'm curious how.

196 points by secalex 10y ago

xori 10y ago

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

somethingnew 10y 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 10y 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 10y 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 10y 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 10y 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.
mikecb 10y ago
There's TL;drs at the end of some sections.
fabulist 10y ago
This is not a sound security strategy.
otterley 10y 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 10y 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 10y 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 10y 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 10y 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 10y 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 10y 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 10y ago
      I'd like this too. An .epub would be nice for e-ink readers like Pocketbook, Kobo, and Kindle.
  - voidz 10y ago
    Is it possible to get notified (via email) when this paper has been updated?
  - Annatar 10y 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.

ishtu 10y ago

"Containers are great. It's a shame Linux doesn't have any."

geggam 10y ago

This..... this is the thing every architect attempting to roll containers out to production needs to read and re read Complexity at scale: Orchestration frameworks (Rancher, MESOS/Aurora, Docker Swarm, LXD, OpenStack Containers, Kubernetes/Borg, etc) are only recently catching up to the container craze, there are too many competing models to list. Many have questionable or unaudited security or leave major requirements out, such as secret management. While containers may be easy to get working within a workstation or a few servers, scaling them up to production deployment is another challenge altogether, even assuming your application stack can be properly ``containerized''

dmpk2k 10y ago
My experience with Joyent's Triton stack has been both simple and positive. Much of the stuff in Section 10 either doesn't apply to the Triton stack (e.g. their implementation of the Docker server doesn't leave sockets lying around), or has already been solved there (e.g. their container implementation has already been hardened over a decade, and actually works well). I'm obviously quite the fan. This document is more an indictment of the current state of the Linux container ecosystem, rather than containers themselves. Don't conflate the two.
- geggam 10y ago
  Reading more and more of the document ... you might change your mind if you do so :)
  - dmpk2k 10y ago
    Yes, that's true. I was being a bit unfair.
kyrra 10y ago
The opinions stated here are my own, not necessarily those of Google. From my understanding Google was one of the main contributors of the core features that have allowed containers on Linux. Specifically cgroups and LXC. And they have have been running containers for 10 years: https://research.google.com/pubs/pub43438.html https://research.google.com/pubs/pub43438.html I'm not sure what you consider new, but it's definitely not super new to Google. I'm guessing your issue is that it's fairly new to being used in production across many companies, so security researchers are just starting to work on finding holes in it.

tyingq 10y ago

"While Linux Container systems (LXC, Docker, CoreOS Rocket, etc) have undergone fast deployment and development, security knowledge has lagged behind. The number of people focused on container security...seems disproportionately small" I agree with this part. Most containers aren't running as an unprivileged user. Those environments that do support it only support it in a very limited set of os/kernel/whatever versions. Somewhat concerning since containers are getting traction almost everywhere.

cyphar 10y ago
Oddly enough, quite a few people in the runC community (including myself) are working on implementing the ability to start containers without root. If we can get this to work, it will be brought to Docker and you'll be able to start containers without even needing a daemon running as root (although you'd lose some functionality due to deficiencies in some of the kernel interactions with user namespaces -- but it should be more secure than it is now). It does bother me that the Linux kernel community entirely ignored other container implementations.
- tyingq 10y ago
  Yes, I've been following the progress, and I see the disconnects across the space. Like this issue: https://github.com/systemd/systemd/issues/321 https://github.com/systemd/systemd/issues/321 Appreciate your efforts. It is good to know that there are people pushing to get this working.
  - cyphar 10y ago
    If you're interested, I've got a WIP branch of runC that actually implements working rootless containers. This is really exciting. I'll be writing a blog post soon. https://github.com/opencontainers/runc/pull/774 https://github.com/opencontainers/runc/pull/774

molecule 10y ago

@ 100+ pages, it would be great to get this in mobi or epub format.

X86BSD 10y ago

Obviously the author put a lot of effort into this paper. Hard work shows throughout. Kudos to you sir! Granted I realize the title is "Understanding and Hardening Linux Containers". However, personally, this just illustrates my frustration and the frustration of others with the Linux world. They exist in their own little echo chamber. Linux was not the first to create "containers" that are secure. There is no inclusion of other solutions outside Linux. The reason other solutions do not have these problems is because the authors actually thought about the problem. And if the Linux camp would simply look outside their echo chamber long enough to see how others solved these problems before them this paper might not have been written. It's just simply frustrating to watch Linux reinvent some wheels, poorly, time after time. Flame on!

heroprotagonist 10y ago
I see nothing wrong with this. I think it's good to be specific. The Linux implementation is different from many other containerization solutions (eg, Solaris Zones, AIX WPAR, HPUX partitions, etc, so forth). The scope of "all container solutions for every platform" is too broad to be able to provide much depth, and the audience of people interested in container information for all platforms instead of a specific platform is fairly narrow. There's plenty of room for someone to make a document specific to other platforms for a different audience. There's even room for someone to make a comparison of all platforms. It depends on your goal, your knowledge, and your intended audience.
- X86BSD 10y ago
  It's not that the paper is wrong for only focusing on Linux "containers". It's that the paper, while describing the security short comings of the various solutions, illustrates the echo chamber I refer to. "We have these security issues, that others do not have, but we are not going to look at how they solved these issues because, well, Linux!" The paper, IMO, would have better served the audience had it included ideas and/or solutions people outside Linux-land developed to solve some of these issues that were written before Linux even attempted a "container". You are free to disagree.

kazinator 10y ago

Harden this container! http://regex.info/i/pic/2005-09-06_16:03.28__00002.jpg http://regex.info/i/pic/2005-09-06_16:03.28__00002.jpg Ideas: Cross-linked polymer? Switch to glass? Too heavy. Carbon fiber, epoxy resin composite?

peterwwillis 10y ago
A unix hacker would wrap it tightly in plastic wrap. Once you're done with the application you can re-use the wrapper.
- kazinator 10y ago
  I'm with you: plus the plastic wrap is a small self-contained tool that sort of does one job half-well.

tptacek 10y ago

Exposing /dev/random in containers does not put the system entropy pool at risk. That claim is repeated twice in the paper, and is false.

mfukar 10y ago
It will never stop being repeated, will it?
josh-wrale 10y ago
Could you link to supporting reference? Is there some smarts in the kernel to namespace, block or limit draining?
- throwaway2048 10y ago
  "Draining" is a fantasy, statistics about it are manufactured by the kernel randomness subsystems. Are you concerned with your ssh keys "running out" too?
  - raesene6 10y ago
    excuse my potential ignorance, but I thought that /dev/random was at risk of exhaustion in the general case, with /dev/urandom not being so... e.g. http://www.onkarjoshi.com/blog/191/device-dev-random-vs-urandom/ http://www.onkarjoshi.com/blog/191/device-dev-random-vs-uran... or http://security.stackexchange.com/a/14293/37 http://security.stackexchange.com/a/14293/37
    - cyphar 10y ago
      I got schooled about this a few days ago. Here's the thread: https://news.ycombinator.com/item?id=11485832 https://news.ycombinator.com/item?id=11485832. The tl;dr is that basically you should just use /dev/urandom unless you're in very weird circumstances. Entropy doesn't "run out" in that sense.
      - 10y ago

fpoling 10y ago

The article contains the best explanation of Linux capabilities that I have seen. Too bad that Docker and other container solutions defaults to rather broad set of capabilities requiring to use things like --cap-drop=ALL --cap-add=NET_BIND_SERVICE ... with typical container invocations to minimize a chance of container escape.

nicolast 10y ago

> and a number of other systems such as Mirage OS (a reimplementation of Solaris Zones). I'd say that's not entirely correct. At all.

amirmc 10y ago
Yeah, there are a number of statements about unikernels that are ... somewhat inaccurate.
- dyn 10y ago
  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.
floatboth 10y ago
Also: > Joanna is also a core contributor and author of the high security Xen hypervisor desktop "CubesOS". it's Qubes, not Cubes. Spelled correctly right in the URL the paper link to.
- dyn 10y ago
  Author here. Oops, will fix, thanks.
dyn 10y ago
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.

stcredzero 10y ago

Has there been a writeup of the history of Container technology? How did these features find their way into the Linux kernel in the first place? What was the original motivation? (Sandboxing, I would guess.) Who were the stakeholders who pushed those features, and why? It's weird and wonderful that such technology infrastructure arose and such innovation happens. I'm curious how.