Kernel Hardening

• 1: Kernel Hardening Comparison Matrix
• 2: Security Auditor Brief: Kernel Hardening Posture
• 3: Procurement Brief: Kernel Hardening at a Glance
• 4: LSM Comparison: HeartSuite vs SELinux, AppArmor, and TOMOYO
• 5: Analyst Summary: HeartSuite Kernel Hardening

1 - Kernel Hardening Comparison Matrix

Subject: Root Lock by HeartSuite, kernel 5.19.6
Config SHA-256: d67caa637263c33ce939b7eef867f0695d60d11d285d6694a7f5567e73ba6fbc
Tool: kernel-hardening-checker commit b9b83a0, run 2026-05-19
Source file: evidence-pack-5.19.6.txt

Part 1 — Measured comparison (same kernel era)

All three configs below are built from the 5.19.x kernel tree. Checker scores are directly comparable — same Kconfig namespace, same option universe.

Reading the table

• Attack-surface measures how many dangerous kernel features are disabled. Higher = more things turned off.
• Exploit-resistance measures how many defensive mitigations against memory bugs are enabled. Higher = harder to exploit.
• These two axes are largely independent and optimized for different threat models.

What this shows

HS leads on attack-surface (91 vs 77 vs 90): it disables BPF_SYSCALL, FUSE_FS, OVERLAY_FS, SECURITY_APPARMOR, SECURITY_TOMOYO, and USER_NS — all of which Arch linux-hardened keeps enabled for its general-purpose user base.

Arch linux-hardened leads on exploit-resistance (69 vs 31): it enables HARDENED_USERCOPY, FORTIFY_SOURCE, INIT_ON_ALLOC_DEFAULT_ON, INIT_ON_FREE_DEFAULT_ON, SLAB_FREELIST_RANDOM, and MODULE_SIG — all absent in HS 5.19.6.

Vanilla defconfig is the baseline: it does about as well as HS on attack-surface (most things aren’t enabled by default) but even worse on exploit-resistance.

Bypass-primitive disables — side by side

HS: 5/8 disabled. Arch lh: 3/8 disabled (different 3). Neither disables all eight.

Exploit-resistance mitigations — side by side

Part 2 — Qualitative orientation (cross-project)

These projects were not scored with the checker in this analysis — either because their configs were unavailable for the 5.19 era, because they are paywalled, or because a meaningful config was not locatable. Characterizations are drawn from each project’s public documentation and design goals.

Notes on the qualitative table:

• “Bypass Prevention” = removal of subsystems that can circumvent MAC/LSM enforcement.
• “Exploit Resistance” = mitigations against kernel memory bugs (heap, stack, pointer corruption).
• NixOS linux_hardened was removed from nixpkgs in 2025 due to lack of maintenance — it is no longer an active project. The bundled config in kernel-hardening-checker (6.12.50-hardened1) is a historical snapshot.
• CLIP OS: the public CLIP OS project is archived. The ANSSI team published their kernel configs; they are accessible at the archived CLIP OS documentation.
• grsecurity requires a paid subscription; their config is not publicly available for automated analysis.
• GrapheneOS targets Android hardware (aarch64); its hardening is not directly applicable to x86 server deployments.

Part 3 — LSM stack and module count (measured)

Part 4 — CPU mitigations (5.19.6 naming)

5.19.6 uses pre-6.1 option names. Checker reports these as FAIL (uses the 6.1+ CONFIG_MITIGATION_* names). Mitigations confirmed present:

Summary

2 - Security Auditor Brief: Kernel Hardening Posture

Subject: Root Lock by HeartSuite, kernel 5.19.6
Config SHA-256: d67caa637263c33ce939b7eef867f0695d60d11d285d6694a7f5567e73ba6fbc
Measured: 2026-05-19 using kernel-hardening-checker commit b9b83a0
Full data: kernel-comparison-matrix-5.19.6.md, evidence-pack-5.19.6.txt

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:

# 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:

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:

cat /sys/kernel/security/lsm
cat /proc/cmdline

3 - Procurement Brief: Kernel Hardening at a Glance

Subject: Root Lock by HeartSuite, kernel 5.19.6
Measured: 2026-05-19 using kernel-hardening-checker, an independent open-source tool
Full technical data: kernel-comparison-matrix-5.19.6.md

What this document covers

Every Linux kernel ships with hundreds of configuration choices that determine how easy it is to exploit vulnerabilities or escape security controls. This document compares HeartSuite’s kernel choices to a directly comparable community-hardened kernel and the KSPP industry benchmark.

All numbers on this page are outputs of the same measurement tool applied identically to each kernel configuration. No estimates. The Arch linux-hardened comparison uses the 5.19.11 release — the same kernel generation as HeartSuite 5.19.6, making scores directly comparable.

At a glance

KSPP benchmark anchored to kernel 6.17; its version-agnostic recommendations set the de facto industry target but are not directly score-comparable to 5.19.x.

What HeartSuite is optimized for

