Comment by liquidgecka | Hacker News Reader

Comment by liquidgecka | Hacker News Reader

Parent Full thread

Uhh.. No.

"Containers" are a mix of two major pieces of technology. One is cgroups, the other is namespaces. Chroot is analogous (kind of) to mount namespaces is all. Containers need not use all of the features of all the cgroups and namespaces available.

For example, from the linux command line I can use the "unshare" command line took to create namespaces to simulate some of the components without the other fanfare.

for example, with namespaces I can remove network access to any process without changing anything else about the system. In this example the process run (ping) has no network devices at all. I love using this to ensure that a script doesn't attempt to download anything unexpected.

$ sudo unshare -n ping 127.0.0.1 ping: connect: Network is unreachable

I can also do things like remove files mounted under another mount. Make a directory called "foo", touch a file in that directory, then mount a ramdisk on top of it and the file is no longer accessible. I can use unshare -m to create a process with a new mount namespace, umount foo and the file becomes accessible again, all while other processes on the system can still see the contents of foo. A real world example of this is when the mysql database got copied onto the root disk before the mysql mount was created. You can leave mysql running while removing the over-mounted files without production risk.

Cgroups are also nifty, you can restrict resources without changing the root file system. So I can ensure that no children of mine can consume more than 1G of RAM without fiddling with file systems at all. Systemd does this with its limits configurations and there are a ton of useful limits that can be applied.

One of the coolest aspects of this is that you can do this per thread, meaning that you can do something like run your render thread in a network namespace without internet access, this preventing possible RCE on just that thread, same for mount namespaces and such, making it possible to chroot effectively a single thread in your application.

So no, containers are not just fancy chroot, they are so very much more.

> "Containers" are a mix of two major pieces of technology. One is cgroups, the other is namespaces.

I respectfully disagree with that definition of what a "container" is.

cgroups, namespaces, and so on are an implementation detail of how containers are commonly implemented on linux these days.

OpenVZ (https://en.wikipedia.org/wiki/OpenVZ) and Solaris Containers (aka zones) both predate the current linux implementation and did not use namespaces or cgroups.

All three of those ways of running containers are containers. unshare/namespaces/cgroups is just one possible implementation. There are also, certainly, other ways of implementing containers, so it feels wrong to define it in terms of just one specific, admittedly the most popular, implementation.

linux namespaces/cgroup may be an implementation detail. But at a high level, each container can have a different view on system resources, and this is the critical point. Different from each other and the host system. The system resource can be filesystem, network access, processes, memory, ... .

chroot only isolates the file system, otherwise all other system resource is shared with the host system.

I don't doubt that other container technologies achieved similar level of isolation or more before Docker. But chroot is really not comparable to Docker.

Dockers for Windows and Macs do not even use "cgroups" and "namespaces" because these technologies are not available on these stacks -- it resorts to plain old VMs. So in a sense, yes, Docker is not just chroot but on the other hand, it is also not just "cgroups" with "namespaces". It turns out Docker is a reference implementation for the concept of containers. But you can replace it with anything that can process images and a "Dockerfile".

Modern containers are a mix of cgroups, namespaces, pivot_root (like chroot but more appropriate for containers), and seccomp.

Some implementations (e.g. firecracker-containerd) also use SELinux and CPU virtualization support.

"containers are just chroot" is an oversimplification to the point it's misleading.

I think that podman on rhel/fedora also 'uses selinux' to confine containers.

Given that threads share an address space, can't the render thread trivially overwrite the call stack of another thread to run attacker-selected functions and parameters?

> Given that threads share an address space, can't the render thread trivially overwrite the call stack of another thread to run attacker-selected functions and parameters?

Yes.

The fact these Linux APIs are per-thread is an artifact of how Linux implements threads, and certainly not a security feature. From a security standpoint, this behavior is more an anti-feature--it's too easy for someone to naively believe they've dropped ambient privileges, unaware that a thread context in the process (a normal process thread, or possibly a io_uring thread or the io_uring context itself) could still possess elevated privileges.

There’s also thread local storage though I don’t know wether the stack sits on it.

Thread-local storage is no less visible to other threads, it's merely a little less convenient to access--you need to figure out the address(es) the same as you would for most any other link in an RCE exploit chain.

I think you might be reacting to the title - the article is a lot more measured in its claims, and is a fantastic read.

Perhaps, but his title, and vast over simplification of the technologies he is trying to demystify is doing it all a huge disservice. Its like saying that a "Nuclear Reactor is just a steam turbine with marketing". Chroot was a very specific piece of technology that was nifty in its day, but the entire concept of how the kernel interfaces with processes had to be reworked to make namespaces work. Its not just "minor refinements and marketing" as he states. I appreciate that he is trying to show that "containers" just run in process space, but the approach is just overly simplified with no further explanation of just how simplified it is later on.

Ok, we've replaced the linkbaity title with a more representative sentence from the article.

If anyone can suggest a better title (i.e. more accurate and neutral, and using language from the article itself), we can change it again.

I wrote this and the consistent feedback I've gotten was that people hate the title, so thanks for changing it. I'd pick 'What chroot taught me about containers' but this also works.

Even better. Changed from "Let’s build a container runtime using only the chroot system call". Thanks!

Looks good to me

Thanks! ^_^

I'd love a more detailed chapter about this topic. Sounds extremely interesting. Kind of OPs post but with added examples and explanations about croups and namespaces.

In my opinion the series starting with https://medium.com/@teddyking/linux-namespaces-850489d3ccf is the gold standard for introducing namespaces.

Thanks!

i definitely agree with you, but I think the point of this exercise is to demonstrate how container images operate (i.e. a rootfs with alterations on top, applied via essentially a recursive untar)

Reply on news.ycombinator.com