10 ms·

Docker container breakout?

317 points by eugeneionesco 12y ago

notacoward 12y ago
Just to be clear, this doesn't really seem like a problem with Docker specifically. It looks like a problem with the kernel's namespace isolation, affecting any container-based solution. Yes, that's in the PPS, but probably should be in the title.
- kapilvt 12y ago
  that's true to some extent, but it also has to do with which namespaces and isolation features a given container solution supports, for example lxc has seccomp syscall filtering support and user namespace support ootb which would have mitigated this attack surface to those of the unprivileged user running the container (and covering the ps on kexec). in addition lsm usage (selinux, apparmor) can also limit the attack surface area.
xeroxmalf 12y ago
"tested with docker 0.11" Looks to be a few releases out past 0.11, notably 0.11.1, 0.12, and now 1.0. Can anyone confirm this works on the later versions of docker?
- ewindisch 12y ago
  The kernel version is just as important, if not more important. I've performed tests that have given me non-specific breakout capabilities on certain combinations of Linux and Docker. I haven't however, as is done here, reproduced and written an exploit. As an employee of Docker, I feel it is more important to me to know if we can breakout and patch those issues than to write viable exploits for them. I have noticed that newer kernels and Docker versions (such as 1.0) are currently more difficult to break out of than they were in earlier versions. Again, however, it's highly dependent on the pairing. What's important to recognize here is that even with breakout potential, containers should add a useful layer of security to break out of that wouldn't otherwise exist. Containers should never remove security from your system, they should only add to it. However, although deployers may find the removal of virtual machines to weaken their security story. The "secure all the things" story would be to put Qemu in a container, then run containers inside the VM. Otherwise, security practices are as they always have been: Don't leave setuid binaries floating around, etc.
jhardcastle 12y ago
With a technology used in production in a lot of places, does responsible disclosure apply here? Did the author (OP?) notify Docker and/or the Linux kernel team before distributing this for public consumption?
- BillinghamJ 12y ago
  A fix has been released already - Docker 1.0. Thus, it shouldn't really be an issue.
- zorked 12y ago
  While the author called the exploit "shocker" I don't think anybody is shocked by it. There are likely many other ways to break out of Docker. And while I assume the Docker (and kernel!) people are closing them as they come along, I don't think anyone is claiming Docker is unescapable so it's not a surprise if it is.
  - zobzu 12y ago
    I think he might have been sarcastic
- nickstinemates 12y ago
  See: http://www.docker.com/resources/security/ http://www.docker.com/resources/security/ It has been used effectively in the past! I'd encourage anyone who is researching security and Docker to send new information here. Thanks!
bastichelaar 12y ago
Apparently this is already fixed in Docker 1.0: Its fixed in docker 1.0 since CAP_DAC_READ_SEARCH is no longer available. Other FS-related threats to container based VMM's that have been discussed: - subvolume related FS operations (snapshots etc) - FS ioctl's that accept FS-handles as well (XFS) - CAP_DAC_READ_SEARCH also defeats chroot and other bind-mount containers (privileged LXC) - CAP_MKNOD might be a problem too (still available in docker 1.0) depending on the drivers available in the kernel Source: http://seclists.org/oss-sec/2014/q2/565 http://seclists.org/oss-sec/2014/q2/565
- kvmosx 12y ago
  Confirmed not working in Docker 1.0: root@377a6f4ab0a4:/# history 10 wget http://stealth.openwall.net/xSports/shocker.c 11 cc -Wall -std=c99 -O2 shocker.c -static 12 apt-get install build-essential 13 cc -Wall -std=c99 -O2 shocker.c -static 14 cc -Wall -std=c99 -O2 shocker.c -static -Wno-unused-result 15 ls 16 ./shocker 17 shocker 18 nano a.out 19 cat a.out 20 ./a.out 21 history root@377a6f4ab0a4:/# ./a.out [***] docker VMM-container breakout Po(C) 2014 [***] [***] The tea from the 90's kicks your sekurity again. [***] [***] If you have pending sec consulting, I'll happily [***] [***] forward to my friends who drink secury-tea too! [***] <enter> [*] Resolving 'etc/shadow' [-] open_by_handle_at: Operation not permitted root@377a6f4ab0a4:/# uname -r 3.14.1-tinycore64
