[HN Gopher] Jails for NetBSD - Kernel Enforced Isolation and Nat...
___________________________________________________________________
Jails for NetBSD - Kernel Enforced Isolation and Native Resource
Control
Author : vermaden
Score : 94 points
Date : 2026-03-05 07:23 UTC (15 hours ago)
(HTM) web link (netbsd-jails.petermann-digital.de)
(TXT) w3m dump (netbsd-jails.petermann-digital.de)
| ggm wrote:
| 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.
| LargoLasskhyfv wrote:
| Does the third entry of the FAQ not suffice?
| ggm wrote:
| No. A feature table would help. An abstraction/layer diagram.
| A lot more.
|
| Could bastille port to it as-is? How about podman?
| LargoLasskhyfv wrote:
| > Could bastille port to it as-is? How about podman?
|
| He wrote things like these are out of scope.
|
| Just light and robust jails without further external
| dependencies.
| PunchyHamster wrote:
| so it's useless then as you can't run anything you'd want
| to there
| LargoLasskhyfv wrote:
| Besides the fact it isn't even ready yet, of course you
| could run everything which runs on NetBSD in there. Just
| not the ways you're used to.
|
| 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__ wrote:
| 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'.
| dizhn wrote:
| It's not a port of FreeBSD jails ?
| DeathArrow wrote:
| 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.
| PunchyHamster wrote:
| OCI is kinda layer above whatever solution is used for
| separation
| jmclnx wrote:
| 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.
| lateralux wrote:
| I've found Bastille really simple and great for creating and
| managing jails https://bastillebsd.org/
| Gud wrote:
| No thanks. I prefer my jails just the way they are and think
| Docker sucks.
| ajross wrote:
| 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.
| Gud wrote:
| I believe it's a "bad thing" and prefer my FreeBSD + jails
| setup and installing my packages using the FreeBSD package
| manager.
|
| 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 wrote:
| > 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.
| arcade79 wrote:
| Uh; not the same as FreeBSD jails? But name conflict? That's just
| silly.
| SoftTalker wrote:
| "jail" is a generic term for any sort of isolation. I've heard
| a simple chroot called a "jail"
| 0x2b9fd814feb0 wrote:
| Zones from Solaris is a nice name.
|
| 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 wrote:
| > Also, this work is made with AI:
|
| More like assisted with AI, in a way that seems perfectly
| reasonable.
| atmosx wrote:
| Can you explain why kauth is superior than FreeBSD's solution?
| yjftsjthsd-h wrote:
| 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.
| lateralux wrote:
| 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
| mpeterma wrote:
| 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.
|
| Thanks for the thoughtful conversation.
___________________________________________________________________
(page generated 2026-03-05 23:01 UTC)