Re: Proposal: Enabling unprivileged chroot by default

> On Aug 5, 2025, at 11:57 PM, Ed Maste <emaste@freebsd.org> wrote:
> 
> I would like to change the default value of the
> security.bsd.unprivileged_chroot sysctl from 0 (disabled) to 1
> (enabled). This will allow unprivileged users to invoke chroot(2)
> under constrained and secure conditions. See the recent "Non-root
> chroot" thread on freebsd-hackers@ for some more context.
> 
> **Background**
> Support for unprivileged chroot(2) was introduced before FreeBSD 14.0
> (and MFC'd for FreeBSD 13.1) via commit a40cf4175c90 ("Implement
> unprivileged chroot"), but disabled by default. This commit added:
> 
> - a sysctl security.bsd.unprivileged_chroot that must be set to 1
> - a check in chroot(2) that the NO_NEW_PRIVS procctl is set when
> called in an unprivileged context
> - a new chroot(8) flag -n to set the NO_NEW_PRIVS procctl
> 
> NO_NEW_PRIVS causes the kernel to ignore set-user-ID and set-group-ID
> bits, preventing the well-known confused deputy issues affecting
> chroot(2).
> 
> The original commit did not include a man page update. I've now added
> a description of unprivileged use in commit 95f8c3e1ed0c, and a more
> explicit error message from chroot(8) if -n is missing, in commit
> e6c623e9bad5.
> 
> **Proposed Change**
> A patch to change the default sysctl value to 1 is under review here:
> https://reviews.freebsd.org/D51702. A regression test still needs to
> be added before this would be committed.
> 
> **Request for Feedback**
> If you have concerns, objections, or additional insight into the
> security or operational impact of this change, please reply to this
> thread or comment directly on the Phabricator review.
> 
> Timing on the commit is an open question; it could be done soon (so
> that the change will be available in FreeBSD 15.0) or after stable/15
> branches (making it available in FreeBSD 16.0).
> 

Thanks for this post and the work here Ed,

Concerns:
some of the worst security compromises I've had to unwind in the last 25 years have had something to do with setuid or chroot directly.  While this defaults change is quite exciting and welcome, I believe setting this default may pose unknown risk, (substantial, at that).
A change like this could come as a surprise to users, (as chroot has not changed for the better in some decades, folks like me would miss this and could make poor decisions).

Suggestion:
I believe one clear and simple way to mitigate this risk, (as well as appropriately announce the behavior to users), is to add a checkbox to bsdinstall, allowing users disable up front - specifically the post-install config right here: "2.8.5. Enabling Hardening Security Options"
https://docs.freebsd.org/en/books/handbook/bsdinstall/#bsdinstall-hardening

Perhaps a bit cumbersome to toss extra work at you near the finish line, but, I think a change like this would benefit from the extra user communication.

Best,
.ike