valarauca1 12y ago
I believe it was Theo de Raadt who once said, "Why does everything think that when it comes to writing VM/container software suddenly people gain super human programming powers and no longer make the same mistakes they make writing operating systems?" (Slightly paraphrasing). While the issue is currently fixed in the .12 and 1.0 versions. I doubt Docker is still completely bullet proof.
- xmlninja 12y ago
  No software is ever gonna be bullet proof.
  - logicallee 12y ago
    Except the software running a tank.
    - valarauca1 12y ago
      I write software that runs on tanks, its not bullet proof. Most the communication protocols just use security though obscurity. If you tell a gear box to shift form 1st to snip it'll do it, and break everything. But when you considered air gap, and physical security surrounding it (12 inches of plate steal, 5 man team with guns, massive main gun), its pretty secure.
      - clhodapp 12y ago
        I think it was a joke... You can fire bullets at the tank and the stuff inside is fine.
        valarauca1 12y ago
        It is, but vehicles including tanks and other armored things use horribly insecure serial protocols for communication. Which is no joke :\
        al2o3cr 12y ago
shykes 12y ago
Hi all, I'm a maintainer of Docker. As others already indicated this doesn't work on 1.0. But it could have. Please remember that at this time, we don't claim Docker out-of-the-box is suitable for containing untrusted programs with root privileges. So if you're thinking "pfew, good thing we upgraded to 1.0 or we were toast", you need to change your underlying configuration now. Add apparmor or selinux containment, map trust groups to separate machines, or ideally don't grant root access to the application. Docker will soon support user namespaces, which is a great additional security layer but also not a silver bullet! When we feel comfortable saying that Docker out-of-the-box can safely contain untrusted uid0 programs, we will say so clearly.
- bfirsh 12y ago
  For more details: https://docs.docker.com/articles/security/ https://docs.docker.com/articles/security/
- api 12y ago
  Don't worry. This is how things get more secure. Just stay the course and whack the moles. :) Docker is awesome by the way.
  - SixSigma 12y ago
    It is better to think "less insecure" than "more secure".
    - deleted 12y ago
      [deleted]
  - ewindisch 12y ago
    Speaking of whack a mole, last month I built a docker image for the Trinity syscall fuzzer. It's a great way of finding those moles, for anyone interested in contributing to either Docker or the kernel: https://registry.hub.docker.com/u/ewindisch/trinity/ https://registry.hub.docker.com/u/ewindisch/trinity/
- 12y ago
gabrtv 12y ago
Docker image to test if your host is vulnerable to this particular open_by_handle_at() container breakout: https://registry.hub.docker.com/u/gabrtv/shocker/ https://registry.hub.docker.com/u/gabrtv/shocker/ Remember to always audit the source code before running something like this. Origin repo is here: https://github.com/gabrtv/shocker https://github.com/gabrtv/shocker
jrockway 12y ago
> "The tea from the 90's kicks your sekurity again. If you have pending sec consulting, I'll happily forward to my friends who drink secury-tea too!" Uh, what?
- eugeneionesco 12y ago
  stealth is a legend of the '90s http://en.wikipedia.org/wiki/TESO http://en.wikipedia.org/wiki/TESO
  - contingencies 12y ago
    Never really got talking but they sent me some friendly warez when I released an ARP-based remote OS detection script in like 1999. As I recall they were all Germanic. Doubt there's any 'reach out' from groups today, too much profit/loss going on...
