Re: automatic creation of a chroot environment

From: Adrian Chadd <adrian_at_freebsd.org>
Date: Fri, 17 Jul 2026 15:10:45 UTC
On Thu, 16 Jul 2026 at 15:07, Mario Marietto <marietto2008@gmail.com> wrote:
>
> >I also meant on my website - in these VN issues:
> >- https://vermaden.wordpress.com/2026/05/25/valuable-news-2026-05-25/
> >- https://vermaden.wordpress.com/2026/06/15/valuable-news-2026-06-15/
>
> Thank you bro !
>
> >Hi all,
>
> >chroot_env (https://github.com/rozhuk-im/chroot_env) is a lightweight >tmpfs+chroot sandbox for FreeBSD - no jails, no ZFS, RO by default, noexec/nosuid >on anything writable. As the author notes, one thing it doesn't touch is the >network stack: chroot(2) gives a sandboxed process the same network access as >its user has on the host.
>
> Someone read the code that I have provided for adding an opt-in network ACL without pulling in jails or VNET ? My sensation is that it has been forgotten for some reason. If it is not relevant for the project,let me know. This is a way for me to understand if I have understood what's the direction of the project. Anyway, I hope it can be useful.

I would really, REALLY like to see sandbox / capability extensions
that let me do things such as "no you can't access the whole
filesystem, only binaries/libraries and a sandbox directory, not my
whole home directory" (which this kind of does?) as well as "why no
you can't talk to the network directly" - without needing root to
create a jail first.

Eg, there's no reason why a little AI agent, some CI test code or a
shell process which is going to call a bunch of compiler stuff should
have access to the network.

If we can figure out a way for users to be able to do this - whether
it is changes to the kernel, or what apple did (a sandbox service that
user processes use to request sandboxes be created) or something else?
That'd be huge.



-adrian