Re: Non-root chroot
- Reply: Jamie Landeg-Jones : "Re: Non-root chroot"
- In reply to: Jamie Landeg-Jones : "Re: Non-root chroot"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sat, 09 Aug 2025 11:20:28 UTC
On 8/7/25 19:43, Jamie Landeg-Jones wrote: > Jason Bacon <bacon4000@gmail.com> wrote: > >> On 8/5/25 22:59, Jamie Landeg-Jones wrote: > >>> But just as it is if you're not using a chroot, your non-root user cannot >>> create suid-root binaries, and when you're setting things up, you'd simply not >>> use root to copy a suid-root 'su' (or anything else) into your chroot tree. >> >> Not quite true: >> >> FreeBSD moray.acadix bacon ~ 1018: sysctl vfs.usermount >> vfs.usermount: 1 >> FreeBSD moray.acadix bacon ~ 1019: whoami >> bacon >> FreeBSD moray.acadix bacon ~ 1020: mount -t nullfs /usr/bin >> /home/bacon/new-root/usr/bin/ >> FreeBSD moray.acadix bacon ~ 1021: ls -l new-root/usr/bin/su >> -r-sr-xr-x 1 root wheel 17K Jul 28 17:11 new-root/usr/bin/su* >> >> Granted, usermount should generally not be set on a shared system, but >> it could happen. > > But usermounts are mounted nosuid. I knew that at one time, but it slipped my mind. ;-) Thanks for the reminder... > >> Or, as I mentioned in a prior response, there's always the possibility >> of duping a root user into installing an suid binary. Not all of them >> are highly qualified, and everyone gets tired or rushed sometimes. > > Yeah, possible, especially if they are recursively copying a system > tree (/bin /usr/bin etc.) to the chroot, but the point I was replying > to said "Important point is that the user is not obliged to hand in any > particular "su" program. The user may hand in any "su"-like code suitable > for escaping the chroot.", so that's not very likely, though I concede > that this is an attack vector greater than not allowing user-chroot. > > Would forcing all user-chrooted trees to be no-suid-root solve this, > do you think? > > Cheers, Jamie It's already forced, but requires user-action. If the user does not use -n, the chroot will fail. I suggested on the phabricator thread that this should not be necessary, and PROC_NO_NEW_PRIVS_CTL should be set automatically based on getuid() != 0. This won't affect security, just make the UI more elegant. -- Life is a game. Play hard. Play fair. Have fun.