hapless 12y ago
Here is your annual reminder: Use SELinux. Nothing with a shared kernel is going to be very secure. That's just the nature of the beast. It's why Docker supports SELinux. It's why RHEL and CentOS ship with pre-written SELinux policy for common daemons. If you intend to have more than zero services on the system, you want SELinux.
- rwmj 12y ago
  Or real virtualization + SELinux + sVirt ... libvirt on RHEL/Fedora/CentOS puts the qemu process into a container too.
  - fleitz 12y ago
    For security yes, however, for performance / resource requirements docker is going to beat libvirt/qemu.
    - rwmj 12y ago
      Or for running anything other than Linux on the exact same kernel. Running Windows, for example, or older copies of Linux.
    - edwintorok 12y ago
      I think of docker as a "nicer chroot", i.e. it might be nice for testing deployment of networked applications with lots of servers, where setting up a new VM for each one would be both slow and an overkill. Is running something inside docker worse than running the same application on the host from a security pov? If not then you can consider docker just as one way of deploying an application on the host, i.e. not something for shared hosting of independent/possibly malicious applications.
      - rwmj 12y ago
        In addition, we have repeatedly hit problems with our "mock" build system which uses a different kernel from what userland software is normally tested with. eg: [1] [2]. This stuff is going to hit Docker users sooner or later. It is also infuriatingly hard to debug. [1] http://bugzilla.redhat.com/1062533 http://bugzilla.redhat.com/1062533 [2] https://bugzilla.redhat.com/563103#c8 https://bugzilla.redhat.com/563103#c8
gtjay 12y ago
This vulnerability is a good example of how a security bug is still a bug. That is: even if all the bad guys went away there would still be problems. This issue was fixed (as far as I can tell) pre-1.0 for non-security reasons. See this discussion: https://github.com/dotcloud/docker/issues/5661 https://github.com/dotcloud/docker/issues/5661 . Basically, docker used to have a "drop" list associated with each execdriver. By default docker kept all kernel bestowed capabilities but would explicitly drop those on the execdriver's drop list. This created issues with compatibility. If an image was prepared on a kernel that didn't have a particular capability at all and was suddenly run on one that was, weird hard to diagnose behavioral differences could emerge. So now docker drops everything by default and the execdrivers have a "keep" list. Also, there's now a check for the kernel defining a capability before trying to mess with it. There are---of course---still some issues. For example, docker drops everything then tries to add the capability back. That won't work for some capabilities because some can't be added back once they've been renounced. Still, the situation is an interesting example of how a security bug is still a bug and is likely to bite you in some way sooner or later. See also XSS flaws that limit valid inputs.
- contingencies 12y ago
  Yes. I pointed it for LXC originally, filing the bug with LXC on sourceforge and later re-filing on github. Nothing to do with docker. Finally, they implemented it. This is like multiple years of timeframe we're talking about. Later I pointed it out for docker. Just sayin'. There's a lot of us contributing here, and much of the work isn't under the docker banner.
  - gtjay 12y ago
    "There's a lot of us contributing here, and much of the work isn't under the docker banner." Of course! If my comment could be taken as part of the mass of prose that can be read to imply otherwise, I apologize. I don't want to undermine what Docker has done with providing a packaging format, UX, and history niceness. I also don't want to undermine the years of hard work that's gone into kernel namespacing etc. that makes it all possible.
peterwwillis 12y ago
Linux capabilities are not a good security model in general. They're more suitable for sysadmins who want to do the very basic locking down of system resources to prevent users from fucking things up, or preventing programs from doing basic accidental mistakes. A MAC or RBAC implementation is a lot more robust and actually fulfills the qualifications for things like secret/top secret computing systems.
- contingencies 12y ago
  grsec + containers is nicer.
  - peterwwillis 12y ago
    From what I recall, grsec's rbac doesn't give you the same flexibility as selinux's mac. You have to pick and choose whether you want advanced heuristics to prevent different kinds of attack, or just get really fine-grained with your system control. I prefer grsec personally, but only because i'm lazy, and it's more than likely not certified for top secret systems.
    - contingencies 12y ago
      grsec's developer philosophy fully admits this pragmatic focus... basically, if we are too lazy to use a custom policy because policy development is painful, then essentially we are not going to use any policy and will instead remain vulnerable. grsec makes it easier, therefore it actually gets used. I studied SEL policies in depth back in 2000 or so, but have never once deployed a custom policy. I suspect others are the same, though common daemons on common distributions recently (~last 5 years) began to have usable pre-supplied policies, unfortunately standard services are so commodified these days they're often outsourced (email, chat, web, etc.) and so the benefits of this 'too-little-too-late' development are partly mitigated in practice.
