[Cells for NetBSD] Re: Experimental secmodel_jail prototype for NetBSD (early kernel work)

Hello all,

a small follow-up to my previous mail: since yesterday the project has a 
new name.

Based on community feedback and a small naming poll, the prototype will 
move forward under the name “Cells for NetBSD”. The goal and 
architecture remain unchanged — the rename mainly helps to avoid 
confusion with FreeBSD Jails and to emphasize that this is intended as a 
NetBSD-native approach.

The project page has moved accordingly:
	
	https://netbsd-cells.petermann-digital.de/

The site now also contains some additional background on the project and 
a small FAQ addressing a few of the questions that came up in recent 
discussions.

Questions, feedback, or suggestions are always welcome - either here on 
the list or directly.

Best regards
Matthias

On 3/1/26 10:33, Matthias Petermann wrote:
> Hello all,
> 
> I was recently asked why nothing about my current jail prototype has 
> appeared on the NetBSD mailing lists yet. I would like to correct that 
> and briefly share the current state here.
> 
> I have published an experimental prototype tentatively called “Jails for 
> NetBSD”. The idea is to explore a kernel-integrated, lightweight process 
> isolation model built on top of NetBSD’s existing kauth/secmodel 
> infrastructure. The goal is deliberately modest: something positioned 
> between chroot-style containment and full virtualization, with clear 
> kernel-level identity boundaries and a deterministic resource 
> association per “jail”.
> 
> Link: https://netbsd-jails.petermann-digital.de/
> 
> This work explicitly understands itself as a continuation or re- 
> interpretation of earlier isolation efforts in the NetBSD ecosystem:
> 
> - GAOLS (P3A, 2008): jail-like process isolation via kauth(9) hooks — 
> research prototype, never integrated.
> 
> - MULT (P5A, 2008): resource isolation by instantiating full kernel 
> subsystems — highly invasive research prototype.
> 
> - netbsd-sandbox: userland sandboxing via chroot, secmodel_sandbox, 
> rlimits, capabilities, Lua policies — hardening tool, not a jail model.
> 
> - Systrace (NetBSD 2.0) / sysjail: syscall-interposition-based process 
> isolation — deprecated and removed.
> 
> Personally, I spent quite some time experimenting with systrace around 
> the NetBSD 2.0 era and was already interested back then in something 
> closer to jail-style isolation. When that code disappeared from the 
> kernel, the topic effectively faded for me as well. For workloads where 
> stronger isolation was required, my pragmatic solution became Xen (with 
> corresponding tooling in dom0), and in my professional day job Linux 
> namespaces and cgroups — and the isolation stacks built on top of them — 
> are naturally common.
> 
> Last summer, after being unexpectedly out of commission for a few weeks, 
> I found myself with time to read kernel code more systematically, 
> including the earlier NetBSD isolation approaches mentioned above. That 
> is when the idea resurfaced and gradually matured into the current 
> prototype.
> 
> Technically, the current implementation introduces a jail identity 
> attached to processes and enforces isolation decisions via secmodel/ 
> kauth hooks. There are also early experiments around per-jail resource 
> accounting and limits (CPU, memory, process count) and a small userland 
> control layer. The focus so far has been on identifying enforcement 
> points that are conceptually clean and compatible with NetBSD’s design, 
> rather than layering on features.
> 
> This is very much experimental. In particular, resource enforcement in 
> hot paths and deeper subsystem interactions (scheduler, UVM, networking) 
> have shown that naive approaches quickly become problematic. I am 
> currently scaling back some of the more invasive parts to converge on a 
> smaller, more reviewable core before exploring further extensions.
> 
> For context: this is my first serious work inside the NetBSD kernel. I 
> am not an experienced NetBSD kernel developer. To better understand 
> complex code paths and trade-offs, I use AI-based tools for analysis and 
> occasionally for draft implementations. However, everything that goes 
> into my working tree is manually reviewed, adjusted, or discarded by me. 
> I only integrate changes that I believe are technically sound and that I 
> can explain and defend, and I am working towards a clean and auditable 
> tree structure.
> 
> Feedback, design criticism, and pointers to prior art within NetBSD that 
> I may have overlooked are very welcome. My primary goal at this stage is 
> to validate (or invalidate) the architectural direction before going any 
> further.
> 
> Best regards,
> Matthias
> 
>