Hacker News Reader

Comment by rotten | Hacker News Reader

1) There were/are sometimes ways to break out of them. 2) The process table is mixed in with your OS process table - making it hard to tell what is running chrooted and what isn't. 3) The network stack is shared 4) They share an OS

You can make a "spectrum" of environments where you run code. One one side is everything running on a single server in a single OS, on the right is everything having its own machine and OS. In between you have chroot, docker, blade servers, virtual machines, and other isolation techniques. chroot falls somewhere between everything running in one system, and everything running in docker containers on one system.

View on HN

1) should actually be "there are ways to break out of them, period". chroot isn't a security feature, it doesn't even try to be one.

The "chroots doesn't offer any security" statement needs to be a bit more nuanced. A non-privileged process in a dedicated directory can't do much damage, and certainly can't escape the chroot without some sort of privilege escalation.

That does not mean you can slap chroot syscalls everywhere and call it secure, of course. But it is still an important part of dropping privileges, together with seccomp-bpf, control groups and the various ACL systems.

It is an important part of things like the OpenSSH privilege separation, where the early protocol is handled by a dedicated process in a read only chroot. It proven both simple and effective in practice, contrary to the idea that chroots are escapable.

Here's a list of ways to break out, marked either as root required or not. Some are only vague idea, others are explained. https://deepsec.net/docs/Slides/2015/Chw00t_How_To_Break%20O...

I too thought you can't easily escape unprivileged chroot, but in reality you need to think about quite a few things to make sure it's true.

And once you need to think about those things... Why not apparmor/selinux instead.

None of the listed methods are novel. Most are elaborate ways of saying "privilege escalation".

If an untrusted process can escalate to root, ptrace to unrelated processes, or access memory outside your process, it was never really contained in the first place.

Do also note that none of the listed methods works in what the presentation itself calls a "reasonable chroot".

> Why not apparmor/selinux instead

It's not either or. Dropping privileges is something you preferably do in more ways than one.

This. If you want the security features, switch to a BSD (jails) or illumos (zones). These started spiritually from that same chroot place but were designed to incarcerate your software in a small subsystem.

The illumos ecosystem in particular got a lot of work from Joyent in this container vein—like how Windows can now run Linux binaries natively because they implemented the Linux system call table, illumos has Linux-branded zones that do the same “our kernel, Linux’s API, no virtualization” approach to Linux containers.

I mean you should throw in Linux filesystem namespaces in there too since I doubt too many people can just switch to a BSD for this.

Windows runs Linux binaries by running Linux in a VM. Something newish is that Windows also implements Windows by running NT and a Windows UI in a VM.

Running on a hypervisor originated at IBM, on its 370, and is very mature technology. Arguably, an OS running on bare metal is practically an embedded system, these days; There are just so many things that make a hypervisor useful or essential.

The key insight IBM had was that the hypervisor runs under the control of one of its VMs. That means the hypervisor doesn't need to provide a full-featured, comfortable work environment; that is the job of guest OSes. Instead, it manages resources according to policies implemented in an "executive" guest OS not used for, or vulnerable to mistakes or malevolence in, regular user programs.

A modern example of such a system is Qubes, security-oriented OS that hosts and orchestrates Linux, BSD, and even Windows VMs.

WSL 2 is virtualization-based (and likely Microsoft’s primary path going forward), but WSL 1 was not— it actually did implement the Linux ABI on top of the Windows kernel, allowing Linux processes to coexist alongside Windows processes (with no actual Linux kernel involved at any point).

It’s actually a pretty neat architecture— I’m on my phone right now and can’t track down a link, but it’s worth reading about if you’ve got the time. Kind of a shame that they moved on to the virtualization approach, but understandable— they’re trying to solve the same sort of problem as Wine, where you’ve got to mimic all the quirks of a foreign OS and it’s also a moving target (so you’re never “done”).

File system access is super slow on WSL. This was one the drivers. If I recall correctly it is because some common Linux syscalls (stat?) are missing/slow on Windows NT kernels.

The filesystem in general is known to be much slower on Windows due to it's extreme flexibility, but Linux design decisions assumed a much more performant filesystem. Hence why running linux on windows slammed into the performance problem.

> Something newish is that Windows also implements Windows by running NT and a Windows UI in a VM.

That’s not really that new. Windows 3.x, running in 386 Enhanced mode, was based on a 32-bit pre-emptive multitasking hypervisor (the VMM). Windows apps shared VM 0, cooperatively multitasked, and were mostly 16-bit. VM 1 and above were for DOS apps, including 32-bit DOS apps using DPMI.

(In Windows 3.0, it is possible to start a subordinate instance of the Windows UI in VM 1 or above. This possibility was removed in later versions.)

This architecture was introduced in Windows/386 2.1x and maintained through Win 95,98 and Me. (In Win 95 and later, most of the 16-bit code in VM 0 became 32-bit.)

> The process table is mixed in with your OS process table

Just wanted to point out that this is true for Docker containers as well.

Something that has actually come in handy from time to time trying to diagnose things.

I think from within the container you can only see that container's processes, but outside (as root) you can see all processes, even those inside the container.

It makes it easy to attach a debugger, too.

That's correct.

I'm curious as to why blade servers are in your mix—aren't they essentially separate physical machines sharing a common backplane for I/O? Seems basically identical (from a software perspective) as servers hosted in the same rack.

They also often share power among some number of blades. When the spectrum is how co aolidated software and hardware are, it is a bit apart from separate physical instances, as the fault tolerance isn't quite the same.

Blade servers are purchased for their density.

> 4) They share an OS

Unless you make your Dockerfiles `FROM scratch` you do have an OS too.

Reply on news.ycombinator.com