mkent 12y ago
Confirmed this works on lxc 0.7.5-3ubuntu69 (ships with Ubuntu 12.04 lts). Just change "/.dockerinit" to any file within a bind mount and run it. To fix this you can shutdown the container, edit the config in /var/lib/lxc/<name>/config and add dac_read_search to lxc.cap.drop. Voila. [*] Resolving 'etc/shadow' [-] open_by_handle_at: Operation not permitted
throwaway9995 12y ago
Relevant recent discussion on the security of containers vs full virtualization: https://news.ycombinator.com/item?id=7834338 https://news.ycombinator.com/item?id=7834338
floatboth 12y ago
Now try breaking out of a FreeBSD jail ;-)
- nisa 12y ago
  like this? http://freebsd.1045724.n5.nabble.com/Thoughts-on-jail-privilege-FAQ-submission-td4219099.html http://freebsd.1045724.n5.nabble.com/Thoughts-on-jail-privil...
  - profquail 12y ago
    That's dated Jan 15, 2009. Are there any newer exploits for breaking out of jails on recent versions of FreeBSD? OR breaking out of a Bhyve VM?
    - floatboth 12y ago
      And that's not even an exploit, that's the sysadmin doing it wrong: "If the host system and the jail share the `john' user and you are sharing `/usr/local' as read-write between the host and the jail, then ``you are doing it wrong!''."
julien421 12y ago
Docker's answer http://blog.docker.com/2014/06/docker-container-breakout-proof-of-concept-exploit/ http://blog.docker.com/2014/06/docker-container-breakout-pro...

317 points by eugeneionesco 12y ago

Just to be clear, this doesn't really seem like a problem with Docker specifically. It looks like a problem with the kernel's namespace isolation, affecting any container-based solution. Yes, that's in the PPS, but probably should be in the title.

kapilvt 12y ago
that's true to some extent, but it also has to do with which namespaces and isolation features a given container solution supports, for example lxc has seccomp syscall filtering support and user namespace support ootb which would have mitigated this attack surface to those of the unprivileged user running the container (and covering the ps on kexec). in addition lsm usage (selinux, apparmor) can also limit the attack surface area.

xeroxmalf 12y ago

"tested with docker 0.11" Looks to be a few releases out past 0.11, notably 0.11.1, 0.12, and now 1.0. Can anyone confirm this works on the later versions of docker?

ewindisch 12y ago
The kernel version is just as important, if not more important. I've performed tests that have given me non-specific breakout capabilities on certain combinations of Linux and Docker. I haven't however, as is done here, reproduced and written an exploit. As an employee of Docker, I feel it is more important to me to know if we can breakout and patch those issues than to write viable exploits for them. I have noticed that newer kernels and Docker versions (such as 1.0) are currently more difficult to break out of than they were in earlier versions. Again, however, it's highly dependent on the pairing. What's important to recognize here is that even with breakout potential, containers should add a useful layer of security to break out of that wouldn't otherwise exist. Containers should never remove security from your system, they should only add to it. However, although deployers may find the removal of virtual machines to weaken their security story. The "secure all the things" story would be to put Qemu in a container, then run containers inside the VM. Otherwise, security practices are as they always have been: Don't leave setuid binaries floating around, etc.

jhardcastle 12y ago

With a technology used in production in a lot of places, does responsible disclosure apply here? Did the author (OP?) notify Docker and/or the Linux kernel team before distributing this for public consumption?

