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 |
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
-
No MAC framework active — default Arch kernel ships with AppArmor compiled in (
CONFIG_SECURITY_APPARMOR=y) but not enabled at boot -
Not in deployment plan — Phases 0-11 of the P16g deploy runbook do not include MAC deployment
-
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 |
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
|
Related
-
CR: P16g AppArmor Deployment — Remediation change request
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 |