Unprivileged chroot

[trasz]

Summary

This is a RFC for unprivileged chroot(8). All feedback is welcome.

This builds on recently introduced NO_NEW_PRIVS flag to implement unprivileged chroot, enabled by security.bsd.unprivileged_chroot. It allows non-root processes to chroot(2), provided they have the
NO_NEW_PRIVS flag set.

The chroot(8) utility gets a new flag, -n, which sets NO_NEW_PRIVS
before chrooting.

[jhb]

sys/kern/kern_exec.c

655 ↗

(On Diff #88696)

This is now redundant as the helper function frees the cred?

sys/kern/vfs_syscalls.c

961

[trasz]

Rebase, improve the consistency of procctl(2) API, and add Linux bits.

[phk]

I'm fine with the two new features proposed individually.

But their linkage has me worried, it is both very blunt, and opaque.

We cannot allow random users to chroot into a tree of their own construction full of captive setuid files.

But how did they get the setuid files in there to begin with, without loosing the setuid bits ?

As far as I can tell, the only way to do that, is to have a writable directory on the same filesystem as the setuid file you want to capture, in which case you can hard-link to it.

It sounds to me like the correct protection is to disallow hardlinking to setuid files, unless you are root or own then ?

And thinking more about it: Why is that even allowed to begin with ?!

I think this needs to be run past the secteam and possibly arch ?

[trasz]

For the purpose of making it easier to review, and eventually commit, parts have been spun off into https://reviews.freebsd.org/D30939 and https://reviews.freebsd.org/D30940. I'll follow up with Linuxulator and chroot bits afterwards.

[trasz]

Regen, improve man page description.

[kib]

usr.sbin/chroot/chroot.8

68

There is no prctl

[trasz]

Fix Xr.

[trasz]

(Tinderboxed.)