BillinghamJ 12y ago
A fix has been released already - Docker 1.0. Thus, it shouldn't really be an issue.
zorked 12y ago
While the author called the exploit "shocker" I don't think anybody is shocked by it. There are likely many other ways to break out of Docker. And while I assume the Docker (and kernel!) people are closing them as they come along, I don't think anyone is claiming Docker is unescapable so it's not a surprise if it is.
- zobzu 12y ago
  I think he might have been sarcastic
nickstinemates 12y ago
See: http://www.docker.com/resources/security/ http://www.docker.com/resources/security/ It has been used effectively in the past! I'd encourage anyone who is researching security and Docker to send new information here. Thanks!

bastichelaar 12y ago

Apparently this is already fixed in Docker 1.0: Its fixed in docker 1.0 since CAP_DAC_READ_SEARCH is no longer available. Other FS-related threats to container based VMM's that have been discussed: - subvolume related FS operations (snapshots etc) - FS ioctl's that accept FS-handles as well (XFS) - CAP_DAC_READ_SEARCH also defeats chroot and other bind-mount containers (privileged LXC) - CAP_MKNOD might be a problem too (still available in docker 1.0) depending on the drivers available in the kernel Source: http://seclists.org/oss-sec/2014/q2/565 http://seclists.org/oss-sec/2014/q2/565

kvmosx 12y ago
Confirmed not working in Docker 1.0: root@377a6f4ab0a4:/# history 10 wget http://stealth.openwall.net/xSports/shocker.c 11 cc -Wall -std=c99 -O2 shocker.c -static 12 apt-get install build-essential 13 cc -Wall -std=c99 -O2 shocker.c -static 14 cc -Wall -std=c99 -O2 shocker.c -static -Wno-unused-result 15 ls 16 ./shocker 17 shocker 18 nano a.out 19 cat a.out 20 ./a.out 21 history root@377a6f4ab0a4:/# ./a.out [***] docker VMM-container breakout Po(C) 2014 [***] [***] The tea from the 90's kicks your sekurity again. [***] [***] If you have pending sec consulting, I'll happily [***] [***] forward to my friends who drink secury-tea too! [***] <enter> [*] Resolving 'etc/shadow' [-] open_by_handle_at: Operation not permitted root@377a6f4ab0a4:/# uname -r 3.14.1-tinycore64

valarauca1 12y ago

I believe it was Theo de Raadt who once said, "Why does everything think that when it comes to writing VM/container software suddenly people gain super human programming powers and no longer make the same mistakes they make writing operating systems?" (Slightly paraphrasing). While the issue is currently fixed in the .12 and 1.0 versions. I doubt Docker is still completely bullet proof.

xmlninja 12y ago
No software is ever gonna be bullet proof.
- logicallee 12y ago
  Except the software running a tank.
  - valarauca1 12y ago
    I write software that runs on tanks, its not bullet proof. Most the communication protocols just use security though obscurity. If you tell a gear box to shift form 1st to snip it'll do it, and break everything. But when you considered air gap, and physical security surrounding it (12 inches of plate steal, 5 man team with guns, massive main gun), its pretty secure.
    - clhodapp 12y ago
      I think it was a joke... You can fire bullets at the tank and the stuff inside is fine.
      - valarauca1 12y ago
        It is, but vehicles including tanks and other armored things use horribly insecure serial protocols for communication. Which is no joke :\
      - al2o3cr 12y ago

shykes 12y ago

Hi all, I'm a maintainer of Docker. As others already indicated this doesn't work on 1.0. But it could have. Please remember that at this time, we don't claim Docker out-of-the-box is suitable for containing untrusted programs with root privileges. So if you're thinking "pfew, good thing we upgraded to 1.0 or we were toast", you need to change your underlying configuration now. Add apparmor or selinux containment, map trust groups to separate machines, or ideally don't grant root access to the application. Docker will soon support user namespaces, which is a great additional security layer but also not a silver bullet! When we feel comfortable saying that Docker out-of-the-box can safely contain untrusted uid0 programs, we will say so clearly.

