The Matrix

The Matrix

[Albin Lidén]

[-- Attachment #1.1: Type: text/plain, Size: 3343 bytes --]

Hello linux-security-module folks,

We’re exploring a primarily userland approach to safe, reversible
“deception” environments for training and incident response rehearsals on
Linux, built on existing kernel primitives.

Problem

   - Blue teams need repeatable ways to expose “adversaries” (or trainees)
   to believable yet harmless system states while recording interaction and
   preventing tampering of the ground truth.
   - Today, ad‑hoc chroot/jail scripts or brittle VM snapshots are commonly
   used. We’d like something more controlled, lower overhead, and scriptable.

Approach (prototype)

   - Session-scoped illusions: A subject (role/user) is placed into a mount
   namespace that presents carefully curated “decoy” trees for select paths
   (e.g., /var/log, /etc, /proc facade via ps-name tricks), plus harmless
   network listeners (e.g., nc) and realistic processes (exec -a).
   - Storage/WORM: All session keystrokes and key system events are written
   to an append-only store (WORM), with auditd rules and/or LSM hooks
   producing verifiable logs. Optional remote sink.
   - Compliance-only mode: A profile set that uses the same engine but
   without deception—hardening/monitoring only.

Kernel interfaces used

   - Namespaces: mount, user, net (per-session isolation)
   - Overlay layering: overlayfs where permissible; otherwise
   fuse-overlayfs for unpriv illusions
   - LSM policies: AppArmor/SELinux for confinement; Landlock (where
   appropriate) for “write‑deny” outside staging areas
   - Audit: auditd rules to flag decoy exits and WORM path tampering
   - eBPF/BPF LSM (optional): for stronger WORM semantics (e.g., deny
   unlink/rename on protected trees) and targeted audit

Open questions for the list

   1. For append-only/WORM semantics at userland granularity, is a BPF LSM
   policy pattern recommended over relying on chattr +a and audit alone? Any
   reference patterns for inode_unlink/rename guards with minimal perf impact?
   2. Overlayfs guidance: best practices to trigger useful audit events
   when decoy trees are mutated (whiteouts, renames) and to ensure we don’t
   degrade I/O paths?
   3. Landlock scope: pragmatically useful here to carve out
   mutation-protected trees for unpriv sessions while still allowing realistic
   “writes” into decoy overlays?
   4. Any concerns with fuse-overlayfs for non‑priv illusions in training
   environments vs. kernel overlayfs (perf, reliability)?
   5. If we later propose small kernel changes, where might they live?
   (e.g., opt‑in audit points in overlayfs; minor helpers for session-scope
   WORM meta)

We’re not proposing a new in‑tree LSM. The project is userland‑first with
existing LSMs/policies, and potentially BPF LSM snippets if that’s
appropriate. Our ask right now is guidance and prior-art pointers.

If helpful, we can share a minimal PoC repo (Go) with:

   - matrixd: session manager (namespaces + mounts), recorder
   - websion: small Go/HTML UI for operators
   - profiles: deception and compliance-only
   - seeds: curated decoy bundles (web/bastion/dev/db)
   - auditd rules + example BPF LSM (if advisable)

Thanks for your time and for any direction you can offer.

Best, Albin Lidén and Simtheory

[-- Attachment #1.2: Type: text/html, Size: 5081 bytes --]

[-- Attachment #2: the-matrix-poc-full.zip --]
[-- Type: application/zip, Size: 53584 bytes --]