Live data from Hacker News

Docker container breakout?

stealth.openwall.net

51–60 of 91 posts

Re: Docker container breakout?

#51
post #16
post #12

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, m…

Don't worry. This is how things get more secure. Just stay the course and whack the moles. :) Docker is awesome by the way.

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/

Re: Docker container breakout?

#52
post #12

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, m…

Solomon, as always, brilliant and to the point. Keep rocking!!

Re: Docker container breakout?

#53
post #32
post #25

Earlier quoted context omitted.

Or real virtualization + SELinux + sVirt ... libvirt on RHEL/Fedora/CentOS puts the qemu process into a container too.

For security yes, however, for performance / resource requirements docker is going to beat libvirt/qemu.

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.

Re: Docker container breakout?

#55

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.

His words where: "You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can't write operating systems or applications without security holes, can then turn around and suddenly write virtualization layers without security holes." (http://marc.info/?l=openbsd-misc&m=119318909016582)

It a wonderful quote by the way, I really like it and it mirrors my reservations regarding some peoples use of visualization.

Visualization is perfectly fine, for hardware utilization, ease of deployment and so on, just don't rely on it for additional security, because that's not what it's there for.

Re: Docker container breakout?

#57
post #32

Earlier quoted context omitted.

For security yes, however, for performance / resource requirements docker is going to beat libvirt/qemu.

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 so…

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

[2] https://bugzilla.redhat.com/563103#c8

Re: Docker container breakout?

#59

Earlier quoted context omitted.

Except the software running a tank.

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.

Modern tanks have steel armor plates that are 12 inches thick?

Re: Docker container breakout?

#60
post #23

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 . Basically, docker used to have a "drop" list associated with each execdriver. By default docker kept all kernel bestowed…

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.
Post reply on HN