release: bump version to 1.3.0

Author: nmicic

README.md

@@ -6,10 +6,10 @@
 Kernel-enforced sandboxing for untrusted processes. Two zero-dependency
 core tools, one shared profile format, plus an optional BPF-LSM module.
 
-> **Core vs optional module:** `compartment-user` and
-> `compartment-root` are the zero-dependency core. `compartment-bpf`
-> is an optional advanced module with kernel and toolchain
-> requirements.
+> **v1.3.0 note:** `compartment-user` and `compartment-root` are
+> unchanged and remain the zero-dependency core. `compartment-bpf`
+> is a new optional advanced module for kernel-level inode sealing,
+> with its own kernel and toolchain requirements.
 
 > **Note:** This is an open-source Linux isolation toolkit, not a
 > formally validated security product. The code has been through

compartment-bpf/LIMITATIONS.md

@@ -123,8 +123,8 @@ syntax.)
 |----------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------|
 | **LD_PRELOAD / LD_AUDIT injection** into actor  | The kernel sees the legitimate actor binary as caller (exe inode matches). Library injection is in-process; compartment-bpf cannot distinguish in-process tampering.    | `tools/compartment-actor-wrapper` (static-linked clean-exec wrapper: `clearenv()` + opt-in `--allow-env` allowlist + DANGEROUS-name guard rejecting LD_PRELOAD/LD_AUDIT/GLIBC_TUNABLES/PYTHONPATH/...); systemd unit `UnsetEnvironment=`; setuid not used. The default is no env survives the wrapper boundary; the guard catches operator mistakes adding dangerous names via `--allow-env`. **Note:** `UnsetEnvironment=LD_PRELOAD` alone leaves `LD_AUDIT`, `LD_DEBUG`, and the other 30+ glibc dynamic-loader vectors active. Use `UnsetEnvironment=~LD_` (the `~` prefix matches by pattern in systemd ≥ v243) or enumerate all `LD_*` names explicitly. The wrapper's clearenv-then-allowlist is the load-bearing control; the systemd directive is defense in depth.             |
 | **ptrace attach + memory write** of running actor | Once the actor process is running, an attacker with `CAP_SYS_PTRACE` can attach and write its memory. The kernel still sees the actor as caller for any subsequent ops. | `yama.ptrace_scope=2` (kernel cmdline); `no_new_privs`; seccomp filter on `ptrace(2)` for production daemons. The actor-wrapper installs a seccomp denylist that blocks ptrace + `process_vm_{readv,writev}` + `pidfd_getfd` + `kcmp` from the wrapped process itself (does NOT stop a third party from ptracing the actor — pair with Yama). |
