[Voklen]

Can anyone explain why chroot requires root privileges in the first place? Because from my understanding it seems like it should only restrict what you can do rather than grant any new abilities.

[Teongot]

If you can get a suid root binary into the chroot, then you can control its configuration files to bypass security restrictions.

   $ ln /usr/bin/sudo ./my-chroot
   $ echo "$USER ALL=(ALL) NOPASSWD: ALL" > ./my-chroot/etc/sudoers.d/01-oops
   $ chroot ./my-chroot
   $ sudo bash

modern Linux distributions prevent creation of hard links to suid binaries, but the restrictions on chroot came years before that.

[cedws]

Can’t SUID binaries in chroots be ignored, like the nosuid mount flag?

[badmintonbaseba]

Nowadays you have unprivileged options with mount namespaces. And from an unprivileged user namespace you can probably invoke chroot just fine as "root".

`chroot`, the function, has probably some baggage that makes it impossible to enable straight from an unprivileged program? Anyway, a chroot-like program seems to be implementable on top of user namespaces. Rootless docker is mostly that, with more namespace and cgroup isolation.

[vifon]

chroot doesn't nest, there is only one chroot active for a given process at a given moment. If you're inside a chrooted environment and call chroot on a subdirectory without entering it, you regain the access to the parent directories.

[compsciphd]

which is why before fs namespaces, as part of security research prototype work I did, I created a "chroot aware" (not quite, but close enough for this context to use that term), that wouldn't let one walk past certain directories (i.e. lookup() would fail for them, no matter what permissions the user had once one entered "pseudo namespace" mode via this chroot mechanism). Was very easy to accomplish, but also very much a hack that fs namespaces are much better for.