71–80 of 91 posts
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…
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.
Earlier quoted context omitted.
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?
so it probably isn't steel in large quantities just as good as 300mm of RHA
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…
also worth noting that you can still de-elavate the process in the container, discourse web runs under the discourse user in the container.
Earlier quoted context omitted.
Agreed. It's also a question of complexity. Xen (for example) has a significantly smaller attack surface than the linux kernel because it just has less stuff to do
That hasn't stopped Xen from having bugs that have allow an attacker to escape the domU and gain access to dom0 and the hardware. The key really is: "Don't rely on visualization for security".
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.
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.
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.
Earlier quoted context omitted.
grsec + containers is nicer.
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.
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.
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…
No virtualization developer is under the impression that it's magical or bulletproof.
You rely on the operating system's security mechanisms continuously, and developers work hard to fix bugs and vulnerabilities when they appear. Same goes for virtualization -- the security semantics are just different.