Re: Non-root chroot

On 4 Aug 2025, at 22:26, Vadim Goncharov <vadimnuclight@gmail.com> wrote:
> 
> On Sat, 2 Aug 2025 08:29:14 +0100
> David Chisnall <theraven@freebsd.org> wrote:
> 
>>> On 1 Aug 2025, at 23:04, Jason Bacon <bacon4000@gmail.com> wrote:
>>> 
>>> I'm aware of jails, which I use regularly for poudriere testing, but I'm
>>> under the impression that they also require root privileges at some level.
>>> To be clear, are you saying that a non-privileged user, with no ability
>>> to edit system files or change sysctls can create a jail in user space
>>> with no assistance from the sysadmin?  So far I have not found a way to do
>>> this.  
>> 
>> No, not currently. It’s a thing I’d like to add. The issue is that a user
>> who can create jails can trivially gain root access on the host: log into
>> the jail as root, set the setuid bit on a copy of the shell, leave the jail,
>> run the shell. You could similarly access any other user’s files by creating
>> a user with the same UID as them.
>> 
>> This is possible because the filesystem stores UIDs but isn’t aware of the
>> jail that owns them. A file owned by uid 0 in or out of a jail is a file
>> owned by root according to the filesystem.
>> 
>> To fix this, I would want to add a creator UID to the jail and make two
>> additional changes:
>> 
>> First, when modifying permissions and ownership of a file, the changes are
>> stored in some extended attributes that are hidden from the jail. Second,
>> when doing any access check, you must:
>> 
>> 1. Check the in-jail credentials agains the permissions in the extended
>> attributes. 2. If the extended attributes are not present, instead check the
>> in-jail credentials against the base owner / permissions in the FS. 3. If
>> either of these succeed, *also* check the FS permissions against the owner
>> of the jail, fail if the owner is not authorised.
> 
> Seems like a problem for filesystems which do not support extended attributes
> (theoretical abuse from user).

If a filesystem doesn’t support extended attributes, it will be less useful in a jail created by an unprivileged user. Users in the jail won’t be able to change permissions and their access will be limited to the intersection of the rights of their UID and the jail owner’s UID (I.e. root in the jail would be able to access the set of files accessible by the user).

>> Linux has a different (simpler?) way of doing this, where each UID is
>> authorised to access a range of UIDs. This would be fairly easy to adapt to
>> FreeBSD. You would need to define the range and then do an addition in the
>> jail so UID 0 in the jail would be the start of the user’s allowed UID
>> range. You’d need to reserve a few thousand UIDs for each user who can
>> create jails, but that’s not too many if UIDs are 32 bits. On Windows, the
>> equivalent of a UID is a UUID and so the problem is much simpler, you need
>> to map administrator but you can trivially create a large number of
>> non-conflicting UIDs for their container infrastructure.
> 
> This way is useful to e.g. port Podman containers from Linux.

Non-root Podman was one of my main motivations. I don’t think the Linux approach is the right one, but I think the above proposal would be fairly easy to implement (for someone with a bit more spare time than me) and would allow ocijail to work nicely for non-root users.

David