Merge in main

docs/TODO.md

@@ -1037,7 +1037,7 @@ reasonable for a controlled fleet; the highest-assurance path is attended/firmwa
 or manufacturer pre-provisioning. Default recommendation: **separate provisioning
 UKI + isolated VLAN + read-back verify.**
 
-## [ ] 11. (DESIGN) TPM 802.1X identity enrolment (TOFU + OOB fingerprint)
+## [~] 11. (DESIGN) TPM 802.1X identity enrolment (TOFU + OOB fingerprint)
 
 **Authoritative design consolidated 2026-06-28:
 [tpm-enrolment-design.md](tpm-enrolment-design.md)** — unifies this item with the
@@ -1062,7 +1062,9 @@ approve → cert). **BENCH-VERIFY:** run against real step-ca (`bootstrap.sh` ro
 `enrol` provisioner password readable by the broker) and confirm an issued cert
 authenticates EAP-TLS.
 
-**HOST SIDE BUILT 2026-07-02 — Go binary (`fleet-enrol`), awaiting bench.**
+**HOST SIDE BUILT 2026-07-02 — Go binary (`fleet-enrol`); TEST-PATH ENROLMENT
+BENCH-VERIFIED ON REAL HARDWARE (Dell 820, `rd.dot1x=0`, 2026-07-03).** Secure-path
+(802.1X/MACsec) enrolment still to verify — see the NV-index bench finding below.
 Pivoted from a shell hook to a static **Go + go-tpm** binary (`files/enrol/`):
 it talks to `/dev/tpmrm0` DIRECTLY (via `transport.FromReadWriter` on an
 `os.File` — no `linuxtpm`, so go-tpm is the only vendored dep), so the enrolment
@@ -1157,7 +1159,7 @@ have their EK there), so enrolment could never create our key.
   (+ `tpm2_evictcontrol -C o -c 0x81000100` for a stale *app* key — never the EK), or
   BIOS "Clear TPM". Document in the bench README.
 
-**BENCH FINDING 2026-07-03 (FIXED) — NV index `0x01800001` collided with OEM
+**BENCH FINDING 2026-07-03 (FIXED + BENCH-VERIFIED) — NV index `0x01800001` collided with OEM
 platform NV; moved to `0x01800100`.** The Dell 820 kept "finding a cert" and
 bypassing enrolment even after repeated BIOS TPM clears. `tpm2_nvreadpublic`
 showed the truth: `0x01800001` on that hardware is a **firmware/platform** index
