I'll make the same comment I did on the other post about this. Either document how it differs from FreeBSD jails or give it some other name. Anything else is asking for confusion.
That some other name: 'cells' (or 'tiles'), in the compositional sense of leaf and tree, forest, framework is more inviting for creative work than 'jails'.
It would have been more interesting have they released something compatible with Open Container Initiative. Most people use Docker containers and having Docker compatible containers would have helped with improved adoption of BSDs.
I have used jails and I still say it is far easier to maintain, lighter and more secure that what Linux has. The only good thing I can say about docker is it is easier to setup.
Also the way I read the document, NetBSD's Jail is going to be very close to what FreeBSD does.
The OCI work mentioned upthread is about interface, not implementation.
Most people who think "Docker sucks" are talking about it's somewhat questionable network layer on Linux and the poor security isolation of the daemon. Non-docker alternatives like Podman don't have that characteristic.
But no one (at least no one reasonable) thinks Dockerfile's building docker images for download from docker-compatible repositories are a bad thing. That stuff runs the world. And the FreeBSD refusal to make a real attempt at interoperability is a confusing wart on what otherwise is pretty good tech.
> Docker sucks and only exists because after all these years, Linux STILL doesn’t have a great way to handle third party applications.
That's... not at all a correct characterization of where Docker found its purchase or what it's used for. Easy containerization dead-to-rights solved the version hell problem of shipping software at scale from vendors and upstreams that can't agree on dependency management. That's not something you can fiat away with "excellent ports and package systems" unless you imagine a world where literally every tiny microservice or cloud backend gadget ends up as a port in a single tree.
Basically you're saying "Docker sucks because I don't do anything that needs containers for anything but security". Well... yeah. I guess it would seem that way.
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."
I'm a little surprised; I guess I would have assumed that if netbsd got jails they'd be an outgrowth of rump kernels with improved security properties. No big deal, just unexpected.
> 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.
It’s awesome to see Unix descendants still alive and active. NetBSD has been doing some really cool stuff lately, like PVH boot support.
Kudos to the SmolBSD team, a really fun project that made NetBSD PVH boot support, allowing it to boot a microVM on QEMU in ~10 ms https://smolbsd.org
Hi, Matthias here - the person currently working on Jails for NetBSD, if one can call it that.
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.
ggm | 14 hours ago
LargoLasskhyfv | 14 hours ago
ggm | 11 hours ago
Could bastille port to it as-is? How about podman?
LargoLasskhyfv | 11 hours ago
He wrote things like these are out of scope.
Just light and robust jails without further external dependencies.
PunchyHamster | 11 hours ago
LargoLasskhyfv | 10 hours ago
IMO anything which makes NetBSD's base more complete is good.
When it is ready, it remains to be seen which external tools may be ported to make use of the newly available internals. If ever.
__patchbit__ | 12 hours ago
dizhn | 12 hours ago
DeathArrow | 11 hours ago
PunchyHamster | 11 hours ago
jmclnx | 10 hours ago
Also the way I read the document, NetBSD's Jail is going to be very close to what FreeBSD does.
lateralux | 4 hours ago
Gud | 10 hours ago
ajross | 7 hours ago
Most people who think "Docker sucks" are talking about it's somewhat questionable network layer on Linux and the poor security isolation of the daemon. Non-docker alternatives like Podman don't have that characteristic.
But no one (at least no one reasonable) thinks Dockerfile's building docker images for download from docker-compatible repositories are a bad thing. That stuff runs the world. And the FreeBSD refusal to make a real attempt at interoperability is a confusing wart on what otherwise is pretty good tech.
Gud | 5 hours ago
Docker sucks and only exists because after all these years, Linux STILL doesn’t have a great way to handle third party applications.
Unlike FreeBSD, which has both the excellent ports and package systems.
FWIW I am not married to FreeBSD. I use Arch Linux as well.
ajross | 4 hours ago
That's... not at all a correct characterization of where Docker found its purchase or what it's used for. Easy containerization dead-to-rights solved the version hell problem of shipping software at scale from vendors and upstreams that can't agree on dependency management. That's not something you can fiat away with "excellent ports and package systems" unless you imagine a world where literally every tiny microservice or cloud backend gadget ends up as a port in a single tree.
Basically you're saying "Docker sucks because I don't do anything that needs containers for anything but security". Well... yeah. I guess it would seem that way.
arcade79 | 9 hours ago
SoftTalker | 5 hours ago
0x2b9fd814feb0 | 8 hours ago
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...
JCattheATM | 7 hours ago
More like assisted with AI, in a way that seems perfectly reasonable.
atmosx | 3 hours ago
yjftsjthsd-h | 5 hours ago
> 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.
lateralux | 4 hours ago
mpeterma | 2 hours ago
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.