3 ms·
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 insid
by pcwalton 7y ago
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.
- tptacek 7y agoRight, 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.
- pcwalton 7y agoWell, 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.
- darren0 7y agoThis 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.
- tptacek 7y agoIs 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).