# Security Auditor Brief: Kernel Hardening Posture > Technical assessment of Root Lock by HeartSuite HS kernel hardening posture for security auditors and red teams — 6.18.9 primary commercial baseline; measured scores and reproduction commands reference the published 5.19.6 legacy stream until 6.18.9 evidence ships. --- LLMS index: [llms.txt](/llms.txt) --- **Subject:** Root Lock by HeartSuite HS kernel — **6.18.9 primary** (commercial baseline, HeartSuite v1.6.4), **5.19.6 legacy** **Evidence status:** Published config SHA-256, checker output, and runtime verification exist for the **5.19.6** stream only. The **6.18.9** stream is the current commercial baseline (`6.18.9-HeartSuite-1.0`); measured evidence is in progress — see [Evidence Status](evidence-status/). **Primary stream (6.18.9):** [Kernel Hardening Comparison Matrix (6.18.9)](kernel-comparison-matrix-6.18.9/) — structure published; scores pending **Legacy stream (5.19.6):** Config SHA-256 `d67caa637263c33ce939b7eef867f0695d60d11d285d6694a7f5567e73ba6fbc` — measured 2026-05-19, kernel-hardening-checker commit `b9b83a0` — [comparison matrix](kernel-comparison-matrix-5.19.6/), [`evidence-pack-5.19.6.txt`](../evidence-pack-5.19.6.txt) The threat model and measured sections below describe the **published 5.19.6** dataset until `evidence-pack-6.18.9.txt` replaces them. Design intent for 6.18.9 includes disabling `CONFIG_IO_URING` and `CONFIG_KEXEC` (both enabled in 5.19.6). --- ## Threat Model HeartSuite's kernel hardening targets one specific threat: **a process on the protected system attempting to bypass the kernel module's VFS-level enforcement**. The design choice is to remove the kernel features that make bypass possible, rather than to harden the kernel against general exploitation. --- ## What the measurements show ### Attack-surface reduction Automated score: **91/132 (68.9%)** Reference points (era-matched, same 5.19.x kernel generation): Arch linux-hardened 5.19.11: 77/132 (58.3%). Vanilla upstream defconfig 5.17: 90/132 (68.2%). KSPP target (6.17, version-agnostic intent): 131/132 (99.2%). HS outperforms production distros and common hardened-distro kernels on this axis. The reason: HS disables `BPF_SYSCALL`, `USER_NS`, `FUSE_FS`, `OVERLAY_FS`, `APPARMOR`, `TOMOYO`, and ~25 additional network/crypto/debug subsystems that Arch and NixOS keep enabled for their general-purpose user bases. These are the subsystems with the most relevant LSM-bypass CVE history. **Caveat:** the automated checker scores vanilla 5.17 defconfig at 90/132, nearly identical to HS. This is because the checker does not distinguish *intentionally hardened to* a value from *never configured to begin with.* The vanilla defconfig also doesn't enable BPF or AppArmor by default. The operational difference is enforcement: a production system built on a vanilla defconfig will have these features added over time; HS's build procedure enforces the disables regardless. ### Exploit-resistance (KSPP-style mitigations) Automated score: **31/109 (28.4%)** Reference points (era-matched): Arch linux-hardened 5.19.11: 69/109 (63.3%). Vanilla upstream defconfig 5.17: 29/109 (26.6%). KSPP target (6.17): 93/109 (85.3%). HS's exploit-resistance posture is at the vanilla upstream baseline. It does not add `INIT_ON_ALLOC_DEFAULT_ON`, `HARDENED_USERCOPY`, `FORTIFY_SOURCE`, `SLAB_FREELIST_RANDOM`, `KFENCE`, `RANDSTRUCT_FULL`, `KSTACK_ERASE`, `MODULE_SIG`, or the other ~57 KSPP mitigations that dedicated hardened kernels enable. --- ## Residual risks **1. Kernel memory corruption / exploitation** HS provides no additional protection beyond vanilla upstream defaults for heap-based exploits (use-after-free, double-free, type confusion). An attacker who can reach a vulnerable in-kernel code path with sufficient primitive quality has no extra mitigations to contend with beyond `STACKPROTECTOR_STRONG`, `KASLR`, `RANDOMIZE_MEMORY`, and `STRICT_KERNEL_RWX` — all of which are vanilla defaults. *Attack path:* Any reachable kernel vulnerability with reliable heap-layout control. **2. SELinux runtime state — verified permissive** `CONFIG_SECURITY_SELINUX=y` with `CONFIG_DEFAULT_SECURITY_SELINUX=y`. SELinux is compiled-in. Runtime verification on the test VM (2026-05-19) shows: - `/sys/fs/selinux/enforce` = `0` — permissive mode, no policy loaded - `/proc/self/attr/current` = `kernel` — initial context, no confinement active - securityfs is not mounted (no `/sys/kernel/security/lsm` file) SELinux initializes at boot but does not enforce. HeartSuite is the sole enforcing MAC LSM. dmesg confirms HeartSuite is enforcing within 4 seconds of boot. *Residual note for production:* this relies on runtime service configuration keeping SELinux permissive. Verify `cat /sys/fs/selinux/enforce` = `0` on each production deployment. A loaded SELinux policy that flips to enforcing mode would add a competing LSM to the stack. **3. MODULE_SIG not enforced** `CONFIG_MODULE_SIG=n`. Kernel module signing is not enforced. A root-level attacker can load an arbitrary unsigned kernel module, including one that unloads or bypasses HeartSuite's VFS hooks. *Mitigating factor:* Lockdown's `kmod` block (when engaged) prevents loading additional modules post-Lockdown. This is an operator-procedure-dependent mitigation, not a config-enforced one. --- ## How to reproduce these measurements Run on any Linux host with Python 3: ```bash # Clone the checker git clone --depth 1 https://github.com/a13xp0p0v/kernel-hardening-checker /tmp/khc # Obtain the HS config (from the HS 5.19.6 kernel package) # Verify: sha256sum config-5.19.6-HeartSuite-1.0 # Expected: d67caa637263c33ce939b7eef867f0695d60d11d285d6694a7f5567e73ba6fbc # Run python3 /tmp/khc/bin/kernel-hardening-checker -c config-5.19.6-HeartSuite-1.0 # Expected summary: OK - 129 / FAIL - 129 ``` To verify the bypass-primitive disables directly: ```bash grep -E "^(CONFIG_BPF_SYSCALL|CONFIG_FUSE_FS|CONFIG_OVERLAY_FS|\ CONFIG_SECURITY_APPARMOR|CONFIG_SECURITY_TOMOYO)" \ config-5.19.6-HeartSuite-1.0 ``` To verify LSM state on a running HeartSuite VM: ```bash cat /sys/kernel/security/lsm cat /proc/cmdline ```