bfirsh 12y ago
For more details: https://docs.docker.com/articles/security/ https://docs.docker.com/articles/security/
api 12y ago
Don't worry. This is how things get more secure. Just stay the course and whack the moles. :) Docker is awesome by the way.
- SixSigma 12y ago
  It is better to think "less insecure" than "more secure".
  - deleted 12y ago
    [deleted]
- ewindisch 12y ago
  Speaking of whack a mole, last month I built a docker image for the Trinity syscall fuzzer. It's a great way of finding those moles, for anyone interested in contributing to either Docker or the kernel: https://registry.hub.docker.com/u/ewindisch/trinity/ https://registry.hub.docker.com/u/ewindisch/trinity/
12y ago

gabrtv 12y ago

Docker image to test if your host is vulnerable to this particular open_by_handle_at() container breakout: https://registry.hub.docker.com/u/gabrtv/shocker/ https://registry.hub.docker.com/u/gabrtv/shocker/ Remember to always audit the source code before running something like this. Origin repo is here: https://github.com/gabrtv/shocker https://github.com/gabrtv/shocker

jrockway 12y ago

> "The tea from the 90's kicks your sekurity again. If you have pending sec consulting, I'll happily forward to my friends who drink secury-tea too!" Uh, what?

eugeneionesco 12y ago
stealth is a legend of the '90s http://en.wikipedia.org/wiki/TESO http://en.wikipedia.org/wiki/TESO
- contingencies 12y ago
  Never really got talking but they sent me some friendly warez when I released an ARP-based remote OS detection script in like 1999. As I recall they were all Germanic. Doubt there's any 'reach out' from groups today, too much profit/loss going on...

hapless 12y ago

Here is your annual reminder: Use SELinux. Nothing with a shared kernel is going to be very secure. That's just the nature of the beast. It's why Docker supports SELinux. It's why RHEL and CentOS ship with pre-written SELinux policy for common daemons. If you intend to have more than zero services on the system, you want SELinux.

rwmj 12y ago
Or real virtualization + SELinux + sVirt ... libvirt on RHEL/Fedora/CentOS puts the qemu process into a container too.
- fleitz 12y ago
  For security yes, however, for performance / resource requirements docker is going to beat libvirt/qemu.
  - rwmj 12y ago
    Or for running anything other than Linux on the exact same kernel. Running Windows, for example, or older copies of Linux.
  - edwintorok 12y ago
    I think of docker as a "nicer chroot", i.e. it might be nice for testing deployment of networked applications with lots of servers, where setting up a new VM for each one would be both slow and an overkill. Is running something inside docker worse than running the same application on the host from a security pov? If not then you can consider docker just as one way of deploying an application on the host, i.e. not something for shared hosting of independent/possibly malicious applications.
    - rwmj 12y ago
      In addition, we have repeatedly hit problems with our "mock" build system which uses a different kernel from what userland software is normally tested with. eg: [1] [2]. This stuff is going to hit Docker users sooner or later. It is also infuriatingly hard to debug. [1] http://bugzilla.redhat.com/1062533 http://bugzilla.redhat.com/1062533 [2] https://bugzilla.redhat.com/563103#c8 https://bugzilla.redhat.com/563103#c8

gtjay 12y ago

This vulnerability is a good example of how a security bug is still a bug. That is: even if all the bad guys went away there would still be problems. This issue was fixed (as far as I can tell) pre-1.0 for non-security reasons. See this discussion: https://github.com/dotcloud/docker/issues/5661 https://github.com/dotcloud/docker/issues/5661 . Basically, docker used to have a "drop" list associated with each execdriver. By default docker kept all kernel bestowed capabilities but would explicitly drop those on the execdriver's drop list. This created issues with compatibility. If an image was prepared on a kernel that didn't have a particular capability at all and was suddenly run on one that was, weird hard to diagnose behavioral differences could emerge. So now docker drops everything by default and the execdrivers have a "keep" list. Also, there's now a check for the kernel defining a capability before trying to mess with it. There are---of course---still some issues. For example, docker drops everything then tries to add the capability back. That won't work for some capabilities because some can't be added back once they've been renounced. Still, the situation is an interesting example of how a security bug is still a bug and is likely to bite you in some way sooner or later. See also XSS flaws that limit valid inputs.

