[Jails for NetBSD] Experimental secmodel_jail prototype for NetBSD (early kernel work)

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


-- 
Für alle, die digitale Systeme verstehen und gestalten wollen:
jede Woche neue Beiträge zu Architektur, Souveränität und Systemdesign.
👉 https://www.petermann-digital.de/blog