This is cool. The commit message doesn’t really explain the security, so I’ll have a go:
Chroot is not a security tool. If you are in a chroot and run as root, you can mount devfs (on older systems, you can create device nodes) and can then mount the filesystem that contains you and escape trivially. It cannot therefore constrain a root process.
If a chroot is allowed by unprivileged processes then it can be used to launch confused deputy attacks. If a privileged process runs in a chroot then it may make decisions based on the assumption that files in certain locations are only writeable by sufficiently privileged entities on the system and may write to locations that are not where it thinks they are. Auditing everything that runs as root to ensure that this isn’t the case is difficult.
This patch provides a simple solution to both problems by denying the ability to run setuid binaries after the chroot has taken place. If you chroot, you can still run any programs that you could previously run but you can’t elevate privileges. This means that you can’t use chroot to mount a confused deputy attack using a setuid binary (you can’t run a setuid binary) and you don’t have to worry about escapes via root privileges (you can’t acquire root privileges).
In summary, this lets me do all of the things I actually want to do with chroot.
EDIT: It looks as if this is being added as part of the work to improve the Linux compat layer. I’m not sure when this was actually merged in Linux, but the patches were proposed in March, so it’s pretty recent. All of the discussion I see about it in Linux is pretty negative, which is a shame because it looks as if this feature was originally proposed for Linux in 2012 and it’s really useful.
The main one is run a tool in an environment where it can’t touch the rest of my filesystem. This isn’t particularly useful for security (it still has full network access, including the loopback adaptor) but it’s great for testing programs if you want to make sure that they’re not going to accidentally trample over things. It’s also great for a bunch of things like reproduceable builds, where you want to make sure that the build doesn’t accidentally depend on anything it shouldn’t, and for staging install files (you can create a thing that looks like the install location and run the install there and test it without touching anything on the host system.
Container infrastructure can solve a bunch of these problems, but spinning up a container (even on ZFS with cheap O(1) CoW clones) is far more expensive than a chroot.
The obvious one is chroot would be really useful for isolating unprivileged binaries, but you have to let them become root via setuid or something first, then drop to the normal privileges once it’s done chrooting. Seems kinda backwards.
That’s already done today in a lot of applications that drop privilege. I mainly ask the use case for un-priviledged users that can’t use chroot(2) or chroot(8) because they can’t elevate privilege.
The build system use case @david_chisnall mentions seems the most logical to me. That seems valuable.
When you start using the phrase “isolating unprivileged binaries” it’s into the realm of defending against something. And to make some software run in a chroot, you often have to start setting the chrooted filesystem with dynamic libraries, etc. It’s a really rough tool for an arbitrary user to just use for running an arbitrary application that doesn’t expect to be chrooted.
This is cool. The commit message doesn’t really explain the security, so I’ll have a go:
Chroot is not a security tool. If you are in a chroot and run as root, you can mount devfs (on older systems, you can create device nodes) and can then mount the filesystem that contains you and escape trivially. It cannot therefore constrain a root process.
If a chroot is allowed by unprivileged processes then it can be used to launch confused deputy attacks. If a privileged process runs in a chroot then it may make decisions based on the assumption that files in certain locations are only writeable by sufficiently privileged entities on the system and may write to locations that are not where it thinks they are. Auditing everything that runs as root to ensure that this isn’t the case is difficult.
This patch provides a simple solution to both problems by denying the ability to run setuid binaries after the chroot has taken place. If you chroot, you can still run any programs that you could previously run but you can’t elevate privileges. This means that you can’t use chroot to mount a confused deputy attack using a setuid binary (you can’t run a setuid binary) and you don’t have to worry about escapes via root privileges (you can’t acquire root privileges).
In summary, this lets me do all of the things I actually want to do with chroot.
EDIT: It looks as if this is being added as part of the work to improve the Linux compat layer. I’m not sure when this was actually merged in Linux, but the patches were proposed in March, so it’s pretty recent. All of the discussion I see about it in Linux is pretty negative, which is a shame because it looks as if this feature was originally proposed for Linux in 2012 and it’s really useful.
What uses do you have in mind? The commits and review comments don’t seem to share any particular use cases.
The main one is run a tool in an environment where it can’t touch the rest of my filesystem. This isn’t particularly useful for security (it still has full network access, including the loopback adaptor) but it’s great for testing programs if you want to make sure that they’re not going to accidentally trample over things. It’s also great for a bunch of things like reproduceable builds, where you want to make sure that the build doesn’t accidentally depend on anything it shouldn’t, and for staging install files (you can create a thing that looks like the install location and run the install there and test it without touching anything on the host system.
Container infrastructure can solve a bunch of these problems, but spinning up a container (even on ZFS with cheap O(1) CoW clones) is far more expensive than a chroot.
The obvious one is chroot would be really useful for isolating unprivileged binaries, but you have to let them become root via setuid or something first, then drop to the normal privileges once it’s done chrooting. Seems kinda backwards.
That’s already done today in a lot of applications that drop privilege. I mainly ask the use case for un-priviledged users that can’t use
chroot(2)orchroot(8)because they can’t elevate privilege.The build system use case @david_chisnall mentions seems the most logical to me. That seems valuable.
When you start using the phrase “isolating unprivileged binaries” it’s into the realm of defending against something. And to make some software run in a chroot, you often have to start setting the chrooted filesystem with dynamic libraries, etc. It’s a really rough tool for an arbitrary user to just use for running an arbitrary application that doesn’t expect to be chrooted.
Links without any surrounding context aren’t very useful. Why?