Since the last article, the secmodel_jail / jailctl / jailmgr stack has moved closer to a coherent whole.
-
Since the last article, the secmodel_jail / jailctl / jailmgr stack has moved closer to a coherent whole. The original guardrails remain unchanged: no modifications to existing kernel paths, no UVM hooks, no NPF integration, no hidden coupling. The scope stays explicit and the risk bounded.
Progress has focused on operations. Logging, lightweight supervision, and basic metrics are in place, shifting the question from "can this work?" to "can this be run?". Networking remains intentionally simple and host-based; for hard isolation, Xen is still the right boundary. Jails provide an operational frame inside the host, not a replacement for virtualization.
Resource budgeting is being prototyped again via the secmodel evaluation interface, touching allocation paths and scheduler run queues in a minimally invasive way, but it needs careful review.
There is now also a small landing page to make the ideas visible, including an experimental amd64 ISO based on NetBSD 10.1 for testing. If it sparks upstream interest or discussion around lightweight, explicit isolation on NetBSD, that is already a win.
Jails for NetBSD - Kernel-enforced Isolation with User-friendly Operations
Jails for NetBSD is an experimental NetBSD-native isolation model with kernel-enforced boundaries, supervised service execution, and snapshot telemetry for practical host-side operations.
Jails for NetBSD - Kernel-enforced Isolation with User-friendly Operations (netbsd-jails.petermann-digital.de)
-
S stefano@mastodon.bsd.cafe shared this topic
-
Since the last article, the secmodel_jail / jailctl / jailmgr stack has moved closer to a coherent whole. The original guardrails remain unchanged: no modifications to existing kernel paths, no UVM hooks, no NPF integration, no hidden coupling. The scope stays explicit and the risk bounded.
Progress has focused on operations. Logging, lightweight supervision, and basic metrics are in place, shifting the question from "can this work?" to "can this be run?". Networking remains intentionally simple and host-based; for hard isolation, Xen is still the right boundary. Jails provide an operational frame inside the host, not a replacement for virtualization.
Resource budgeting is being prototyped again via the secmodel evaluation interface, touching allocation paths and scheduler run queues in a minimally invasive way, but it needs careful review.
There is now also a small landing page to make the ideas visible, including an experimental amd64 ISO based on NetBSD 10.1 for testing. If it sparks upstream interest or discussion around lightweight, explicit isolation on NetBSD, that is already a win.
Jails for NetBSD - Kernel-enforced Isolation with User-friendly Operations
Jails for NetBSD is an experimental NetBSD-native isolation model with kernel-enforced boundaries, supervised service execution, and snapshot telemetry for practical host-side operations.
Jails for NetBSD - Kernel-enforced Isolation with User-friendly Operations (netbsd-jails.petermann-digital.de)
@mpeterma it looks really cool! I love the simplicity of the interface
.I was curious if resource sharing is possible? Say I want some directory or file to be available to the jail. Will it have something like unveil or landlock?
-
Since the last article, the secmodel_jail / jailctl / jailmgr stack has moved closer to a coherent whole. The original guardrails remain unchanged: no modifications to existing kernel paths, no UVM hooks, no NPF integration, no hidden coupling. The scope stays explicit and the risk bounded.
Progress has focused on operations. Logging, lightweight supervision, and basic metrics are in place, shifting the question from "can this work?" to "can this be run?". Networking remains intentionally simple and host-based; for hard isolation, Xen is still the right boundary. Jails provide an operational frame inside the host, not a replacement for virtualization.
Resource budgeting is being prototyped again via the secmodel evaluation interface, touching allocation paths and scheduler run queues in a minimally invasive way, but it needs careful review.
There is now also a small landing page to make the ideas visible, including an experimental amd64 ISO based on NetBSD 10.1 for testing. If it sparks upstream interest or discussion around lightweight, explicit isolation on NetBSD, that is already a win.
Jails for NetBSD - Kernel-enforced Isolation with User-friendly Operations
Jails for NetBSD is an experimental NetBSD-native isolation model with kernel-enforced boundaries, supervised service execution, and snapshot telemetry for practical host-side operations.
Jails for NetBSD - Kernel-enforced Isolation with User-friendly Operations (netbsd-jails.petermann-digital.de)
Small follow-up on Jails for NetBSD.
While experimenting with resource budgeting via the secmodel evaluation interface, it became clear that pushing resource limits into the jail mechanism introduces complexity in sensitive kernel paths and risks undermining system stability. That runs counter to one of the core guardrails of the project: keep the mechanism simple, explicit, and low-risk.
As a result, resource control is now considered out of scope for Jails for NetBSD.
Jails remain focused on lightweight service isolation and operational structure inside the host. Systems that require hard resource guarantees should use virtualization boundaries such as Xen.
This keeps the design aligned with its original goal: pragmatic, minimally invasive process isolation on NetBSD.
A short write-up explaining this scope refinement will be published on the project website later this week.
