What Root Lock replaces — and what it does not

Overview: Root Lock by HeartSuite controls per program whether it can execute, which files it can read or write, and which network connections it can make, including for programs running as root.

Standard operating systems grant these rights to users. Ken Thompson built Unix that way in 1969 on an unused PDP-7 at Bell Labs, designed for a small group of trusted researchers, not for networked infrastructure or a world with malware. Every operating system since inherited the decision unchanged. Until now.

Kernel architecture

graph TB
    Root(["Root attacker"])

    subgraph SL["Standard Linux: runtime layers"]
        EDR["EDR agent\nCrowdStrike · SentinelOne"]
        BPF["eBPF runtime\nFalco · Tetragon · Sysdig"]
        LSM["LSM hooks\nAppArmor · SELinux"]
        K["Kernel binary"]
        EDR --> BPF --> LSM --> K
    end

    subgraph HS["Root Lock: compiled enforcement"]
        HSK["Kernel binary\nenforcement compiled in\nno HS agent to kill"]
    end

    Root -."kill".-> EDR
    Root -."unload".-> BPF
    Root -."set permissive".-> LSM
    Root -."no path".-> HSK

    style EDR fill:#fdd,stroke:#c44
    style BPF fill:#fdd,stroke:#c44
    style LSM fill:#fdd,stroke:#c44
    style K fill:#eee,stroke:#888
    style HSK fill:#d4f4dd,stroke:#2a7a40

Standard Linux security tools are runtime layers an attacker who already has remote root can disable. Root Lock compiles enforcement into the kernel binary itself. The BPF syscall is absent, so there is no eBPF layer to unload, no agent to kill.

Every published Linux kernel CVE comes with the same question: is that kernel feature compiled into your hosts? For the features Root Lock has compiled out, the answer is always no, without patching, without policy, without an agent checking.

Most runtime security tools sit at Layer 3 (LSM hooks such as SELinux and AppArmor) or Layer 5 (userspace EDR agents such as CrowdStrike Falcon and SentinelOne). Root Lock sits at Layer 2: enforcement is compiled into the kernel binary itself, not a program installed in userspace.

An attacker who already has remote root can turn those tools off. They kill the program, unload the module, or set the LSM policy permissive. Sitting at Layer 2 leaves nothing to turn off.

Changing the sealed allowlist takes physical presence or the cloud serial console. SSH is not enough, even as root. What remains is whether Setup Mode approved too much, and whether someone at the console can unseal it.

See Circumvention and recovery. For the full taxonomy with all tools mapped by layer, see Layer Analysis.

Security as economics

For an analysis of attacker cost, defender operational cost, and ROI comparison against SELinux, EDR, Zafran, and CTEM programs, see Security as Economics.

What Root Lock replaces

The comparison below is scoped to preventive enforcement. Telemetry, behavioural analytics, and incident response are in What Root Lock complements. Each tool has a known bypass path. See Circumvention and recovery for detail.

The common pattern. Every tool in this table can be disabled by an attacker who already has remote root. They can kill the security agent, unload the BPF program, or set the LSM permissive.

Root Lock removes that possibility: enforcement is compiled into the kernel and the allowlist is sealed under Lockdown. By design, root has no path to disable enforcement or rewrite the sealed allowlist. See Circumvention and recovery.

Industry pattern (impair defenses). In many ransomware and post-compromise campaigns, attackers disable or impair security tools early. They stop the EDR agent, unload sensors, or weaken host policy first. Then they encrypt the files, or they move to the next machine.

Root Lock is designed so it has no agent process, no BPF program, and no unloadable module to target. The question is no longer whether the agent is still running. It is whether Setup Mode approved too much, and whether someone at the console can unseal it.

Related designs. The idea that even root cannot rewrite the running policy is not unique to Root Lock. Android keeps SELinux policy on a verified, read-only image. FreeBSD can raise securelevel so schg files stay immutable until reboot. Root Lock’s version of that idea is Lockdown: the allowlist is sealed, the kernel refuses the write, and unsealing takes the console or physical presence.

