Unprivileged chroot()

Anyway, there's one advantage of direct unprivileged chroot over making an unprivileged user + mount namespace and calling chroot inside there: you retain a full UID map of the outside system. If you use "unshare -cm --keep-caps," you get to map a single UID, your own, and so things like "ls -l /bin" don't display the results you'd expect. Since unprivileged chroot wouldn't create a user namespace, things would still look normal.

Maybe this could be worked around by saying something like, if you're inside a user namespace, you have no capabilities, and you map to the same UID outside the namespace, and you call PR_SET_NO_NEW_PRIVS, you get the ability to write an identity map to uid_map and gid_map, even if they've already been written to. After all, in no new privs mode, you can't switch users or gain any capabilities, so it doesn't matter what UID mapping you see. But it seems extremely tricky to get the detail of that right and you'd probably introduce exploitable bugs the first few times you try.

(I don't believe CAP_SYS_CHROOT is a meaningful alternative here. How would you grant it? Would you give filesystem capabilities to the chroot command? It won't be enforcing the NO_NEW_PRIVS requirement, then, and will turn into an immediate local root escalation. It _can't_ enforce that requirement, in fact: if you run a setcap program under NO_NEW_PRIVS, those capabilities are ignored, specifically because you asked for no new privs! So it wouldn't work if run from a no-new-privs parent process. If you somehow could avoid that constraint and run a setcap chroot, you could call it twice, the second time with a modified /lib thanks to being able to modify your chroot, and you could use that to escape the first chroot and hold onto chrooting privileges. It is technically true that CAP_SYS_CHROOT is the best example of how the capability mechanism is supposed to work - it's a fantastic demonstration of how useless that mechanism is.)