-| **CAP_BPF + direct map mutation**            | A privileged user can `bpftool map update` against `sealed_inodes` / `sealed_dirs` and weaken or wipe seals. The v0 model assumes a trusted load phase.                  | `SIGNED-POLICY-SPEC.md` §7 `bpf_gate` (future); `bpf_map_freeze` after load (already enforced in v0.3 loader).     |
-| **Privileged BPF link detach** (`bpf(BPF_LINK_DETACH)` / bpffs link unlink) | A privileged user with `CAP_BPF` can detach the compartment-bpf LSM links at runtime via the `bpf(BPF_LINK_DETACH)` UAPI or by `unlink()`ing the bpffs link pin, removing every hook from the kernel chain in one syscall. This is distinct from `bpftool map update` (which weakens individual seals): a successful detach removes enforcement entirely until the next `--pin`, leaving the system fail-OPEN. | Restrict `CAP_BPF` to the loader and operator accounts (drop from all daemons via systemd `AmbientCapabilities=` / `CapabilityBoundingSet=`); ingest `audit_event` ringbuf into a SIEM that alerts on enforcement-stop; `SIGNED-POLICY-SPEC.md` §7 `bpf_gate` (future) closes this surface at the kernel layer. |
+| **CAP_BPF + direct map mutation**            | A privileged user can `bpftool map update` against `sealed_inodes` / `sealed_dirs` and weaken or wipe seals. The v0 model assumes a trusted load phase.                  | Future signed-policy / `bpf_gate` work; `bpf_map_freeze` after load (already enforced in v0.3 loader).     |
+| **Privileged BPF link detach** (`bpf(BPF_LINK_DETACH)` / bpffs link unlink) | A privileged user with `CAP_BPF` can detach the compartment-bpf LSM links at runtime via the `bpf(BPF_LINK_DETACH)` UAPI or by `unlink()`ing the bpffs link pin, removing every hook from the kernel chain in one syscall. This is distinct from `bpftool map update` (which weakens individual seals): a successful detach removes enforcement entirely until the next `--pin`, leaving the system fail-OPEN. | Restrict `CAP_BPF` to the loader and operator accounts (drop from all daemons via systemd `AmbientCapabilities=` / `CapabilityBoundingSet=`); ingest `audit_event` ringbuf into a SIEM that alerts on enforcement-stop; future signed-policy / `bpf_gate` work is the kernel-layer closure. |
 | **Out-of-band kernel writes**                | Direct `kmem` writes, kprobe overwrites, or kernel-module loads can disable the LSM hook chain entirely.                                                                | Kernel `lockdown=integrity` or `lockdown=confidentiality` (kernel cmdline); `kernel.modules_disabled=1`; Secure Boot. |
 | **Offline tampering of the actor binary**    | If the attacker boots from rescue media and edits `/usr/sbin/aide` on the unmounted disk, E-6 cannot fire — enforcement is only active at runtime.                       | LUKS full-disk encryption; signed kernel modules; IMA/EVM file signatures; locked-down boot firmware.              |
 | **Exec via interpreter chain** (NOT a bypass) | Actor exec's `python /tmp/evil.py` → `current->mm->exe_file` becomes `python`. File access is then correctly denied because python is not in `actor aide`. This is the intended behavior, listed here so readers don't mistake it for a bypass. | None needed — this is intended fail-closed semantics.                                                              |
@@ -192,6 +192,5 @@ is security-load-bearing.
   rationale per row.
 - `README.md` Limitations section — high-level v0 / v0.3 capability
   surface.
-- `experimental/SIGNED-POLICY-SPEC.md` — design intent for future
-  cryptographic policy signing (sealed-agent mode, future exec-trust
-  seal — not yet shipped).
+- Future signed-policy design notes — cryptographic policy signing,
+  sealed-agent mode, and future exec-trust seal work not yet shipped.

compartment-bpf/ON-RAMP.md

@@ -5,7 +5,8 @@ If you are reading this in a fresh clone and want to confirm that
 pick one of the three paths below. They differ in fidelity, setup
 cost, and what they prove.
 
-For the design rationale, read `experimental/ARCHITECTURE.md`.
+For the design rationale, start with `README.md`, `HOWTO.md`, and
+`experimental/EXEC-DOMAIN-SPEC.md`.
 
 ## Path A — full-fidelity KVM VM (production-grade)
 

compartment-bpf/README.md

@@ -166,8 +166,7 @@ See `LIMITATIONS.md` for the full table. Highlights:
   namespace lockdown for stronger guarantees.
 - **btrfs / overlayfs anon_bdev**: on these filesystems, `(dev, ino)` can be
   reused across bind-mount views of the same inode; see LIMITATIONS.md.
-- **No cryptographic policy signing** (design intent in
-  `experimental/SIGNED-POLICY-SPEC.md`).
+- **No cryptographic policy signing** yet.
 
 ---
 

compartment-bpf/experimental/EXEC-DOMAIN-SPEC.md

@@ -3,7 +3,8 @@
 > Status: draft v0.3, May 2026 — authoritative consolidation of the
 >          exec-domain feature family for compartment-bpf
 > Audience: implementers, profile authors, reviewers
-> Companion to: `SIGNED-POLICY-SPEC.md`, `ARCHITECTURE.md`
+> Companion to: the future signed-policy / `bpf_gate` design notes and
+>               the broader compartment-bpf design rationale
 > Prerequisite: v0 enforcement surface (existing seal model)
 > Lineage: LIDS exec-domain (1998–2002) — historical motivation
 >          for the actor-allowlist property; the author's 2001
@@ -300,7 +301,7 @@ worker has the same `mm->exe_file` inode.
 - **T-X4. CAP_BPF process direct map mutation.** Root with
   `bpftool map update` against the seal map can bypass enforcement
   without a kernel-side gate. The v0 model assumes a trusted load
