3 ms·

The problem is that there are many well-known ways to get around chroot(2) (which don't require privileges). This includes /proc-related escapes as well as more

by cyphar 7y ago

The problem is that there are many well-known ways to get around chroot(2) (which don't require privileges). This includes /proc-related escapes as well as more general VFS attacks. Really, tools should have switched to using pivot_root(2) a decade ago instead of continuing to use chroot(2). Unfortunately this article completely ignores the existence of pivot_root(2) -- which makes it read as though they are trying to convince people to stop using root-switching a security feature (which is definitely bad advice).

bluecmd 7y ago
I've never seen this advice, would you mind elaborating or citing a more elaborate source? Since pivot_root requires the old root to be a child of the new root, traversing back to the full system seems trivial. Actually, I don't see why this syscall isn't worse than chroot due to this.
- ece 7y ago
  grsec doesn't use pivot_root, you can read into that however much you'd like: https://en.wikipedia.org/wiki/Grsecurity#Chroot_restrictions https://en.wikipedia.org/wiki/Grsecurity#Chroot_restrictions
- cyphar 7y ago
  > Actually, I don't see why this syscall isn't worse than chroot due to this. You can (and everyone does) unmount the oldroot. Then in your mount namespace the old root is not reachable through the VFS alone. You need to make use of procfs's magic-links or other such tricks.
deleted 7y ago
[deleted]
vbezhenar 7y ago
Isn't it better to fix those many well-known ways to escape chroot?
- cyphar 7y ago
  Some of them can't be reasonably fixed (doing a path_is_under() check on all ".." traversals would fix most security bugs -- but it would make all path lookups be O(n^2) which is unacceptable) and there is also the risk of yet-unknown attacks.
xorcist 7y ago
> This includes /proc-related escapes as well as more general VFS attacks. Right, there are numerous ways to mess up a chroot, just like any other namespace isolation such as process and network namespaces. Basically as soon as you bind one namespace inside another, the containing namespace will have access to the contained namespace. That much should (hopefully) be obvious. If you mount a procfs inside your application it is no longer contained from the syscalls that procfs necessitates. But that's not typical for an application that drops privileges. Even decaces old software such as BIND, which has had numerous vulnerabilities over the years, chroots to the data directory and drops to an unprivileged user by default. There is an important distinction here whether the application itself should drop any unnecessary privileges, as exemplified by chroot, seccomp and pledge, or whether the application should be started with as little privileges as possible, as exemplified by SELinux and Docker. In the former case, the responsibility falls on the application developer, and in the latter case on the system administrator or end user. The article explicitly argues for SELinux instead of the chroot. That is, arguing the latter approach is superior to the former. That is experimentally verified bad advice by now. Software such as Chrome rely on chroot-style compartmentalisation and is much better off because of it. > tools should have switched to using pivot_root(2) a decade ago Yet people keep using the simpler tool. The threat model is the same and pivot_root is easier to misuse. In fact, it is probably a good idea to do both.

by cyphar 7y ago

bluecmd 7y ago

I've never seen this advice, would you mind elaborating or citing a more elaborate source? Since pivot_root requires the old root to be a child of the new root, traversing back to the full system seems trivial. Actually, I don't see why this syscall isn't worse than chroot due to this.

ece 7y ago
grsec doesn't use pivot_root, you can read into that however much you'd like: https://en.wikipedia.org/wiki/Grsecurity#Chroot_restrictions https://en.wikipedia.org/wiki/Grsecurity#Chroot_restrictions
cyphar 7y ago
> Actually, I don't see why this syscall isn't worse than chroot due to this. You can (and everyone does) unmount the oldroot. Then in your mount namespace the old root is not reachable through the VFS alone. You need to make use of procfs's magic-links or other such tricks.

deleted 7y ago

[deleted]

vbezhenar 7y ago

Isn't it better to fix those many well-known ways to escape chroot?

cyphar 7y ago
Some of them can't be reasonably fixed (doing a path_is_under() check on all ".." traversals would fix most security bugs -- but it would make all path lookups be O(n^2) which is unacceptable) and there is also the risk of yet-unknown attacks.

xorcist 7y ago

> This includes /proc-related escapes as well as more general VFS attacks. Right, there are numerous ways to mess up a chroot, just like any other namespace isolation such as process and network namespaces. Basically as soon as you bind one namespace inside another, the containing namespace will have access to the contained namespace. That much should (hopefully) be obvious. If you mount a procfs inside your application it is no longer contained from the syscalls that procfs necessitates. But that's not typical for an application that drops privileges. Even decaces old software such as BIND, which has had numerous vulnerabilities over the years, chroots to the data directory and drops to an unprivileged user by default. There is an important distinction here whether the application itself should drop any unnecessary privileges, as exemplified by chroot, seccomp and pledge, or whether the application should be started with as little privileges as possible, as exemplified by SELinux and Docker. In the former case, the responsibility falls on the application developer, and in the latter case on the system administrator or end user. The article explicitly argues for SELinux instead of the chroot. That is, arguing the latter approach is superior to the former. That is experimentally verified bad advice by now. Software such as Chrome rely on chroot-style compartmentalisation and is much better off because of it. > tools should have switched to using pivot_root(2) a decade ago Yet people keep using the simpler tool. The threat model is the same and pivot_root is easier to misuse. In fact, it is probably a good idea to do both.