@@ -1173,9 +1175,18 @@ through the cmdline (`extract-artifacts.sh`), `fleet-enrol -nvindex`, the dracut
 hooks, bench scripts, invariant #1, and docs. Also **hardened `WriteNVCert`** to
 refuse a `platformcreate` index with a clear "pick a free owner index" error
 instead of a confusing undefine failure (regression `simtest/
-TestWriteNVCertRefusesPlatformIndex`). **BENCH-VERIFY:** 820 now enrols at
-`0x01800100`; and check `tpm2_nvreadpublic` on any OTHER hardware model in the
-fleet — if a vendor also squats `0x018001xx`, pick a value free on all of them.
+TestWriteNVCertRefusesPlatformIndex`). **BENCH-VERIFIED 2026-07-03 — the Dell 820
+enrols end-to-end at `0x01800100`.** First success on REAL TPM hardware (past the
+un-clearable OEM platform-NV at `0x01800001`): validates BOTH the NV-index move
+AND the `0x81000100` key-handle move on a physical TPM, not just the Proxmox
+swtpm — the full host ceremony (ensure ECDSA key → CSR → broker fingerprint →
+approve → leaf cert → NV write) runs on the metal. This was the hard case (the
+820 previously "found a cert" and silently bypassed enrolment every boot). **STILL
+BENCH-VERIFY:** (a) `tpm2_nvreadpublic` on any OTHER hardware model in the fleet —
+if a vendor also squats `0x018001xx`, pick a value free on all of them; (b) the
+enrolled cert actually **authenticates EAP-TLS on the secure path** (this run was
+test-mode `rd.dot1x=0`; 802.1X/MACsec enrolment still unverified — see the
+test-mode note above).
 
 **BENCH-VERIFY (host side, before trusting):** (a) go-tpm against a REAL TPM +
 swtpm on the target (the simulator proves the ceremony, not the device) — **the
@@ -1547,6 +1558,15 @@ tailoring; retires deviation-register #4).
    unchecked-hash` over the Python trees BEFORE the erofs build → mtime-independent
    `.pyc`, no rewrites, and MORE reproducible. (Worth doing regardless of firewalld —
    it's the true root cause of the firewalld AVCs seen 2026-07-03.)
+   **[x] DONE (2026-07-03):** implemented in `diskless.pkr.hcl` — (a) the compileall
+   `--invalidation-mode unchecked-hash` pass over `/usr/lib*/python3.*` at the end of the
+   2d hygiene block (last step before erofs extraction), and (b) masked
+   `dnf-makecache.timer` next to the existing `rhsmcertd` mask (it was the observed ~10-min
+   post-boot trigger that re-imported the dnf Python stack). Confirmed live on a booted host
+   via the overlay audit: `dnf/libdnf/librepo/rhsm` `__pycache__` rewritten at boot+10min.
+   **BENCH-VERIFY:** after a rebuild, no more `.pyc` files appear in the overlay
+   (`find / -xdev -newermt '1980-01-01' -path '*__pycache__*'` empty) and the `lib_t`
+   `.pyc` AVCs stop in the SIEM. Items 1 & 3 (firewalld enablement + tailoring) still OPEN.
 3. **Tailoring:** re-select the 4 firewalld rules.
 
 **THE load-bearing bench gate (why #4 deferred it):** the NVMe/TCP root is an OUTBOUND
@@ -1556,6 +1576,47 @@ default → should, but UNVERIFIED); a reconnect within `ctrl_loss_tmo` re-estab
 *through* the firewall; DHCP renew + MKA keepalives unaffected; SSH in; no AVCs; verity
 hash reproducible. If it drops the root, that is the fleet-wide outage risk — gate hard.
 
+## [~] 17. Cap fapolicyd trust-DB RAM (`db_max_size`) — biggest overlay consumer
+
+**Finding (overlay RAM audit, 2026-07-03, host `cygnus-cruiser-99`):** the writable root
+is `systemd.volatile=overlay` (a tmpfs). Enumerating runtime-written files via the `-T 0`
+trick — every baked file has mtime = epoch, so anything newer is an overlay write:
+
+```bash
+sudo find / -xdev -type f -newermt '1980-01-01' -printf '%b\n' | awk '{s+=$1*512} END{print s/1048576" MiB"}'
+```
+
+showed **124.5 MiB** total, of which **`/var/lib/fapolicyd/data.mdb` = 100 MiB, FULLY
+allocated** (`du` == `du --apparent-size`, not sparse) — **~80% of the entire overlay.**
+fapolicyd's LMDB trust DB is rebuilt at boot onto the tmpfs overlay, so its `db_max_size`
+(MB, in `/etc/fapolicyd/fapolicyd.conf`) is a **fixed RAM reservation**, not a ceiling it
+grows into. The EL9 default is ~100; the minimal+kiosk trust set is a fraction of that.
+
+**[x] DONE (2026-07-03):** `diskless.pkr.hcl` 2c-STIG-postfix now seds
+`db_max_size = 50` into `fapolicyd.conf` BEFORE the `fapolicyd-cli --update` rebuild (so
+the rebuilt db uses the smaller map). Value 50 chosen conservatively — it was fapolicyd's
+upstream default for years and covered a FULL workstation rpmdb (larger than this image),
+so it has real headroom. Reclaims ~50 MiB of overlay RAM.
+
+**[ ] BENCH-VERIFY (STIG-critical — fapolicyd is the writable-overlay exec guard):**
+1. Boot the rebuilt image; confirm kiosk renders, admin SSH (ECDSA) logs in, `sudo`
+   works, and custom binaries (`kiosk-session`, `fleet-hostapi`, `fleet-enrol`) still
+   execute — i.e. the trust DB rebuilt cleanly at 50 MiB with no `MDB_MAP_FULL`.
+   Undersizing bricks exec (login/kiosk) — that's the hard gate.
+2. Re-run the overlay audit: `data.mdb` should now be ~50 MiB and total overlay ~75 MiB.
+3. **Can go lower:** measure the real trust set with `fapolicyd-cli --dump | wc -l` on the
+   booted host; if the content is only ~15–25 MiB, 40 (or less) is safe and reclaims more.
+
+**Secondary lever (free, already in flight):** the trust DB scales with trusted files, so
+the kiosk weak-deps trim (commit `a193dc3`, ~100 fewer packages) shrinks the *actual*
+`data.mdb` content — widening the headroom under `db_max_size`.
+
+**Other overlay consumers noted (not fapolicyd, for context):** Chromium `/dev/shm`
+(~38 MiB, its own tmpfs) + kiosk `/tmp/kiosk-profile` (on the root overlay here — `/tmp`
+is NOT a separate tmpfs, ties to #15's mount separation); `/var/log/{messages,audit}`
+grow unbounded in RAM (audit is local-only) — logrotate caps or SIEM offload on
+long-lived hosts.
+
 ## [~] 18. Slim the image — locale + firmware (biggest erofs-size wins)
 
 **Finding (image-size audit via the 2b `rpm -qa --qf '%{SIZE}'` manifest, 2026-07-03):**

docs/stig-deviations.md

@@ -167,6 +167,87 @@ re-check the verity hash is stable across two builds (same concern as the
 (the module install lives in the STIG-gated provisioner); a non-STIG *enforcing*
 build would still see the AVC.
 
+## 15. Local SELinux policy module `fapolicyd_tmpfs` (added 2026-07-03)
+
+Not a STIG-rule waiver — a **minimal local `allow` module** shipped to close an
+**exec-guard gap** under enforcing SELinux. Source: `files/stig/fapolicyd-tmpfs.te`;
+built + `semodule -i`'d in the 2c-STIG provisioner (right after #14).
+
+**The one rule:** `allow fapolicyd_t tmpfs_t:filesystem getattr;`
+
+**Why:** fapolicyd is the app-allowlisting **exec guard for the writable RAM
+overlay** — dm-verity covers only the read-only erofs lower, so a binary dropped
+into the tmpfs overlay upper is exactly what fapolicyd must catch (this is why we
+KEEP fapolicyd; see "Things that are NOT deviations"). fapolicyd `statfs`'s mounts
+to decide which to watch, and **tmpfs is in its default `watch_fs`**. This image's
+root is `systemd.volatile=overlay`, so `statfs("/")` returns the overlay **upper**
+— a tmpfs (audit: `dev=tmpfs ino=1 name="/"`, `fapolicyd_t → tmpfs_t:filesystem
+getattr`, `permissive=0`, seen 2026-07-03). The shipped policy has no such rule
+(no ordinary host has its root on tmpfs), so under enforcing the `getattr` is
+**denied**, fapolicyd cannot fully mark the tmpfs mounts (`/`, `/tmp`, `/dev/shm`),
+and its guard over the writable overlay is **incomplete** — a real gap, not just
+SIEM noise. An **`allow`** (not `dontaudit`): we *want* fapolicyd to see the tmpfs.
+
+**Scope:** one perm (`getattr`) on one class (`filesystem`), two well-known types.
+Grants no file read/write, only the `statfs` fapolicyd needs to classify + watch
+the mount. **BENCH-VERIFY:** (a) the AVC is gone on an enforcing boot; (b) fapolicyd
+**blocks a non-RPM executable dropped in `/tmp`** (proves the guard now covers the
+overlay tmpfs) while the trusted kiosk/appliance binaries still run; (c)
+**reproducibility** — `semodule -i` rebuilds the policy store, so re-check verity
+hash stability across two builds (same concern as #12/#14). NB: only shipped when
+`enable_stig=true`; a non-STIG enforcing build would still see the AVC and the gap.
+
+**UPDATE 2026-07-03 — the getattr allow alone did NOT close the exec gap; the real
+enabler is `watch_fs`.** Bench test on `comet-beacon-54`: with the `.te` installed
+(AVC gone, `fapolicyd active`, `permissive=0`), a **novel** non-RPM executable in
+`/tmp` (hash NOT in the trust db) still **ran** (`exit=0`). Root cause: the diskless
+root is **overlayfs** (`stat -f /` → `overlayfs`, `/tmp` too), but the shipped
+`watch_fs = ext2,ext3,ext4,tmpfs,xfs,vfat,iso9660,btrfs` has **no `overlay`**.
+fapolicyd marks mounts by fs type, so it never marks the overlay = it intercepts
+**no exec on `/`** — the whole root, `/usr` and `/tmp` alike. So the exec guard was
+effectively **OFF at runtime** on every diskless host. Fix: the 2c-STIG fapolicyd
+step now appends **`overlay` to `watch_fs`** in `fapolicyd.conf` (idempotent) so
+fapolicyd watches the overlay root; trust is path-based (`integrity=none`) so overlay
+paths resolve against the rpmdb trust normally. The `fapolicyd_tmpfs` `.te` above is
+still needed — it supports fapolicyd statfs'ing the overlay's tmpfs upper. **This
+turns app-allowlisting ON for the whole root at runtime for the first time**, so
+**BENCH-VERIFY HARD:** boot + kiosk render + admin SSH + sudo + TPM enrolment all
+still work (nothing legit is untrusted — the 4 custom binaries + rpmdb are trusted),
+a novel `/tmp` binary is now **blocked** (EPERM), and no new AVCs (extend the `.te`
+if any). `enable_stig=false` is the escape hatch if it regresses the boot/secure path.
+
+**VERIFIED 2026-07-04 (build `fapolicyd-tmpfs-12043d3`, host `comet-beacon-54`) —
+enforcing, no false positives.** `fapolicyd active (running)`, `permissive = 0`,
+`watch_fs = ...,overlay` (the fix took), `stat -f / /tmp` → both `overlayfs` (so the
+test hits the overlay rule, not the pre-existing tmpfs one). A novel-hash binary
+(`cp /bin/true /tmp/n; printf '\0' >>/tmp/n`) was **denied**: `bash: /tmp/n: Operation
+not permitted`, `exit=126`, and the audit record confirms fapolicyd did it —
+`type=FANOTIFY ... resp=2` (FAN_DENY) `obj_trust=0` (target not in trust db). The
+**deny sweep was empty** (`journalctl -t fapolicyd -b | grep dec=deny` → nothing),
+i.e. **zero false denials**: kiosk-session/weston/chromium + the NM dispatcher scripts
+all ran trusted; admin SSH + `sudo` worked under `staff_u:staff_r:staff_t`. So the
+exec guard went from **effectively OFF** (pre-fix, overlay unwatched) to **enforcing
+on the whole overlay root** with nothing legit broken. My NM-dispatcher false-denial
+worry did not materialise.
+
+**Scope caveat — this closes the UNTRUSTED-PATH half, not the MODIFIED-TRUSTED-PATH
+half.** With `integrity = none`, trust is by **path**, so watching the overlay blocks
+a *new* file at an *untrusted* path (`/tmp/n`) — proven above. It does **not** catch a
+*trusted* path whose **content** was swapped: writing to e.g. `/usr/bin/bash` triggers
+an overlayfs **copy-up** into the tmpfs upper — same path, new inode, **outside
+dm-verity's coverage** (verity only protects the erofs lower, which is now shadowed) —
+and the path-based rule still trusts it. Closing that residual gap needs either
+`integrity = sha256` (fapolicyd re-hashes at exec, content ≠ trust-db hash → deny; the
+rpmdb backend already carries SHA-256 digests, so it's a one-line `fapolicyd.conf`
+change — cost is per-exec userspace hashing, partly redundant with verity on the
+un-tampered lower) **or** an **un-shadowable `/usr`** so copy-up can't happen at all
+(read-only mount → write fails EROFS, no tmpfs copy is ever created; path-trust becomes
+sound again). The latter is tracked as **TODO #15** ("scope root overlay to per-subtree
+tmpfs — un-shadowable `/usr`") and is the preferred fix since it removes the attack
+surface rather than detecting abuse of it. Requires a write primitive to a root-owned
+path either way (already-privileged context), which is fapolicyd's defense-in-depth
+threat model — not an unprivileged bypass.
+
 ## Things that are NOT deviations (kept / enforced)
 
 - **SELinux enforcing** (`selinux --enforcing`; labels preserved into the erofs).