Docker Desktop: Your Desktop over ssh inside of a Docker container

Root on the container doesn't mean root on the host. Machine-level virtualization has received more scrutiny than LXC, so as of today, many people consider traditional VMs to be more secure. But KVM or Xen are not intrinsically more secure than LXC or OpenVZ. They all have their histories of exploits and privilege escalations.

One key thing is, that it makes sense to run containers without root privileges (greatly improving security), while it is much harder to realistically run a VM without root processes. As a result, it could be said that containers are much safer, because before even thinking about breaking out of the container, you have to work on a root exploit - on a system which, by essence, only runs the processes that you really need, and has a much smaller attack surface.

We're working on a more elaborated answer, to be included within Docker docs!

> You either have to trust Docker

...and everybody else on my network, with that method. Doing that I don't even get the chance to think "Hey wait a second, why was this only 50 bytes of shell script...".

The reason that you see outrage for this "method" is because it is born of laziness and far too reminiscent of more disturbing times in computer security.

> Because people who use command lines / open source software generally have better judgement about this sort of thing

Why do we need an instruction on downloading the source to begin with? It really just promotes bad habits with those who know no better, i.e. new/inexperienced developers. The problem is when people see instructions like that on 20% of the guides they read in earnest, trusting that everything is OK if enough people say it. One hopes they stumble upon a discussion like this so that they can consider the consequences but that just isn't going to happen to everyone. True, one should exercise equal caution while cloning, gem-ing[1], etc. It would be great if authors would just link to the source and paste the relevant lines from the README if necessary.

[1] http://andre.arko.net/2013/03/29/rubygems-openssl-and-you/

I think I get where you're going with this, in that, the burden to run this and review the source is too high, that it almost seems like a waste of time. If that is your point, then I agree with you.

I don't know much about docker, but doing a "curl | sh" peeks my interest, then downloading additional binaries into /usr/local/bin, I'd want to take a closer look. Obviously, this is a case by case review, till it sits well with me. If I was going to run this in production, I'd want to have a really good idea of what this was doing and what to expect, so I'd probably take a closer look at the source if it was not clear from the documentation.

Do you reverse engineer your CPU's schematics?

This can go on pretty far - trust is always an eventually unsolvable issue.

There is a certain level of trust that is easy to achieve and easy to get. Trusting dotcloud is easier than trusting everyone on the internet is pink bunny. Happens to be that HTTPS and signing aren't exactly hard either ;-)

Even if you can be bothered to semi-manually audit the changes a script applies to the VM and can afford the time and space overheads of such a "guess-and-check" approach, a malicious server could send you a different script the second time you requested it, or the script could in turn pull down other payloads differently the second time it executed. If you try to extract a diff of the changes applied to the VM and then reapply it to your host machine to ensure the behavior is the same, why not simply have an installer system which behaves in a more restricted way to begin with? The root of the problem is that shell scripts fetched from remote servers are far too flexible to be 'safe'.

... except when someone writes a script that guesses (or reliably detects, depending on container technology) whether it's running in a VM/container and acts differently then. Or if it only acts maliciously say, one out of five times ("old school" viruses would often do that - destroy your floppies sometimes, but most of the time just spread).

Sounds like a great application of Docker, come to think of it. I'm sure it's quite possible to spin up a new docker VM from a shell script and do exactly that.

Hm, the only problem is installing Docker in the first place ...

Or... use Docker!

Seriously, Docker is perfect for creating a sandbox with all dependencies to help new users get up and running quickly and safely. Every project should come with a Dockerfile and/or Vagrantfile.

to me it's not about performance... it's about rigorous isolation. LXC is like FreeBSD jails, though there are things you can do with the cgroup namespace stuff now that are impossible using jails... eg. disk io accounting.

in a jail, one user who attempts to monopolize disk io will succeed. in a cgroup, he can be restricted to exactly 10% of available i/o bandwidth, so you can guarantee that he doesn't starve the other containers.

there are also easy and documented ways to break out of a chroot if you are able to obtain root in the chroot. those holes are plugged by lxc and docker. Most notably, access to devices can be restricted.

I don't know what you mean by "carry fat binaries and a kernel for chrooting an environment" -- you don't need a separate kernel for chroot, any more than you need a separate kernel for docker. There's no advantage to static linked binaries (fat binaries?) when you can put the storage of your containers in a zpool or btrfs with deduplification. Same as your chroots.

Try out docker. Read about cgroups. I first gave LXC a try a few years ago and I was really sad about the extent of support for creating guests and keeping them properly isolated. It was really not friendly at all. You basically had to commit to using kernel patches that made your system pretty unusable as a desktop. (Was that xen dom0 or lxc?)

Everyone was saying, "Ohh, LXC is no better than a chroot." It's insecure, easy to break yourself out. Not so much anymore, with the current state of Docker you don't even have to know all the advances in cgroup and namespaces.

It's worth a look. Really, go check it out.