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.
Docker container breakout?
51–60 of 91 posts
Re: Docker container breakout?
#52Hi 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…
Re: Docker container breakout?
#53Earlier 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.
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?
#54Re: Docker container breakout?
#55I 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.
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?
#56Now try breaking out of a FreeBSD jail ;-)
Re: Docker container breakout?
#57Earlier 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…
Re: Docker container breakout?
#58Re: Docker container breakout?
#59Earlier 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.
Re: Docker container breakout?
#60This 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…