-  phase. The defense is `SIGNED-POLICY-SPEC.md` §7 `bpf_gate` —
+  phase. The defense is future `bpf_gate` work —
   *out of this spec's scope* but compatible with it.
 
 - **T-X5. Exec via interpreter chain — NOT a bypass.** Actor
@@ -468,7 +469,7 @@ every failed unpin attempt durable — silent suppression requires
 compromising both channels.
 
 The real defense against malicious unpin by a CAP_BPF-equipped
-attacker remains `bpf_gate` (see `SIGNED-POLICY-SPEC.md` §7),
+attacker remains `bpf_gate` (see the future signed-policy work),
 which puts an LSM gate on `BPF_PROG_DETACH` and `BPF_OBJ_GET`
 from non-agent tasks. That is out of this spec's scope and is not
 implemented in v0.x. Until `bpf_gate` lands, a CAP_BPF user can
@@ -1419,7 +1420,7 @@ unpacker. The unpacker is a transport.
 
 ### 15.2 What the addendum proposes
 
-Two reserved TLVs in `SIGNED-POLICY-SPEC.md` §4.3 — `EXEC_DELEGATE`
+Two reserved TLVs in the future signed-policy design — `EXEC_DELEGATE`
 (0x07) and `DOMAIN_CLAIM_MAP` (0x08) — plus `DOMAIN_FLAG_ALLOW_ANON_EXEC`
 on `DOMAIN_DEF`. Six requirements (R-22..R-27 in the addendum's
 numbering) wire `bpf_gate` to admit claim-map writes only from
@@ -1552,11 +1553,11 @@ additions (T-7 / T-8 / T-9 in the addendum's numbering).
 
 ## 17. References
 
-- `SIGNED-POLICY-SPEC.md` — §7 `bpf_gate`. Compatible with this
+- Future signed-policy / `bpf_gate` work — compatible with this
   spec; not required. Shape B for unpin protection.
-- `ARCHITECTURE.md` — overall component shape; this exec-domain
-  family slots into the daemon's existing inode-keyed seal model
-  without changing the management-plane assumptions.
+- Broader compartment-bpf design rationale — this exec-domain family
+  slots into the daemon's existing inode-keyed seal model without
+  changing the management-plane assumptions.
 - `tools/profile-draft.py` — drafting tool that this spec extends
   with discovery-input ingestion (§13). DT_NEEDED expansion is
   explicitly NOT part of this spec; libraries are loaded via
@@ -1607,7 +1608,7 @@ additions (T-7 / T-8 / T-9 in the addendum's numbering).
   binary's identity comes from the binary being itself sealed
   against modification (E-6 for actors, X-6 for exec-trust),
   not from cryptographic measurement. TPM / IMA integration is
-  `SIGNED-POLICY-SPEC.md` territory.
+  future signed-policy territory.
 - **Not anonymous-inode content verification.** Even with the
   Exec_Enc addendum (§15) adopted, the spec does NOT verify what
   bytes the kernel runs from an anonymous inode; trust is

compartment.h

@@ -31,7 +31,7 @@
 #define _GNU_SOURCE
 #endif
 
-#define COMPARTMENT_VERSION "1.2.0"
+#define COMPARTMENT_VERSION "1.3.0"
 
 #include <stdio.h>
 #include <stdlib.h>

man/compartment-root.8

@@ -1,6 +1,6 @@
 .\" Copyright (c) 2026 Nenad Mićić <nenad@micic.be>
 .\" SPDX-License-Identifier: Apache-2.0
-.TH COMPARTMENT-ROOT 8 "April 2026" "compartment 1.2.0" "System Administration"
+.TH COMPARTMENT-ROOT 8 "May 2026" "compartment 1.3.0" "System Administration"
 .SH NAME
 compartment-root \- full-namespace process isolation (requires root)
 .SH SYNOPSIS

man/compartment-user.1

@@ -1,6 +1,6 @@
 .\" Copyright (c) 2026 Nenad Mićić <nenad@micic.be>
 .\" SPDX-License-Identifier: Apache-2.0
-.TH COMPARTMENT-USER 1 "April 2026" "compartment 1.2.0" "User Commands"
+.TH COMPARTMENT-USER 1 "May 2026" "compartment 1.3.0" "User Commands"
 .SH NAME
 compartment-user \- userspace process isolation with Landlock, seccomp, and environment sanitization
 .SH SYNOPSIS