Re: [Cells for NetBSD] Re: Experimental secmodel_jail prototype for NetBSD (early kernel work)

Hello Greg,

thanks for the reply and for following up on this - I really appreciate it.

On 3/9/26 23:12, Greg Troxel wrote:
> Matthias Petermann <[email protected]> writes:
> 
>> Based on community feedback and a small naming poll, the prototype
>> will move forward under the name “Cells for NetBSD”. The goal and
>> architecture remain unchanged — the rename mainly helps to avoid
>> confusion with FreeBSD Jails and to emphasize that this is intended as
>> a NetBSD-native approach.
> 
> (Dropping netbsd-users@ as I do not like to send to multiple lists at
> once.)
> 
> I was going to ask, and never got around to:
> 
>    How is this different than FreeBSD jails?
> 
>    If so, why?  Is something wrong with FreeBSD jails?

The short answer is that it depends on the level you look at it from. 
The overall goal is similar, but the design differs at several layers.

To your second question: there is absolutely nothing wrong with FreeBSD 
jails - quite the opposite. They are an excellent and very mature 
system, but...

> 
>  From your page, it sounds like you are doing essentially the same
> thing -- which makes sense.  But with renaming, apparently you aren't.
> I'm trying to figure out if this is just different to be different, or
> if there is a reason to do other than implement what FreeBSD did and use
> their code.

...NetBSD already has very solid groundwork in the form of the secmodel 
framework and kauth. These provide a fairly central decision point for 
many security-relevant operations. My prototype tries to build on that 
and enforce isolation policies primarily through those hooks.

FreeBSD has something somewhat analogous with MAC, but from what I have 
read the jail implementation itself tends to hook directly into many 
different decision paths throughout the kernel. A FreeBSD developer 
could certainly explain that better or correct me if I am 
misunderstanding parts of it. For my own work it simply felt 
architecturally cleaner to lean on the existing secmodel/kauth 
infrastructure that NetBSD already provides.

The userland tools for Cells grew out of a slightly different motivation 
as well. I work professionally in environments where DevOps-style 
operational workflows are common, so I tried to design the tooling 
around a very straightforward "out-of-the-box" experience. The layered 
control plane design is intentional, so that higher-level orchestration 
tools can be built on top later.

The idea is that a minimal workflow like

	# cellmgr bootstrap
	# cellmgr create ...
	# cellmgr start --all

should already leave you with a production ready service environment 
derived directly from the base system. So in that sense the userland 
side is deliberately its own design rather than trying to mirror 
FreeBSD’s jail tooling or configuration formats.

Your question actually touches on the reason for the rename as well. The 
term "jails" carries fairly strong associations with the FreeBSD 
implementation. Depending on who you ask, it may refer either to the 
basic kernel isolation mechanism or to the entire stack including the 
surrounding tooling.

That led to expectations that things like configuration formats, 
command-line interfaces, or runtime behavior would match the FreeBSD 
model closely. I understand and respect that expectation - if someone 
had mentioned "jails" to me a few months ago, I would also have 
immediately thought of FreeBSD.

In that sense the term functions almost like a brand name in the BSD 
world. Realizing that, it seemed better to rename the project early 
rather than keep having the same discussion about expectations.

The new name "Cells" came out of that discussion. It was originally 
suggested by a member of the FreeBSD community and later won a small 
naming poll I ran on Mastodon. And I must say, it has grown on me.

Best regards
Matthias