contingencies 12y ago
Yes. I pointed it for LXC originally, filing the bug with LXC on sourceforge and later re-filing on github. Nothing to do with docker. Finally, they implemented it. This is like multiple years of timeframe we're talking about. Later I pointed it out for docker. Just sayin'. There's a lot of us contributing here, and much of the work isn't under the docker banner.
- gtjay 12y ago
  "There's a lot of us contributing here, and much of the work isn't under the docker banner." Of course! If my comment could be taken as part of the mass of prose that can be read to imply otherwise, I apologize. I don't want to undermine what Docker has done with providing a packaging format, UX, and history niceness. I also don't want to undermine the years of hard work that's gone into kernel namespacing etc. that makes it all possible.

peterwwillis 12y ago

Linux capabilities are not a good security model in general. They're more suitable for sysadmins who want to do the very basic locking down of system resources to prevent users from fucking things up, or preventing programs from doing basic accidental mistakes. A MAC or RBAC implementation is a lot more robust and actually fulfills the qualifications for things like secret/top secret computing systems.

contingencies 12y ago
grsec + containers is nicer.
- peterwwillis 12y ago
  From what I recall, grsec's rbac doesn't give you the same flexibility as selinux's mac. You have to pick and choose whether you want advanced heuristics to prevent different kinds of attack, or just get really fine-grained with your system control. I prefer grsec personally, but only because i'm lazy, and it's more than likely not certified for top secret systems.
  - contingencies 12y ago
    grsec's developer philosophy fully admits this pragmatic focus... basically, if we are too lazy to use a custom policy because policy development is painful, then essentially we are not going to use any policy and will instead remain vulnerable. grsec makes it easier, therefore it actually gets used. I studied SEL policies in depth back in 2000 or so, but have never once deployed a custom policy. I suspect others are the same, though common daemons on common distributions recently (~last 5 years) began to have usable pre-supplied policies, unfortunately standard services are so commodified these days they're often outsourced (email, chat, web, etc.) and so the benefits of this 'too-little-too-late' development are partly mitigated in practice.

mkent 12y ago

Confirmed this works on lxc 0.7.5-3ubuntu69 (ships with Ubuntu 12.04 lts). Just change "/.dockerinit" to any file within a bind mount and run it. To fix this you can shutdown the container, edit the config in /var/lib/lxc/<name>/config and add dac_read_search to lxc.cap.drop. Voila. [*] Resolving 'etc/shadow' [-] open_by_handle_at: Operation not permitted

throwaway9995 12y ago

Relevant recent discussion on the security of containers vs full virtualization: https://news.ycombinator.com/item?id=7834338 https://news.ycombinator.com/item?id=7834338

floatboth 12y ago

Now try breaking out of a FreeBSD jail ;-)

nisa 12y ago
like this? http://freebsd.1045724.n5.nabble.com/Thoughts-on-jail-privilege-FAQ-submission-td4219099.html http://freebsd.1045724.n5.nabble.com/Thoughts-on-jail-privil...
- profquail 12y ago
  That's dated Jan 15, 2009. Are there any newer exploits for breaking out of jails on recent versions of FreeBSD? OR breaking out of a Bhyve VM?
  - floatboth 12y ago
    And that's not even an exploit, that's the sysadmin doing it wrong: "If the host system and the jail share the `john' user and you are sharing `/usr/local' as read-write between the host and the jail, then ``you are doing it wrong!''."

julien421 12y ago

Docker's answer http://blog.docker.com/2014/06/docker-container-breakout-proof-of-concept-exploit/ http://blog.docker.com/2014/06/docker-container-breakout-pro...