Bringing New Security Features To Docker

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.

Comments

Taken to the logical conclusion

[Chrisq]

"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.

Take this to the ultimate conclusion and you have just reinvented virtualisation.

Re:Taken to the logical conclusion

[mlts]

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:Taken to the logical conclusion

[jbolden]

Absolutely right and well said. Docker is about deploying tons of trusted containers on a server. It doesn't have a security layer. If you want fewer less secure containers you want virtualization.

Re:Taken to the logical conclusion

[Chrisq]

Absolutely right and well said. Docker is about deploying tons of trusted containers on a server. It doesn't have a security layer. If you want fewer less secure containers you want virtualization.

I think you meant "more secure"!

Re:Taken to the logical conclusion

[jbolden]

Yes you are right.

Re:Taken to the logical conclusion

[gmuslera]

The idea of containers is that full virtualization requires too much resources. Put your apps in its own filesystem/network/users/processes/memory/etc in an efficient way (adding cow/union fs to the mix is one of the big advantages of docker) and you are running at basically native speed, using very little extra disk (i.e. 2 vms running ubuntu have the full copy of ubuntu each, even deduplication don't match the saving you do with different containers sharing the same base), and memory (just one kernel loaded, the memory you use is just the app one). You just can do far more density of "virtualized" applications in real or virtualized hardware than using VMs.

But as they run under the same kernel, you can run only linux apps with it (with vms you can run windows or *BSD), and have a bigger exposure area in the kernel than VMs. Adding this new security features should lower the risk of exploiting containers to get access to the main machine. The other alternative is to run multiple containers in VMs to lower exposure while maximizing application density, a bit of what Google does. And the fact that you can run containers in VMs mean that you can run them on AWS, google app engine and other cloud services that give you essentially VMs instead of bare metal.

Another option is to move VMs to the container advantages zone, like creating microVMs to run single applications (like in OpenMirage)

Re:Taken to the logical conclusion

[Rich0]

Not necessarily. The point of containers is to do this stuff in the kernel so that your box doesn't have to run 10 kernels, with 10 sets of disk caches, and 10 sets of extra ram so that the OOM killer doesn't get triggered 3 times per day, etc. You can get rid of a lot of overhead with containers, and allow resource allocation to be much more dynamic.

However, the problem is that the security isn't 100% there. It is fine for hosting 10 of your own services in containers when you could otherwise safely run them all as traditional services on a single box. It is completely inadequate for something like VPS where you can't trust that nobody will be hacking into the rest of the box.

Re:Taken to the logical conclusion

[Liquid-Gecka]

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. =)

Re:Watch

[jbolden]

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:grsec

[mlts]

grsec, and AppArmor. SELinux is a very good system, but AppArmor is easier to understand and work with.

Going blue-sky, having the ability to turn on a trusted executable list similar to AIX would be nice. It doesn't have to be signed executables per se, but a way to have a manifest list of OK things to run.

whatever makes you happy

[tmbdev]

Docker is just a way of starting processes on top of a union file system, with some simple capabilities management. You can wrap whatever other security features you want around it. Frankly, SELinux wouldn't be my first choice, both because of where it comes from and because I don't like the way it works, but, hey, whatever floats your boat.

As far as SELinux and AppArmor are concerned, what I'd really like to see is being able to install Ubuntu without either package installed. Right now, I seem to be pretty much forced to install both, whether I want to or not.

Re:Watch

[gmuslera]

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:Watch

[Anonymous Coward]

A closed platform, walled garden or closed ecosystem[1][2] is a software system where the carrier or service provider has control over applications, content, and media, and restricts convenient access to non-approved applications or content. --Wikipedia definition of a Walled Garden

Please explain how this applies to Docker.

Re:jails and zones

[McKing]

When I was a sysadmin in our Unix team, I loved zones and championed them throughout our organization. In the span of a year, we migrated from scores of older, slower Sun systems into a blade chassis with 10 blades, each running Solaris 10 with up to two dozen zones each. Our big Oracle database used to run on a Sun E10000 system that was literally the size of full rack, and we moved it onto a zone on a T2 blade and gained a ton of performance. We even finally had a real DR solution, since the old solution was to manually mount the storage from the E10000 server onto a 280R that was 1/10th as powerful until we could get Sun out to fix the E10000. The new way was to setup SAN to SAN sync to our DR site, bring up the latest ZFS snapshot, and roll forward the transaction log.

Fast forward almost 10 years and Oracle has pretty much destroyed Solaris and priced themselves out of our data center. Even our most business-critical Oracle database is now running on RHEL now, and as soon as we finish migrating some production apps to RHEL VMs on Hyper-V, the Oracle hardware goes bye-bye. I have to manage some apps on RHEL and while I love working in Linux userspace again, I miss Solaris 10 for a lot of things. Stupid Oracle.