[geofft]

It's containerization between trustworthy apps; it's not security containerization. What it gets you is, if you have one application that's designed to run well on RHEL 5 with /usr/bin/python pointing to Python 2.4, and another one that's designed to run well on Debian testing with a manual /usr/bin/python symlink to Python 3, you can give both of them what they want. This has nothing to do with security.

If you want Docker + security isolation, I'm intrigued by Clear Containers, which is a lightweight KVM-based virtualization thing:

https://lists.clearlinux.org/pipermail/dev/2015-September/00...

https://lwn.net/Articles/644675/

[philips]

If you want to try out Clear Containers we merged it into the rkt container runtime a few weeks ago. And since rkt can run both docker and appc container images you can run any existing app container from this runtime. This blog posts details Clear Containers in rkt:

https://coreos.com/blog/rkt-0.8-with-new-vm-support/

[takeda]

> It's containerization between trustworthy apps; it's not security containerization.

Isn't that what a process is? The containers in Linux are based on Jails from FreeBSD and zones from Solaris. They are absolutely there for security.

Regarding the remaining part of your post, I understand what you are trying to show but python is a really bad example. You absolutely can have python 2 and 3 side by side, or even different minor versions. And with virtualenv or pyvenv (that came with 3.4) you can even have multiple installation of the sane version. If you add setuptools to your application you can easily generate single file package (I personally like wheel) the deployment is as simple as writing pip install myawesomeapp-1.0.py2.py3.whl it downloads all dependencies. There is not much that Docker would help, it only makes things more complex.

[geofft]

> Isn't that what a process is?

It's the level of isolation of a process, yes. Just as two processes can use their address spaces as they see fit without bothering each other, even loading different versions of the same library, under a Linux container, two applications can use their filesystem as they see fit without bothering each other, even using different versions of the same binary applications.

But the security isolation between two processes running as the same user account is extremely weak. While it's true that one process can't write to another one's memory directly, it's not a fundamental breach of the security policy if it can do so indirectly. There may be things to increase defense-in-depth (like Yama) but fundamentally if you're the same UID there is no security boundary. The same rule applies to containers.

> python is a really bad example

Yeah, agreed. I was just trying to come up with something quick. If your app works with v(irtual)env, by all means just use that and stop messing with containers. However, if you've got some large closed-source app with a portion in Python, and it expects /usr/bin/python to both work and be some exact version, you need to virtualize the filesystem.

[takeda]

> It's the level of isolation of a process, yes. Just as two processes can use their address spaces as they see fit without bothering each other, even loading different versions of the same library, under a Linux container, two applications can use their filesystem as they see fit without bothering each other, even using different versions of the same binary applications.

I'm sorry for disagreeing, but that's what chroot() or even chdir() supposed to do. It's not for security (process can fool it), but they do provide isolation assuming there are no malicious actors.

Containers were created to provide security, perfect example is FreeBSD Jail which precedes Solaris zones. It supposed to be secure version of chroot() which should not be escapable. It was successfully used in early 2000 before VMs to provide shared hosting.

> But the security isolation between two processes running as the same user account is extremely weak. While it's true that one process can't write to another one's memory directly, it's not a fundamental breach of the security policy if it can do so indirectly. There may be things to increase defense-in-depth (like Yama) but fundamentally if you're the same UID there is no security boundary. The same rule applies to containers.

Agreed, except the last sentence. With processes the isolation is weak because same UID represent the same user, if you use a different UID the isolation is enforced. The containers (assuming they are correctly set up) allow you to actually have two root accounts that can't interfere with each other.

> Yeah, agreed. I was just trying to come up with something quick. If your app works with v(irtual)env, by all means just use that and stop messing with containers. However, if you've got some large closed-source app with a portion in Python, and it expects /usr/bin/python to both work and be some exact version, you need to virtualize the filesystem.

Assuming these are not malicious, you can just do:

chroot /app1_root python myapp1.py chroot /app2_root python myapp2.py

And as long as they don't use any tricks to get out, they won't step on each others teas.

[geofft]

> The containers (assuming they are correctly set up) allow you to actually have two root accounts that can't interfere with each other.

To the best of my knowledge, Docker (the official implementation) does not do that. rkt does, as mentioned at the bottom of this blog post mentioned elsethread:

https://coreos.com/blog/rkt-0.8-with-new-vm-support/

(The Linux implementation of this is somewhat poor, in that you need to have a separate UID reserved in the global namespace, and you can only do 1:1 maps in containers. A nicer implementation would treat the user principal as a (container, UID) tuple. I recall that Linux tried that, but gave up for backwards-compatibility reasons.)

> chroot /app1_root python myapp1.py

Yeah, I think 80% of what Docker actually gets people in practice is a system for managing and running things in chroots. Containers also let you give them separate networking setups, track PIDs properly, and apply resource controls. But I've seen homegrown approximations that preceded Docker, based on stuff like schroot.

[rdtsc]

Pretty much. It is marketing multiple exiting open source Linux technologies (overlay file systems, namespacing for processes, network sockets, chroots) under a set of tools and bam! -- hundreds of millions of dollars in valuation.

[superuser2]

Well, more than that, it's packaging them into user-friendly tools and promoting the shit out of it.

Still Docker the company's core value proposition is a hosted registry, something many savvy corporations will never go for. Docker the product could probably do just fine if the company were to fold.

[LoSboccacc]

but the hosted registry is what your average distribution already provide under the form of packages.

and with everything moving to services, I see the utility of actually using components diminishing fast (well except for those providing those services)

but for everyone else, docker solves no actual problem that can't already be solved now.

[superuser2]

Writing a Dockerfile and typing "docker run whatever" is a hell of a lot easier than configuring a chroot and LXC container.

[azernik]

virtualenv only works if you want an isolated Python environment. What if you have two things that each want a set of .so libraries with incompatible versions, and one wants node.js? In theory this could be managed with something like NixOS, but containerization is the much more mature and flexible solution.

[takeda]

In that situation you can use LD_LIBRARY_PATH, that's what it is for.

But what you really want in that case is to link the application statically. If you don't want to have benefits of shared objects:

- smaller binary - memory savings (if multiple programs are using the same library, it is loaded once) - less files to patch to fix a security vulnerability

The share objects have these features but it comes at price of lower performance, so by putting all .so files into a single docker file instead of statically compiling your application you're getting worst out of both worlds.

[icebraining]

Loading .so files doesn't mean the language can be statically compiled.

[xorcist]

How is that a problem? That's bascially the same thing as installing a newer set of tools under your home directory, and using them for an application. This has been done since long before Linux.

(Containers are still good, for isolating concerns and management. Multiple versions of the same library is just not it.)

[LoSboccacc]

so it's basically a complete set of workaround for enabling people to live with brain-damaged applications?

and we are encouraging this now, instead of fixing the damned apps?

sheesh this makes me feel old.

[geofft]

Yeah, the UNIX-Haters(tm) view of Docker is something like, this is what you get when you give up on static linking, give up on a UNIX spec, and make the mistake of telling people that chroots exist. We could have avoided all of this, and normal application deployment would have just worked with all the benefits Docker gives.