NetBSD's jail feature is based on kauth, a decent designed capabilities system, informed by an Apple technical paper. Having jails backed by kauth puts NetBSD's well above FreeBSD's, if NetBSD can reach feature parity. The earlier implementation struggled with a networking feature that NetBSD did not have.

Also, this work is made with AI:

"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."

https://mail-index.netbsd.org/tech-kern/2026/03/01/msg030854...

> Jails share the host network stack by design.

> This keeps routing, firewalling, and interface management simple on the host.

> Listening ports can be reserved per jail.

> Port ownership is enforced by the kernel, preventing accidental conflicts while preserving a straightforward host-centric network model.

It's perfectly reasonable to have a different approach, but on Linux I'll say I really prefer that each container has its own view of ports; it is specifically useful that I can run multiple copies of the same app and they can all bind :8000 or whatever and that just works.

First of all, thank you for the lively discussion and all the feedback. I’ve been following the thread for a few days and I genuinely appreciate the input. Earlier today I also received a thoughtful email with some suggestions, which motivated me to respond here publicly as well.

To give a bit of background: the idea was indeed inspired by FreeBSD. I’m a long-time admirer of FreeBSD and have worked with it for many years. In my day job I mostly deal with Linux, Kubernetes, etc., while NetBSD has become the interesting counterpoint for me in my personal projects.

My original goal was actually to reproduce something quite close to FreeBSD jails. That’s also why you currently see aliases like jls and jexec in /etc/profile. But while learning the NetBSD internals and experimenting with prototypes, I realized that some of the defining properties of FreeBSD jails - particularly network isolation and strict resource controls in hot kernel paths - would require moving outside the relatively well-defined and safer territory of the secmodel framework. For a first kernel project, that started to feel like a risky direction.

At the same time, NetBSD already has a very elegant and robust answer for strong isolation of networking and resources like CPU and RAM: Xen. From a security perspective, that happens at a level where these concerns are naturally handled.

Because of that, the project gradually shifted. What currently exists (secmodel_jail) focuses more on controlled process isolation within the host rather than full virtualization-style containment. In parallel I’m already thinking about a concept where Xen VMs and these lighter-weight “jails” could be provisioned through a unified control plane, making the distinction transparent at the operational level.

Regarding the name: I completely understand the confusion.

When you picture a jail in the strict sense - a fully isolated cell with solid walls, a tiny window, and a food slot in the door - the current prototype is not quite that. What I built so far is closer to a cage: it prevents escape, but you can still reach through the bars. In practical terms, that means certain host resources remain shared, while the security model prevents destructive interactions (for example via signals).

That analogy is simplified, but it captures the spirit.

Because of this mismatch, I’m not opposed to renaming the project at this stage. Someone suggested “cages”, which actually fits the current design quite well. I’m also open to other ideas and might run a small poll once things settle a bit.

In any case, I just wanted to let you know that I’ve read the comments and appreciate the discussion. Feedback - critical or supportive - is very welcome, especially while the design is still evolving.

Thanks for the thoughtful conversation.