Bringing New Security Features To Docker 29
Czech37 writes SELinux lead Dan Walsh wrote last month that Docker "containers do not contain" and that the host system isn't completely protected. Today, Walsh details the steps that Docker, Red Hat, and the open source community are taking to make Docker more secure: "Basically, we want to put in as many security barriers to break out as possible. If a privileged process can break out of one containment tool, we want to block them with the next. With Docker, we are want to take advantage of as many security components of Linux as possible. If "Docker" isn't a familiar word, the project's website is informative; the very short version is that it's a Linux-based "open platform for developers and sysadmins to build, ship, and run distributed applications"; Wikipedia has a good explanation, too.
Re:Taken to the logical conclusion (Score:4, Informative)
Or something close to the BSD jail() command.
What would be close to ideal would be something like jail() except that the jailed program would get its own loopback filesystem. This way, if a malicious task does things like make a lot of files in effort to consume all free inodes or create a directory link so deep rm() can't unlink it, the damage just affects that partition, and nothing else. I've found malware that did that in Windows, so when I use sandboxes, they go to their own dedicated volume that can be easily reformatted.
Re:Watch (Score:5, Informative)
What irony? By walled garden they mean Apple's controlled ecosystem. Docker is open source and mainly meant to run open source. The standards are open, the working group is open...
Re:Watch (Score:4, Informative)
You can download Docker source code, compile it yourself, have your own image repository, and even copy just the dockerfiles to put big/complex installations under your supervision/control rebuiding/tuning them yourself
What docker does is provide a "walled garden" for applications from other people/companies running in your own servers/desktops, limiting what they can do with your system and data, like a lightweight VM. The focus of this article is how to impove the security of that "walled garden" even more.
Re:Taken to the logical conclusion (Score:5, Informative)
This is basically the approach that most container systems use. A scratch space is mounted on top of the various container objects that is a partition on LVM. Interacting with the file system will only impact your locally allocated space.
Docker may be like jail() in a way, but true linux cgroups/namespaces are far more powerful. For one, they can be set on individual processes (including threads). So you can create a thread which has a different view of the filesystem than say the main thread. Sure, the attack vector exists to share information between them but now you can basically make one more hop for an attacker. You can make threads which have no network access, or make a thread which has no access to the process list on a system.
So picture using this with a web browser. You can make that crappy module run in a process which has no network access, a root file system that is empty (/var/empty or some such) and can not see any of the other processes on the system. Its only access to the outside world is through a SOCKS proxy passed in as a file descriptor. Even better this can be done with minimal system calls and no setup from the end user so you don't need any of the real infrastructure that jails require. Just recently they added user namespaces as well so uid "0" in a namespace isn't uid 0 on the host OS.
I love that you can harden a web server by having all the threads accept a "resolver" thread have no network access, and have all the threads except a logging thread have no file system access (or limited file system access), while also limiting the resolver thread to say 50M of memory, the main processing thread to 80% CPU and 12G of memory, and the logging thread to 10% CPU and 10k file system operations per second.. etc.
The per thread aspect of the whole setup is way cool, but the zero administrative overhead for a large chunk of it is even cooler. =)