Jails for NetBSD is an experimental prototype for lightweight, kernel-enforced isolation on NetBSD.

It closes the operational gap between simple chroot environments and full virtualization platforms such as Xen.

The project runs multiple workloads on a single host with:

  • Strong process isolation
  • System hardening profiles
  • Supervised service execution
  • Unified lifecycle management
  • Centralized logging
  • Snapshot-based metrics export

The system stays fully NetBSD-native: isolation and policy enforcement are built into the kernel security framework, not delegated to a separate runtime layer.

The goal is not to replicate Linux-style container ecosystems, but to provide a focused operating model with minimal dependencies, no external control services, and explicit operational boundaries.

As with any kernel-based isolation, security depends on kernel correctness; stronger trust separation may still require virtualization such as Xen.

Earlier design discussions and experiments also considered per-jail hard resource partitioning, but that topic is currently out of scope for this prototype.

Overall, the project is a practical impulse for modern isolation capabilities that fit naturally into existing NetBSD administration workflows.

The implementation is built around the following components:

Layer Model

  • secmodel_jail Kernel security model responsible for jail identity, policy enforcement, and snapshot telemetry.

  • jailctl Low-level control interface for lifecycle management, supervised execution, and runtime statistics export.

  • jailmgr Host-side orchestration layer for filesystem preparation, persistent configuration, and multi-jail operations.

An optional in-jail service runner (svcmgr) is available for tightly coupled multi-process workloads.

Jails for NetBSD focuses on practical, operator-friendly isolation with a balanced emphasis on policy, observability, and daily operations.


Isolate Workloads Safely

Each jail provides a clear containment boundary.

Processes cannot inspect or signal processes across jail boundaries, which keeps failures scoped to the affected workload.


Harden System Access

Security profiles (low, medium, high) restrict privileged host-scope operations for jailed workloads.

Administrative actions such as mounting filesystems or modifying host state can be controlled per jail.


Prevent Port Conflicts

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.


Built-in Supervisor

Run services in foreground mode under the built-in host supervisor.

  • Automatic restart with backoff
  • Deterministic lifecycle
  • No hidden daemons
  • Clear operational visibility from the host

Centralized Logging

  • Jailed services emit logs to stdout/stderr to the host supervisor, which forwards them to syslog for collection and retention
  • A unified host-level log stream across all jails improves auditing and incident analysis

Telemetry

Jails expose snapshot telemetry for operational monitoring.

  • CPU ticks (1s delta and rolling 10s average)
  • Process count
  • Reference count
  • Sampled virtual-memory size

Metrics are available via jailctl list and jailctl stats, with optional Prometheus export for integration into existing monitoring systems.


Operate Fleets with jailmgr

jailmgr provides host-side operations for multi-jail environments.

  • Bootstrap workflow for module/config/base layout preparation
  • Persistent per-jail configuration (autostart, supervise command, profile, reserved ports)
  • Consistent lifecycle operations (create, start, stop, restart, status)
  • Host-driven in-jail script execution via apply

This section demonstrates a minimal, reproducible workflow using jailmgr, jailctl, and NetBSD base components.

The example provisions a constrained HTTP service inside a jail, starts it, inspects runtime state, and exposes metrics.


1. Bootstrap

Prepare the host for jail operation.

This step:

  • Loads the secmodel_jail kernel module
  • Ensures it is configured for automatic loading on boot
  • Prepares base filesystem layers
  • Creates default configuration files
  • Initializes the jail data directory layout

2. Create Jail

Create a jail named web with:

  • HTTP daemon bound to port 8080
  • Medium hardening profile
  • Reserved listening port 8080
  • Structured logging
vhost# jailmgr create -a -x '/usr/libexec/httpd -I 8080 -X -f -s /var/www/mysite' -l medium -r 8080 -f local3 -o info -e err -t jail-web web
Created jail web
vhost#

3. Ephemeral Provisioning

Execute commands inside the jail from the host, without altering its persistent configuration.

The jail is entered temporarily, the commands are run, and control returns to the host.

vhost# jailmgr apply --ephemeral web <<'APPLY'
mkdir -p /var/www/mysite
echo "<html>Hello NetBSD!</html>" > /var/www/mysite/index.html
APPLY

4. Start All Jails

Each jail configuration contains an autostart setting that can be enabled or disabled individually. The --all option operates only on jails where autostart is active.

vhost# jailmgr start --all
Started jail web
vhost#

5. Supervision Model

When started in supervise mode, jailctl daemonizes itself on the host and becomes the parent process for the workload running inside the jail.

All processes started within the jail are descendants of the jailctl supervise process.

From the host perspective, these processes remain fully visible in the standard process table. There is no hidden runtime or separate process namespace.

Host process tree:

vhost# ps axd
....
8252 ?     Ss   0:00.00 |-- jailctl: jailctl supervise jail=web jid=3 
6488 ?     Ss   0:00.01 | `-- /usr/libexec/httpd -I 8080 -X -f -s /var/www/mysite 

Enter jail context:

vhost# jailctl exec web
vhost# whoami
root
vhost# ps axd
 PID TTY   STAT    TIME COMMAND
6488 ?     Is   0:00.01 /usr/libexec/httpd -I 8080 -X -f -s /var/www/mysite 
7117 pts/1 S    0:00.01 /bin/sh -i 
5572 pts/1 O+   0:00.00 - ps -axd 
vhost#

Inside the jail context, even the root user can only see processes belonging to that jail.

Cross-jail process visibility is denied by the kernel. The host context (jid 0) remains the only global view.


6. Runtime Statistics

Snapshot telemetry per jail is maintained inside the kernel and exposed through the control interface.

vhost# jailctl stats
ID       NAME             CPU1S      CPU10S     PROC       REFS       VMEM
3        web              0          0.0        1          2          154025984

7. Prometheus-Compatible Metrics Endpoint

jailctl stats can emit Prometheus-compatible metrics.

The -P flag switches to Prometheus exposition format.

This makes it possible to expose the metrics endpoint using only base system facilities (for example via inetd), without requiring a dedicated exporter daemon.

vhost# jailctl stats -P -h
HTTP/1.1 200 OK
Content-Type: text/plain

# TYPE jail_cpu_usage_ticks_1s gauge
# TYPE jail_cpu_usage_ticks_10s_avg gauge
# TYPE jail_processes gauge
# TYPE jail_references gauge
# TYPE jail_vmem_bytes gauge
jail_cpu_usage_ticks_1s{jid="3",name="web",root="/var/jailmgr/jails/web/root"} 0
jail_cpu_usage_ticks_10s_avg{jid="3",name="web",root="/var/jailmgr/jails/web/root"} 0
jail_processes{jid="3",name="web",root="/var/jailmgr/jails/web/root"} 1
jail_references{jid="3",name="web",root="/var/jailmgr/jails/web/root"} 2
jail_vmem_bytes{jid="3",name="web",root="/var/jailmgr/jails/web/root"} 154025984

Result

  • Base-system HTTP daemon
  • Snapshot-based observability
  • Supervised execution
  • Ephemeral provisioning
  • Observable via structured metrics
  • No container runtime
  • No UID remapping
  • No full virtualization

This is process isolation as a disciplined, inspectable system primitive.

Jails for NetBSD is under active development.

The project provides source access and an experimental ISO build for evaluation and testing.


Source Code

The project is maintained in a dedicated source tree and now primarily developed on a branch based on netbsd-11.

Repository (NetBSD 11, active):

Bug Reports (GitHub Issues): https://github.com/MatthiasPetermann/netbsd-src/issues


Evaluation DVD Image (Unofficial Build)

An evaluation DVD image based on NetBSD 11.0 RC1 (amd64) with integrated Jails support is available:

Download:

Verify Checksum:

sha256sum NetBSD-11.0_RC1.jails7-amd64-dvd.iso
d637e5e4b7a8148ab5e2645168bc1eac192b30c2747ee8c6d9e0bdc2d74eae34  /home/mpeterma/Library/iso/NetBSD-11.0_RC1.jails7-amd64-dvd.iso

Important Notice

This ISO is not an official NetBSD release.

It is an experimental build derived from a NetBSD source tree with additional modifications for Jails support.

It is provided only for idea evaluation and to get an early impression of how jails on NetBSD could work.

It is an independent effort and is not aligned with or endorsed by the NetBSD core team.

For official NetBSD releases, please refer to:


Status

This project is currently in a technology preview stage.

It is suitable for development, evaluation, and architectural exploration. Interfaces, behavior, and internal structures may change as the design evolves.

The goal is to provide a concrete impulse for discussion and progress. The project should be seen as a practical contribution to that direction, alongside other possible implementation approaches.

Jails for NetBSD relates to earlier research and isolation efforts in the NetBSD ecosystem.

Project Focus Status
GAOLS (P3A, 2008) Jail-like process isolation via kauth(9) hooks Research prototype; never integrated
MULT (P5A, 2008) Resource isolation by instantiating full kernel subsystems Highly invasive research prototype
netbsd-sandbox Userland sandboxing via chroot, secmodel_sandbox, rlimits, capabilities, Lua policies Hardening tool; not a jail model
Systrace (NetBSD 2.0) / sysjail Syscall interposition–based process isolation Deprecated / removed

Jails for NetBSD focuses on jail-scoped enforcement integrated into the existing kauth security framework, without syscall interposition or full subsystem replication.

This FAQ addresses common questions and critical points about scope, security model, and project direction.


“Does ’not a container ecosystem’ mean it is not for security?”

Not at all. Security is a core goal.

The statement means this project is not a general-purpose container ecosystem and not full virtualization. It focuses on one clear scope: kernel-enforced process isolation with explicit operational boundaries.

As with any kernel isolation model, high-risk trust separation can still require virtualization (for example Xen), and we state that openly.


“Jails are containers, right? Why say it is not a container platform?”

The term “container” is overloaded.

Here, “not a container platform” means: no OCI runtime stack, no image distribution workflow, and no orchestration control plane. Jails for NetBSD is a NetBSD-native isolation model with a smaller, predictable toolchain.


“How is this different from FreeBSD jails?”

FreeBSD jails are established and feature-rich, including resource limits and multiple forms of virtual networking.

Jails for NetBSD is intentionally narrower in scope: it targets NetBSD specifically, with a different API and a strong emphasis on operational simplicity, explicit boundaries, and host-visible supervision. Advanced resource limiting and alternative virtual networking models are out of scope.

The primary goal is a simple operational layer that improves security and delivers a strong out-of-the-box experience without requiring additional tools.


“Linux container internals can feel like a patchwork”

Many operators share that experience.

This project intentionally keeps the model compact: one host-centric network model, kernel-backed policy decisions, and fewer moving parts in day-to-day operation.


“Looks easy to use”

Thank you. Ease of use is intentional.

The goal is to keep advanced isolation approachable for regular NetBSD administration workflows.

This website is operated in accordance with applicable German law.

Content is provided without warranty as to accuracy, completeness, or timeliness. External links are the responsibility of their respective operators. All content is subject to German copyright law.

NetBSD® is a registered trademark of The NetBSD Foundation, Inc.

For full provider information and detailed legal disclosures,


AI notice: AI tools were used for code analysis and prototyping.