What each tool does best. Bypass surface is one dimension of comparison, not the whole picture. Each tool above retains strengths Root Lock does not replicate.

eBPF observers (Falco, Cilium Tetragon, Sysdig Secure, Tracee, and bpftrace) ship mature rule libraries, Kubernetes-aware context, and fleet-wide runtime telemetry. For behavioural alerting on Kubernetes nodes — particularly autoscaled clusters, where on-host eBPF tooling is not a fit by design — those tools remain the right answer.

They can observe a Root Lock host from adjacent infrastructure via network taps or log forwarding.

Userspace LSM frameworks (AppArmor, SELinux, SMACK, Landlock) offer policy capabilities Root Lock does not replicate: SELinux refpolicy and domain transitions, AppArmor’s distribution-shipped per-application profiles, Landlock’s per-application self-confinement primitive.

Root Lock’s value is the sealed boundary (chattr +i immutability plus a running kernel that refuses runtime changes), not richer policy syntax.

On 5.19.6, CONFIG_SECURITY_APPARMOR is compiled out and existing profiles cease to apply at the first Root Lock kernel boot. On fielded 6.18.9-hs, AppArmor is present in the live LSM list — do not assume profiles disappeared.

seccomp-bpf sandboxes in systemd services, browser sandboxes, bubblewrap, and firejail sit closer to the syscall surface than Root Lock can. A Chromium renderer’s own seccomp filter is genuine defence-in-depth from inside the program; Root Lock does not replace it, and both layers are worth keeping.

gVisor addresses a different threat model: host protected from untrusted guest, via a userspace syscall-emulating kernel. Root Lock addresses workloads protected from compromised root inside the kernel they run on. The two compose: Root Lock as the guest kernel inside a gVisor-isolated container is a coherent stack.

Linux EDR (CrowdStrike Falcon, SentinelOne, Microsoft Defender for Endpoint, FortiEDR) provides telemetry, behavioural analytics, fleet-wide correlation through a SOC console, threat intelligence, and incident response. Root Lock provides none of those.

The honest position is prevention versus detection; most regulated environments run both.

When attackers use legitimate tools rather than new malware (the pattern in most modern breaches), EDR detects the suspicious behavior. Root Lock constrains it differently: even a legitimate tool can only reach the files and network destinations its allowlist entry approves.

EDR agents that deploy via eBPF cannot attach on-host. The BPF syscall is not present on the Root Lock kernel. Under Lockdown, agents that install as kernel modules are blocked without an allowlist entry. That is the same gate that applies to every other program.

Both syslog streams (per-decision enforcement events and aggregated alerts) reach the EDR ingestion pipeline via a single rsyslog forwarding rule, with no external tooling required. Detection and response coverage continues through the log pipeline without an on-host sensor.

Capability-based confinement

Capsicum (FreeBSD) operationalizes the same core thesis as Root Lock: ordinary programs should not have unrestricted default access to the global OS namespace. It is the most architecturally principled approach to that problem outside of Root Lock, and the comparison is worth being direct about.

How Capsicum works. After cap_enter(), any syscall that traverses a global namespace (open() with an absolute path, kill() with a PID) returns ECAPMODE immediately. Default access paths through the OS are severed at the syscall boundary.

Per-FD rights masks then control what operations each open file descriptor permits. The design enforces this directly: no path through the global namespace means no access.

What structural elimination costs. Every sandboxed application, or a wrapper around it, must be rewritten. The application calls cap_enter(), pre-opens every file descriptor it will ever need before that call, and uses openat(fd, …) relative to those FDs thereafter.

Sandboxing OpenSSH under Capsicum required explicit modifications to sandbox-capsicum.c. Libcasper exists specifically to handle operations that cannot be pre-opened (DNS lookups, /etc/passwd reads) via a dedicated delegation channel.

