Jails for NetBSD – Kernel Enforced Isolation and Native Resource Control

https://netbsd-jails.petermann-digital.de/

by vermaden • 5 months ago

113 27 5 months ago

ggm2• 5 months ago

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.

LargoLasskhyfv3• 5 months ago

Does the third entry of the FAQ not suffice?

ggm2• 5 months ago

No. A feature table would help. An abstraction/layer diagram. A lot more.

Could bastille port to it as-is? How about podman?

__patchbit__• 5 months ago

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• 5 months ago

It's not a port of FreeBSD jails ?

DeathArrow• 5 months ago

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.

PunchyHamster2• 5 months ago

OCI is kinda layer above whatever solution is used for separation

jmclnx• 5 months ago

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.

lateralux2• 5 months ago

I’ve found Bastille really simple and great for creating and managing jails https://bastillebsd.org/

Gud3• 5 months ago

No thanks. I prefer my jails just the way they are and think Docker sucks.

ajross2• 5 months ago

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.

arcade79• 5 months ago

Uh; not the same as FreeBSD jails? But name conflict? That's just silly.

SoftTalker• 5 months ago

"jail" is a generic term for any sort of isolation. I've heard a simple chroot called a "jail"

0x2b9fd814feb0• 5 months ago

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• 5 months ago

Also, this work is made with AI:

More like assisted with AI, in a way that seems perfectly reasonable.

atmosx• 5 months ago

Can you explain why kauth is superior than FreeBSD’s solution?

yjftsjthsd-h• 5 months ago

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.

lateralux2• 5 months ago

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

mpeterma3• 5 months ago

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.

mpeterma3• 5 months ago

Good morning everyone, just a quick follow-up on the naming topic. There is an ongoing poll and I'd like to invite you to vote: https://mastodon.bsd.cafe/@mpeterma/116180607527845598

mpeterma3• 5 months ago

Small update: since yesterday the project has a new name — Cells for NetBSD.

The goal and architecture remain exactly the same. The rename mainly helps to avoid confusion with FreeBSD Jails and better reflects that this is intended as a NetBSD-native approach rather than an attempt to replicate the FreeBSD architecture.

https://netbsd-cells.petermann-digital.de/

Jails for NetBSD – Kernel Enforced Isolation and Native Resource Control

Related Stories