5 ms·
Well, so far I have only heard a lot of FUD and nothing concrete. http://opensource.com/business/14/7/docker-security-selinux http://opensource.com/business/14
by general_failure 12y ago
Well, so far I have only heard a lot of FUD and nothing concrete.
http://opensource.com/business/14/7/docker-security-selinux http://opensource.com/business/14/7/docker-security-selinux seems to have some information. But to refuse the points there, on my system:
a) docker containers do not have a /dev/mem
b) /sys/fs is mounted read-only
c) /dev/sd* is not visible
And so on. What's the thing with cgroups? Can a container delete the host's cgroups? Can it overwrite it's own cgroup constraints?
Can you or someone tell me if there is something I can try out on my own to understand actual issues? I run my containers unprivileged (which is the default) if it matters.
Again, all I am asking is for some material to educate myself on what actually the flaws are. All I have seen are vague articles claiming it's insecure.
- ryan-c 12y agoYou should be assuming Docker is insecure until proven otherwise. Fully isolating a root user with a shared kernel is very difficult.
- mappu 12y agoOpenVZ is very widely deployed and manages to do this safely.
- SEJeff 12y agoReality disagrees with you good sir: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=openvz https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=openvz
- icebraining 12y agoThe first is not even an OpenVZ bug, and which of the others shows an exploit that breaks out of the VM?
- jchavannes 12y agoHow do you prove something is secure?
- SEJeff 12y agohttp://blog.docker.com/2014/06/docker-container-breakout-proof-of-concept-exploit/ http://blog.docker.com/2014/06/docker-container-breakout-pro... But nothing is stopping you from creating a binary and running it as root that perhaps mounts those filesystems, or sends ioctls / badness to the kernel. I'm just shooting from the hip here and might be wrong, but I'm almost certain devices aren't namespaced. If you were to mknod a block device with the right major / minor numbers as the host's sda/sdb/etc, what would stop you from mounting the host's root filesystem and making changes? Granted the "work around" is to drop the privileges of the containers as much as possible, use sVirt (via SELinux), drop as many capabilities as possible, don't run untrusted containers, etc. But this isn't a theoretical security problem, it is a real big attack surface. Edit: http://www.projectatomic.io/blog/2014/09/yet-another-reason-containers-don-t-contain-kernel-keyrings/ http://www.projectatomic.io/blog/2014/09/yet-another-reason-...
- general_failure 12y agoafaik, devices are namespaced already. http://lwn.net/Articles/564854/ http://lwn.net/Articles/564854/
- justincormack 12y agoNo, I dont think thats upstream.
- general_failure 12y agoFor a moment I thought John Cormack replied :) Thanks for the info.
- scintill76 12y agoWhen the creators themselves are saying they don't consider it secure, I don't think it's "FUD".
- general_failure 12y agoSorry, I didn't imply what Shykes said is FUD. I meant most of the articles out there about docker security have little to no information other than "breakout is possible".
- scintill76 12y agoThat quote from Shykes could be paraphrased "it's safest to assume breakout by uid0 is possible." I understand the academic/hacker interest in identifying the exact avenues for breakout, and why vague articles are disappointing. My point is, it's important everyone understand it's not to be considered secure, even if we can't/don't name the vulnerabilities off the top of our heads.
- general_failure 12y agoFair enough. I agree with you.