For software you write yourself, the model is clean. For a fleet of existing Linux binaries you did not write, it means modifying every program you want to protect, or not protecting it.

How Root Lock reaches the same goal without application changes. VFS hook points in namei.c, open.c, exec.c, and exit.c intercept path traversal and check the calling process’s allowlist entry against the path.

Network hooks in socket.c check outbound routable connections (both connect() calls and sendto() calls with an explicit destination address) against the program’s IP allowlist. Local IPC over UNIX domain sockets and NETLINK is exempt by design.

Default access paths are filtered rather than severed. Existing Linux binaries run without modification; Root Lock observes what they do and enforces the allowlist against it. Root Lock makes this choice (hook-at-VFS rather than cap_enter-before-first-access) precisely to enable application transparency: no binary needs to be rewritten to be protected.

The Setup Mode gap. Capsicum has no learning phase. Policy lives in application source code, written at development time by the developer who wrote the application. There is no “observe what this binary actually needs at runtime, then derive its allowlist” workflow.

For any environment running software it did not write, which is most production infrastructure, Root Lock’s Setup Mode is the practical path: record what the binary does, review, approve, then lock. Capsicum offers no equivalent.

The policy-integrity gap. Capsicum’s policy lives in the application. After it ships, there is no policy file to edit, so Capsicum never had to protect one from root.

Root Lock’s policy is an allowlist file. An attacker who already has root would want to change it. Lockdown seals that file: the files are immutable, and the kernel refuses the write.

Platform. Capsicum is primary on FreeBSD. Linux support is incomplete. Root Lock targets Linux 5.19.6 and 6.18 natively.

The two designs make opposite choices: modify the application, or maintain a policy database. For a Linux fleet running software you did not write, Root Lock’s approach (maintain the database, get transparency and the full Setup → Lockdown lifecycle) is the one that covers the workload.

Formally verified microkernels

seL4 is the benchmark for machine-checked security guarantees in an OS kernel. Its proofs establish that every syscall behaves exactly as specified, that no information can pass between components without an explicit connection, and that these properties hold in the compiled binary on select platforms.

Root Lock and seL4 share the same goal — prevent programs from reaching resources they were not explicitly granted — and diverge on almost everything else.

How seL4 works. seL4 is a microkernel of roughly 10,000 lines of C backed by machine-checked proofs. Every kernel object (memory region, communication channel, thread control block) is named and accessed through an unforgeable token. A process starts with exactly the tokens its creator delegates, nothing more.

To reach a file, a process must hold a token for that file’s underlying storage. To message another process, it must hold a token for the communication channel. There is no global path namespace to traverse: if you do not hold the token, the kernel rejects the call before any check fires.

What those guarantees require in practice. seL4’s proofs depend on keeping the kernel small enough that every line can be verified (roughly 10,000 lines of C). That means seL4 contains no file system, no network stack, no device drivers. Every service that exists in a standard Linux installation (SSH, package management, web server, any application) must be rebuilt as a userspace component with explicit token grants.

Existing Linux software does not run on seL4 without a full OS porting effort. For a commercial server running standard software, deploying seL4 means replacing the entire software environment, not just the kernel.

How Root Lock enforces the same principle on existing software. Root Lock installs as a modified Linux kernel on a host already running standard software. Root Lock controls whether each program can execute, which files it can read or write, and which network connections it can make. The existing binaries run without modification.

Root Lock observes what each binary does during Setup Mode; you build the allowlist through the Dashboard queues, review and approve, then engage Lockdown. The guarantee is a kernel-enforced allowlist on the software the host already runs.

The Setup Mode gap. seL4 has no learning phase. Token grants are designed at system build time by the developer who builds the system. There is no “observe what this service actually needs at runtime, then derive its policy” workflow.

Root Lock’s Setup Mode is the practical answer for standard infrastructure: run the system, record every access in the Dashboard queues, review and approve, then engage Lockdown. For any environment running standard Linux software, Root Lock’s Setup Mode provides the observe-and-build path that seL4 cannot offer.