HeartSuite removes or disables the kernel features that are most commonly used to bypass security controls — not necessarily those used to exploit vulnerabilities.

This means:

• Attacker cannot use BPF to override security decisions at runtime. (Arch linux-hardened keeps BPF enabled; it’s widely used by system tools and container runtimes.)
• Attacker cannot use user namespaces (CONFIG_USER_NS=n) to create a fake root environment. (Arch linux-hardened 5.19.11 keeps user namespaces enabled for container use.)
• Attacker cannot use FUSE or overlay filesystems to confuse path-based enforcement.
• No competing security policies (AppArmor, SELinux at runtime, YAMA, Landlock, IMA, EVM) that could interfere with or be manipulated to weaken HeartSuite’s decisions.

What HeartSuite does not add — and dedicated hardened kernels do:

• Memory initialization on allocation/free (INIT_ON_ALLOC_DEFAULT_ON, INIT_ON_FREE_DEFAULT_ON)
• Bounds-checking on kernel-to-user copies (HARDENED_USERCOPY)
• Compiler-level hardening (FORTIFY_SOURCE, RANDSTRUCT, GCC_PLUGIN_LATENT_ENTROPY)
• Allocator randomization (SLAB_FREELIST_RANDOM, SLAB_FREELIST_HARDENED)
• Kernel stack erasure on syscall return (KSTACK_ERASE)

These mitigations slow down or prevent exploitation of kernel memory bugs. Arch linux-hardened 5.19.11 scores 69/109 (63.3%) on this axis vs HS’s 31/109 (28.4%). HeartSuite 5.19.6 sits at the vanilla upstream baseline for exploit-resistance. For deployments where the primary concern is a compromised process escaping its enforcement boundary — not kernel memory exploitation — HeartSuite covers the relevant threat at the right operating point; the Decision guide below covers when adding exploit-resistance hardening alongside HeartSuite makes sense.

Broader market landscape

Note: NixOS linux_hardened was removed from nixpkgs in 2025 due to lack of maintenance and is no longer an active project. Qualitative characterizations are drawn from each project’s public documentation. Only HS and Arch linux-hardened scores are directly measured and era-matched.

Decision guide

Choose HeartSuite if your primary concern is:

• Preventing a compromised application from escaping its security boundary
• Ensuring no in-kernel feature (BPF, FUSE, namespaces) can be used to bypass your security policy
• Minimizing the total kernel attack surface (9 loadable modules vs. thousands)
• Running a single-purpose security appliance, not a general-purpose server

Consider adding a hardened kernel layer if your concern is also:

• Protection against kernel-level exploitation (heap corruption, use-after-free, ROP)
• Compliance requirements that enumerate specific KSPP mitigations
• Environments where root access cannot be fully constrained

HeartSuite is not a replacement for: network firewalls, application-layer WAFs, SIEM, endpoint detection/response — it operates at the kernel enforcement layer, not at the network or application layer.

Verification

HeartSuite’s kernel configuration is published with a SHA-256 hash. Any qualified security team can reproduce these measurements using the open-source kernel-hardening-checker tool:

Config SHA-256: d67caa637263c33ce939b7eef867f0695d60d11d285d6694a7f5567e73ba6fbc
Tool: https://github.com/a13xp0p0v/kernel-hardening-checker (commit b9b83a0)

Full methodology and raw data: evidence-pack-5.19.6.txt

4 - LSM Comparison: HeartSuite vs SELinux, AppArmor, and TOMOYO

Subject: Root Lock by HeartSuite, kernel 5.19.6
Audience: Security engineers familiar with SELinux, AppArmor, or TOMOYO evaluating HeartSuite for containment or appliance deployments.

The core distinction

SELinux, AppArmor, and TOMOYO all answer the same question: given that a kernel feature is present, what should a process be allowed to do with it?

HeartSuite answers a different question: which kernel features should exist on this system at all?

This is not a claim that one approach is universally superior. For single-purpose containment appliances, removing bypass primitives from the kernel is more reliable than writing policy around them — because policy can be misconfigured, and because certain primitives (BPF, FUSE, overlayfs) can defeat any MAC policy regardless of how carefully it is written.

Comparison Table

Bypass primitives: open vs closed

The table below lists the kernel-level bypass vectors most relevant to MAC enforcement. “Closed” means the kernel option is disabled — the attack vector does not exist on the system. “Open” means the feature is present and policy must account for it.

An attacker who can reach any “Open” primitive has a path to bypass LSM enforcement regardless of how well the policy is written. HeartSuite closes all four vectors above at the kernel config level.

When SELinux, AppArmor, or TOMOYO is the right choice

HeartSuite is not a general-purpose MAC replacement. Choose SELinux, AppArmor, or TOMOYO when:

