Re: Proposal: Enabling unprivileged chroot by default

On 8/6/25 09:55, Darren Henderson wrote:
> 
> On 8/5/2025 3:59 PM, Jordan Gordeev wrote:
>> On Tuesday, 5 August 2025 at 17:58, 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).
>> If a system manager wants to allow unprivileged users to use 
>> chroot(8), they can easily allow that by setting the sysctl to 1 on 
>> their system. Taking that into account, what problem will changing the 
>> default solve?
>>
>> Do the majority of FreeBSD users simultaneously:
>>    1) have a desire to use chroot(8) as an unprivileged user
>>    2) have no clue how to change a sysctl?
> 
> I would take it further than this - is there even a significant minority 
> of users who need or want this?

Like all uses of FreeBSD, that's difficult or impossible to track.  To 
put this in context, I started the discussion because I'm looking for a 
way for ordinary users to reliably build and install software with or 
without assistance from a sysadmin.  The prototypical user in my mind is 
a researcher using workstation managed by their employer's I.T. 
department, or a shared resource such as an HPC cluster, run by their 
employer or maybe ACCESS CI.

The solution is a simple, cross-platform package manager that will be 
usable without any assistance from I.T. staff.  There aren't nearly 
enough qualified sysadmins in the HPC world, or academia in general, so 
it's important that the system allow users to self-serve on whatever 
resources they have access to.  This can eliminate huge delays to 
important research.  In my 20 years in the business I saw countless 
cases where research was held up for months while people searched for 
ways to install software that could be deployed in seconds by any decent 
package manager.
> It seems like something that should be a conscious and deliberate change 
> to the system for which an exceeding simple change by the sysadmin is a 
> reasonable and practical solution.
> 
> A niche need that increases the potential attack surfaces isn't 
> something that should be made the norm. Leave it disabled.

I tend to agree with this sentiment, and I won't be upset if the 
proposal to enable unprivileged_chroot by default is ultimately 
rejected.  If I were still managing HPC clusters, I would be hesitant to 
even enable it manually.  It would be slick if this system could work on 
FreeBSD without any 3rd party software like proot or fake-chroot, but 
it's not essential.

I'm only in support of this change if those reviewing it determine that 
there is no significant risk involved.  That's a decision for the 
project's security experts, which I am not...

-- 
Life is a game.  Play hard.  Play fair.  Have fun.