The policy-integrity gap. seL4 has no policy file. Authority is the token set. There is nothing to edit after the system is built.

Root Lock’s policy is an allowlist file. An attacker who already has root would want to change it. Lockdown seals that file: the files are immutable, and the kernel refuses the write. seL4 makes authority impossible to forge; Root Lock seals the allowlist after Lockdown engages (see Circumvention and recovery).

Platform. seL4 is not a Linux kernel; standard Linux software requires a full porting effort to run on it. Root Lock targets Linux 5.19.6 and 6.18 and is installed by replacing the kernel on an existing host.

The two approaches make opposite foundational choices: build the OS from a proof up, or enforce on the software stack that already exists. For commercial infrastructure running standard Linux software, Root Lock is the option that ships.

Object-capability operating systems

Fuchsia (Google) is a production operating system built on Zircon, a microkernel where every resource is accessed through an unforgeable handle. Like seL4, its security model is structural: no handle means no access, at the kernel boundary, before any policy database is consulted.

Fuchsia adds two architectural properties that seL4 does not emphasize: per-component private namespaces and cryptographic verification of every executable.

Private namespaces. In Fuchsia, each component receives an explicitly assembled filesystem view: its /svc/, /data/, and /pkg/ entries are handle-routed by the Component Framework. There is no global root filesystem visible to all components.

A compromised component cannot traverse upward to discover paths it was not given handles to; those paths do not exist in the component’s view.

Root Lock enforces on a global Linux filesystem. Root Lock controls whether a program can access a given path, but the path still exists and an access attempt returns an error rather than silence. Root Lock’s global filesystem is what makes existing Linux software run unchanged. That is the same choice that allows deployment on any existing Linux server.

Cryptographic integrity. Fuchsia verifies every executable through BlobFS. Each file is identified by its hash and checked before it runs. Replacing a binary silently is structurally impossible. Root Lock does not do that.

At Lockdown it seals the allowlist and the critical system paths: the files are immutable, and the kernel refuses the write. Full cryptographic verification at boot means building the OS around content-addressed storage from scratch. Lockdown is runtime tamper-resistance on the Linux you already run.

The Setup Mode gap. Fuchsia has no learning phase and no operator-facing allowlist tooling for standard server software, because standard server software does not run on Fuchsia. Root Lock’s Setup Mode records what each binary does; you review and approve through the Dashboard queues, then engage Lockdown. The workflow exists because Root Lock deploys on the software stack already running in production.

Platform. Fuchsia targets embedded devices and consumer hardware. It is not a Linux kernel and has no server deployment path. Root Lock targets Linux 5.19.6 and 6.18 server deployments and is installed by replacing the kernel on an existing host.

Fuchsia’s security architecture is more restrictive at every layer: per-component namespaces, cryptographic verification, handle-only access, userspace drivers. Root Lock provides enforced per-program allowlisting on existing Linux deployments without rebuilding the OS. For any organization running Linux infrastructure today, Root Lock is the option that deploys.

Trust boundaries and bypass surface

Three questions cut to the core of any enforcement mechanism: who is trusted to set the policy, who is gated at runtime, and what does a bypass look like?