• You are running a general-purpose multi-user system where diverse workloads need fine-grained per-process policy.
• You require MLS / MCS (Multi-Level Security / Multi-Category Security) for labeled data separation.
• You need container runtime support that depends on USER_NS or overlayfs (Kubernetes, Docker, Podman, LXC).
• Your compliance framework mandates a specific named LSM (e.g., STIG-mandated SELinux).
• You need to audit permitted accesses, not just denials — HeartSuite logs every denied file access, socket connection, and sandbox violation with the specific program path and target resource, but successful accesses are not logged. SELinux and TOMOYO can record both. If a full allowed-access trail is also required, SELinux can run alongside HeartSuite on supported deployments — see Co-existence.

When HeartSuite is the right choice

Choose HeartSuite when:

• You are deploying a single-purpose appliance running one or a small set of known workloads.
• Your threat model centers on containment escape — a compromised application attempting to break out of its enforcement boundary.
• You want zero policy surface — no policy file, no audit2allow, no profile to misconfigure.
• BPF tooling, container runtimes, FUSE mounts, and user namespaces are not part of the system’s attack surface — they are absent from the kernel, not restricted by policy.
• You want a violation-focused audit trail: every denied file access, network connection, and sandbox violation is logged with the specific program path and target resource. In Setup Mode, would-be denials are logged and permitted simultaneously — giving full visibility into the policy surface without blocking anything.
• You want independent verifiability: the kernel config SHA-256 is published and measurements are reproducible with an open-source tool.

Co-existence

HeartSuite does not stack with AppArmor or TOMOYO. Both are kernel-disabled (CONFIG_SECURITY_APPARMOR=n, CONFIG_SECURITY_TOMOYO=n).

SELinux behaves differently depending on the deployment OS:

HeartSuite’s VFS hooks fire before the LSM chain (security_path_*() calls). The ordering means:

• If HeartSuite denies an operation → the SELinux hook is never reached. HeartSuite is the first and final authority on that call.
• If HeartSuite allows an operation → SELinux can still deny it. SELinux can only add restrictions to what HeartSuite allows, never grant access HeartSuite denies.

This is intentional and safe. On RHEL/Fedora, SELinux is Enforcing by default; the stacking is additive, not conflicting. On Debian/Ubuntu, no SELinux policy is loaded by default. Either way, HeartSuite’s enforcement cannot be bypassed via the SELinux layer.

RHEL operational note: As with any new kernel module on RHEL, a targeted SELinux policy entry may be needed for HeartSuite’s specific operations. If AVC denials appear, ausearch -m AVC -ts recent | audit2why identifies them and audit2allow generates the targeted module. HeartSuite’s enforcement is unaffected — SELinux operates after HS in the hook chain and cannot override HS decisions.

Further reading

• Comparison Matrix — Measured kernel-hardening-checker scores: HeartSuite vs Arch linux-hardened vs vanilla defconfig.
• Auditor Brief — Residual risks, threat model, and self-reproduction instructions.
• Procurement Brief — Decision guide for buyers choosing between hardened kernel options.

5 - Analyst Summary: HeartSuite Kernel Hardening

Kernel: Root Lock by HeartSuite 5.19.6. Config hash: d67caa637263c33ce939b7eef867f0695d60d11d285d6694a7f5567e73ba6fbc. Measured: 2026-05-19.

HeartSuite’s Linux kernel contains just 9 loadable modules — compared to 3,500 to 4,000 in a standard Debian Linux system. This isn’t because the system is less capable; it’s because the kernel was built for one job and nothing else was included.

The approach extends beyond raw module count. HeartSuite disables specific kernel features that security researchers have identified as the most common paths for bypassing security controls: BPF (a programmable kernel interface), FUSE (user-space filesystems), overlay filesystems, and all competing security policy engines including AppArmor and SELinux. Each of these has been used in documented real-world attacks to escape software sandboxes or override security policies.

On an independent audit using the open-source kernel-hardening-checker tool — the same tool used by Linux kernel security researchers — HeartSuite’s kernel outperforms the Arch Linux hardened kernel on attack-surface measures: 91 out of 132 checks passed by HeartSuite versus 77 out of 132 for Arch linux-hardened (compared on the same 5.19.x kernel generation, making scores directly equivalent). Arch linux-hardened scores lower on this axis because it keeps features like BPF, FUSE, and AppArmor enabled — features that its general-purpose users depend on, but that also provide paths for bypassing security controls.

Where HeartSuite is not strongest: Exploit resistance. When a kernel vulnerability is discovered — a memory bug, a logic flaw — certain protection techniques make it much harder to turn that bug into a working attack. HeartSuite’s kernel does not include most of these techniques, scoring 31 out of 109 checks on this measure. The era-matched Arch linux-hardened kernel (same kernel generation) scores 69 out of 109 on the same tool. HeartSuite is designed to prevent attacks from bypassing its controls — not to harden against every possible kernel vulnerability.

The configuration is publicly verifiable. The SHA-256 hash of the kernel configuration file is published, and any qualified security team can reproduce the measurements above using publicly available tools.

For fact-checkers: All numbers in this summary derive from evidence-pack-5.19.6.txt and kernel-comparison-matrix-5.19.6.md in this same document section. Tool: kernel-hardening-checker at commit b9b83a0. Every claim can be independently reproduced.