INC-2026-04-04: P16g Deployed Without Mandatory Access Control

Incident Summary

Field Value

Detected

2026-04-04 ~evening PDT (self-audit during domus-digitalis setup)

Mitigated

Pending

Resolved

Pending

Duration

Ongoing since 2026-04-02 (deployment date)

Severity

P2 (High) - Secrets-handling workstation with no process confinement

Impact

All processes run with full user privilege — no isolation between applications and ~/.secrets/, ~/.gnupg/, ~/.age/, gopass stores

Root Cause

MAC system (AppArmor/SELinux) not included in P16g deployment phases

Timeline

Time (PDT) Event

2026-04-02

P16g deployed — Phases 0-8b completed. No MAC system installed or configured.

2026-04-04

Discovered during domus-digitalis setup failure — prompted broader security posture review

2026-04-04

Confirmed: no LSM active beyond default Yama. No AppArmor, no SELinux, no SMACK.

Symptoms

  • No MAC framework loaded in kernel LSM stack

  • Every user-space process has unrestricted access to all user-owned files

  • npm/node processes (domus-digitalis) can read ~/.secrets/, ~/.gnupg/, ~/.age/

  • Browser processes can access gopass stores, age identities, SSH keys

  • No confinement on Docker daemon or containers beyond default namespaces

Investigation

Verify LSM State

# Check active Linux Security Modules
cat /sys/kernel/security/lsm

Expected on a bare Arch install: lockdown,capability,yama — no AppArmor, no SELinux.

# Check if AppArmor is available in kernel (compiled in but not enabled)
grep -i apparmor /boot/config-$(uname -r) 2>/dev/null || zcat /proc/config.gz | grep -i apparmor
# Check for any AppArmor or SELinux packages installed
pacman -Q apparmor 2>/dev/null || echo "apparmor: not installed"
pacman -Q selinux-utils 2>/dev/null || echo "selinux: not installed"

Findings

  1. No MAC framework active — default Arch kernel ships with AppArmor compiled in (CONFIG_SECURITY_APPARMOR=y) but not enabled at boot

  2. Not in deployment plan — Phases 0-11 of the P16g deploy runbook do not include MAC deployment

  3. Razer has same gap — this is a systemic issue, not P16g-specific (but P16g is the immediate concern as it’s being hardened now)

Root Cause

Technical explanation: The P16g deployment runbook (PRJ-2026-04-p16g-deploy) was authored without a MAC deployment phase. The default Arch Linux installation enables only Yama (ptrace restriction) — no path-based or label-based MAC. This means every process running as evanusmodestus has equal, unrestricted access to all user-owned files including encrypted credentials, age identities, GPG private keys, and gopass stores.

Why it happened:

  • Immediate cause: MAC not included in deployment phases 0-11

  • Contributing factors: Arch Linux does not enable AppArmor by default (unlike Ubuntu/SUSE)

  • Systemic issues: No security hardening checklist exists for workstation deployments — Phase 11 ("Verification") mentions "hardening" but has no specific MAC requirement

Resolution

Immediate Fix

Deploy AppArmor on P16g. See CR: P16g AppArmor Deployment for implementation plan.

Verification

# After AppArmor deployment — verify LSM stack
cat /sys/kernel/security/lsm
# Expected: lockdown,capability,yama,apparmor
# Verify AppArmor is enforcing
aa-status
  • AppArmor in LSM stack

  • Profiles loaded for high-risk applications (browsers, node/npm, Docker)

  • Custom deny profiles for ~/.secrets/, ~/.gnupg/, ~/.age/ access

  • Complain-mode profiles for remaining applications

Impact Assessment

Systems Affected

System Status Impact Duration

modestus-p16g

Exposed

Since 2026-04-02 (ongoing)

Attack Surface (Without MAC)

Threat Vector Unmitigated Risk

Compromised npm package

Full read access to ~/.secrets/, ~/.gnupg/, ~/.age/, gopass stores

Browser exploit

Can exfiltrate SSH keys, age identities, Vault tokens

Malicious Python/Rust crate

Unrestricted file system access within user context

Docker container escape

No AppArmor profile to limit container capabilities

Business Impact

  • Users affected: 1 (personal workstation)

  • Data loss: No (no known compromise)

  • Security posture: Significantly degraded — defense-in-depth missing critical layer

  • Credential exposure risk: Elevated — no process isolation around sensitive stores

Prevention

Short-term (This Week)

  • Deploy AppArmor on P16g — CR-2026-04-04 — Evan Rosado

  • Verify kernel boot parameters include lsm=landlock,lockdown,yama,integrity,apparmor,bpf — Evan Rosado

  • Load complain-mode profiles for all installed applications — Evan Rosado

Long-term (This Quarter)

  • Add MAC deployment as mandatory phase in workstation deployment runbook — Evan Rosado

  • Write custom AppArmor profiles for high-risk apps (node, browsers, Docker) — Evan Rosado

  • Deploy AppArmor on modestus-razer (same gap) — Evan Rosado

  • Create AppArmor profile for Claude Code / npm processes — Evan Rosado

  • Add MAC verification to Phase 11 hardening checklist — Evan Rosado

Lessons Learned

What Went Well

  • Gap discovered during routine setup, not during an actual breach

  • Systematic investigation of domus-digitalis setup failure led to broader security audit

  • Arch kernel already has AppArmor compiled in — remediation path is straightforward

What Could Be Improved

  • Deployment runbook had no security hardening checklist beyond "hardening" bullet point

  • MAC was never part of the Razer setup either — this is inherited technical debt

  • No automated security posture verification exists for workstation deployments

Key Takeaways

  1. Default Arch = no MAC — unlike Ubuntu (AppArmor) or Fedora (SELinux), Arch ships with MAC compiled in but not enabled. Every Arch workstation deployment MUST explicitly enable it.

  2. Secrets on a workstation without MAC is indefensible~/.secrets/, ~/.gnupg/, ~/.age/ are high-value targets. Any compromised user-space process can read them without MAC.

  3. Phase 11 needs teeth — "hardening" as a vague bullet point is not a checklist. Specific, verifiable security requirements must be enumerated.

  4. Audit triggered by unrelated failure — the domus-digitalis .env issue surfaced this. Without that accidental discovery, the gap would persist indefinitely.

Metadata

Field Value

Incident ID

INC-2026-04-04-002

Author

Evan Rosado

Created

2026-04-04

Last Updated

2026-04-04

Status

Draft

Post-Incident Review

After AppArmor deployment verified