graph LR
    A[Attacker gains root] --> B["eBPF agent\n(Falco, Tetragon)"]
    A --> C["LSM framework\n(AppArmor, SELinux)"]
    A --> D["seccomp sandbox\n(bubblewrap, firejail)"]
    A --> E["Linux EDR agent\n(CrowdStrike, SentinelOne)"]
    A --> F["Root Lock"]
    B --> G["Kill agent or\nunload BPF program"]
    C --> H["Set permissive or\nreload policy"]
    D --> I["Launch same binary\nwithout the filter"]
    E --> J["Kill driver or\nBYOVD bypass"]
    F --> K["Physical presence\nrequired"]
    G --> L["Protection disabled ✗"]
    H --> L
    I --> L
    J --> L
    K --> M["Protection intact ✓"]

    style A fill:#fdd,stroke:#c44
    style B fill:#fdd,stroke:#c44
    style C fill:#fdd,stroke:#c44
    style D fill:#fdd,stroke:#c44
    style E fill:#fdd,stroke:#c44
    style G fill:#fdd,stroke:#c44
    style H fill:#fdd,stroke:#c44
    style I fill:#fdd,stroke:#c44
    style J fill:#fdd,stroke:#c44
    style L fill:#fdd,stroke:#c44
    style F fill:#d4f4dd,stroke:#2a7a40
    style K fill:#d4f4dd,stroke:#2a7a40
    style M fill:#d4f4dd,stroke:#2a7a40

The table below answers each question in full for the main enforcement mechanisms alongside Root Lock.

Two differences carry the position. Every mechanism above narrows the runtime trust boundary to a subset of processes: one container, one labelled domain, one process tree, one observed program. Root Lock narrows it to every program via a system-wide allowlist, root included.

Every competitor above can be turned off by an attacker who already has remote root: kill the agent, unload the module, or set the policy permissive. Root Lock has nothing equivalent to turn off.

Changing the sealed allowlist takes physical presence or the cloud serial console. See Circumvention and recovery.

The May 2026 TanStack npm attack illustrated the trust-boundary distinction from the supply chain direction. The attacker operated inside a legitimate build pipeline using valid credentials.

SLSA provenance, OIDC, and 2FA all functioned as designed. No credential check or trust-chain verification registered anything to block.

Root Lock’s per-program network allowlist bounds what pipeline processes can reach from the host regardless of credential validity; connections to unapproved destinations are refused at the kernel.

What Root Lock complements

These tools do not overlap with Root Lock. They answer different questions, and mature security programs run both.

Root Lock makes a class of attacks impossible rather than merely visible. Your SIEM, NDR, and VA scanner work on what remains: a smaller, more focused set of events.

How Root Lock feeds these tools

Block events reach a SIEM via the local journal under identifier heartsuite (written to /dev/log). One rsyslog rule can forward that identifier; how it lands on the wire (RFC 3164 vs RFC 5424) depends on your rsyslog/journald configuration, not on Root Lock.

:programname, isequal, "heartsuite" @@your-siem:514

The enforcement stream emits one record per denial (HS-PROG-DENY, HS-FILE-DENY, HS-FILE-WDENY, HS-NET-DENY). The alert stream carries aggregated events (new_program_blocked, network_burst, and others). Successful allowlisted work is not streamed.

For push notifications, an HTTPS webhook (JSON; native PagerDuty Events API v2 and OpsGenie Alert API adapters) delivers alert-level events only. Webhook and email timestamps reflect alert evaluation time, not kernel event time; when correlating across sources, account for up to the daemon poll interval (typically 30–60 s).

Every allowlist approval action (programs, file paths, and network destinations) is written to a dedicated, persistent JSONL log that records timestamp, uid, and tty. This gives a machine-readable, session-attributable history of policy changes.

An always-on rotating application audit log records UI and core operational events and errors. Lockdown advisories are generated from verdict logic with direct provenance back to the underlying allowlist state and decision records rather than from unfiltered event dumps.

The combination of the per-decision enforcement stream, the dedicated approval log, and the application audit log produces a reconstructible record that security teams and auditors can use to trace what the system did, when, and why.

Agent-based scanners (Tenable Nessus Agent, Qualys Cloud Agent) run as allowlisted programs. Run the scanner during Setup Mode so Root Lock logs its programs and file access paths, then review and approve the entries through the Dashboard queues. Network-based scans from an external host reach the system over its normal network stack without special configuration.

Where a separate kernel is required

Root Lock deliberately omits overlay filesystems, user namespaces, and the BPF syscall because they are the features attackers use to hide, shadow directories, and reach root. Those workloads are not a fit by design. Run them on a separate system, or use the shipped paths below:

