Hacker News Reader

Comment by zlynx | Hacker News Reader

There are dangerous things that you can allow Docker to do. But if you don't do those things, it is pretty difficult to break out of a container.

Redhat has been especially good here, with not allowing anyone but host-root to connect to Docker and using SELinux and seccomp filtering. With those working, it doesn't matter if your container mounts a host filesystem since it won't have the correct SELinux roles and types anyway.

Many people claim that ruins Docker, since now you can't use Docker from within Docker. But that's the price you pay for security.

I believe that with the correct precautions, a Linux container is just as safe as a jail or zone. Perhaps the problem is just how easy it is for a sysadmin to put holes into the containers that ruin the security.

View on HN

> Perhaps the problem is just how easy it is for a sysadmin to put holes into the containers that ruin the security.

I think there's a bit more to it than that. For some examples of other reasons people might be wary vs zones:

docker itself is still a daemon that runs as root, combining a large number of different functionalities which require root access into a single binary with a large attack vector and a lot of code which doesn't need to be privileged. While isolation of responsibilities of docker has begun, even their own security page [1] admits that there's a long way to go here.

Zones are, as many of the articles in this thread point out, a first class feature designed and implemented. What docker/"containers" allow you to do is the culmination of many building blocks which have been incrementally added to the Linux kernel. Some of those have been pretty recently, and without an overall design, their interactions with other portions of the Linux kernel or other components of the system have often been surprising and led to a number of security issues over time. In comparison, both the code and the design of the system are relatively young. A good example of this can be found at [2], which ends with the following very apt quote:

> Why is it that several security vulnerabilities have sprung from the user namespaces implementation? The fundamental problem seems to be that user namespaces and their interactions with other parts of the kernel are rather complex—probably too complex for the few kernel developers with a close interest to consider all of the possible security implications. In addition, by making new functionality available to unprivileged users, user namespaces expand the attack surface of the kernel. Thus, it seems that as user namespaces come to be more widely deployed, other security bugs such as these are likely to be found.

It might also be interesting to read [3], which is already showing that 3.5 years later, user namespaces are still a breeding ground for security issues that lead to privilege escalation.

[1] https://docs.docker.com/engine/security/security/#related-in... [2] https://lwn.net/Articles/543273/ [3] https://utcc.utoronto.ca/~cks/space/blog/linux/UserNamespace...

I can appreciate that the features needed to be developed and matured over time, but I don't understand why Linux didn't invent an umbrella concept to tie everything together.

It seems to me a grab bag of things which Linux allows to be independently namespaced/isolated: Cgroups, networking, PIDs, VFS, etc. From a kernel point of view, this would be the perfect use case for an "object-oriented" design with some kind of abstract container concept that reflected the nesting of each container, but instead it seems very scattered and ad-hoc.

In particular, each mechanism is opt-in and must configured separately, very carefully; to approximate Zones you have to combine all of the mechanisms together and hope you didn't forget something, and also hope that the kernel's separation is perfect (which, given the vast amounts of "objects" it can address, is doubtful). To my untrained (in terms of kernel development) eye, this seems the opposite of future proof, because if the kernel invents some new namespacing feature, an application that uses all of the existing mechanisms won't automatically receive it, because there's no concept of a "container" as such.

opt-in seems like the wrong approach. The safer alternative would be that a new container process was completely isolated by default, and that whoever forked the process could explicitly specify the child's access (e.g. allow sharing the file system). This is, I believe, how BSD jails work.

That "object-oriented" design is called capabilities.

> since now you can't use Docker from within Docker.

Docker-in-docker is a trashfire that barely works anyway, it's no real loss.

Think you might be talking about running the Docker daemon inside Docker, which is a different thing from just calling Docker from a container.

Ah, you're right. The latter is actually a pretty cool solution, I've had great success with using it to spawn what are essentially sibling containers.

Reply on news.ycombinator.com