Hacker News Reader

Yeah, I assume the author meant to write "kernel memory" there. I think what they were getting at is that root could theoretically mknod a /dev/mem device inside the chroot jail and then modify kernel data structures through it. Or root could issue an init_module(2) syscall to install a kernel module that breaks out of the jail.

View on HN

Right, but on modern Linux, you're a seccomp call away from blocking those vectors. The inadequacy of chroot was a more coherent story to tell 10 years ago, but now, it seems silly to suggest that chroot isn't a security feature; it is, it's just part of an ensemble of related features that need to be deployed in concert.

Well, this was published in 2013. That was right around the time seccomp-bpf was introduced, but I don't think best practices around it were widely known at the time.

This isn't true. For example containers use pivot_root instead of chroot or MS_MOVE because there are specific security issues with keeping a reference to the parents mount table.

If you care about security there is no reason to use chroot on Linux, there are better approaches.

Is there a vulnerability pivot_root breaks that applies to unprivileged users? I wrote quickly and imprecisely and agree that in general chroot isn't especially helpful against the superuser (for a bunch of reasons).

Reply on news.ycombinator.com