• Kubernetes nodes with dynamic container scheduling after Lockdown. Many instances of the same binary are supported, but new mounts for HPA scale-out or rescheduling are refused. Fixed pod sets before Lockdown work via the Container-host install; see Deployment Scenarios.
• Falco, Cilium Tetragon, bpftrace, and similar eBPF tools. The BPF syscall is deliberately absent. This closes the verifier bypass surface and prevents unloading of enforcement. Observe from adjacent hosts via syslog instead. On-host eBPF tooling is not a fit.
• Hypervisor hosts running VMs via KVM. KVM host features are compiled out to reduce attacker reach. Root Lock runs as a guest, not a host.
• Systems that require rootless containers. Unprivileged user namespaces are omitted; they are a path to privilege escalation without credentials. Use a separate host.

See System Requirements → Software Compatibility Notes for the full list.

For CISO and procurement evaluation of the Root Lock kernel itself in enterprise fleets (including operational models, Secure Boot roadmap, and alternatives), see the Kernel Hardening → Enterprise Adoption Guide.

Circumvention and recovery

Every security system has a known way to be taken out of the picture. Being explicit about it is how customers evaluate fit.

Root Lock’s sealed allowlist is intended to change through these operator paths:

1. Maintenance window. You switch to Setup Mode, make changes, and re-engage Lockdown. Logged and intentional.
2. Lockdown recovery. When Lockdown is active, the allowlist is sealed. Remote root cannot edit it. Recovery requires booting the maintenance kernel, using the Dashboard’s Maintenance ([m]) to remove the seal, and rebooting back. Booting the maintenance kernel requires physical or serial-console access: a keyboard and monitor at the machine, a serial port, a BMC (Dell iDRAC, HPE iLO, and similar), a hypervisor serial console, or your cloud provider’s serial console. An attacker without that console path cannot take this route. On a VM, the hypervisor that owns the guest disk and memory is that outer path. The guest kernel cannot police it.

What this means for security:

• Under Lockdown, an attacker who already has remote root cannot defeat enforcement. There is no agent to kill, no kernel module to unload, and no LSM policy to set permissive. There is also no remote way to force a reboot into the maintenance kernel without console access.
• Supported recovery requires physical or serial-console access: a keyboard and monitor at the machine, a serial port, or your cloud provider’s serial console. SSH access alone, regardless of privilege level, is not the recovery path.
• Physical or serial-console access always returns control to you. No software applied to the host can prevent console recovery.
• What can still go wrong (beyond physical or serial-console access). On a large kernel, whether every path is actually gated is still an engineering job. That includes seal and control paths that must stay gated under Lockdown (for example sibling attributes or HeartSuite control entry points), an allowlist that approved too much in Setup Mode, and an already-approved program abused as a deputy.
• Seal and control integrity are product contracts, tested on ship pins; check them on the pin you run. This is a different question than whether an agent is still running.

Compare this to the tools in the first table: in most of them, root can turn enforcement off. They kill the agent, unload the module, or set the policy permissive. Root Lock is deliberately not in that category.

Nothing the attacker ran survives a reboot.

To see the three enforcement mechanisms tested against real attacks, including what happens when attackers stay within approved boundaries, see When Root Isn’t Enough.

Privileged access. SOC 2, PCI DSS, and ISO 27001 each expect the organization to restrict and review privileged access. None of them is a single question of the form “can an administrator remotely disable this product?”

Under Lockdown, remote root cannot modify the sealed allowlist or disable Root Lock the way a userspace agent can be killed. Changing the seal takes physical or serial-console access, to boot the maintenance kernel.

That is one technical activity a customer control may cite. It does not satisfy a TSC, an Annex A control, or a PCI requirement by itself. Examiners still test identity, access reviews, logging, and the rest of the control environment.

For kernel-config notes and residual risk on the fielded pin, see Threat model and residual risk.