Linux Security Layer Analysis
Purpose: Security audits and competitive evaluations often group products by vendor category — EDR, SIEM, NDR — without capturing where in the kernel stack enforcement actually happens. This page maps Linux host security products to the enforcement layer they occupy. Layer placement determines bypass surface: a product enforcing at Layer 2 cannot be disabled by a mechanism that only reaches Layer 3 or above.
Layer definitions
| Layer | Name | What lives here |
|---|---|---|
| 1 | Hardware / firmware | CPU microcode, UEFI/BIOS, Secure Boot chain, TPM |
| 2 | Kernel | The running kernel binary and its compiled-in configuration |
| 3 | LSM / kernel hooks | In-tree LSM frameworks, eBPF programs attached to kernel hooks |
| 4 | Userspace sandbox | Agents and runtimes that compose Layer 3 primitives — run as userspace processes |
| 5 | Userspace telemetry / response | Kernel-module or eBPF agents primarily providing detection, alerting, and response |
| Adj. | Complementary controls | Products that answer different questions — no enforcement overlap with Layers 2–5 |
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 product, see Kernel architecture.
Product map
Layer 2 — Kernel-embedded enforcement
| Mechanism | Products |
|---|---|
| Kernel-embedded allowlist / stripped kernel | Root Lock by HeartSuite, custom hardened kernels, unikernels |
| Hardware-virtualized micro-isolation | Firecracker, Kata Containers, Cloud Hypervisor |
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
| Mechanism | Products |
|---|---|
| Userspace syscall-emulating kernel (intercepts container syscalls) | gVisor (sentry process) |
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 by HeartSuite 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)
| Mechanism | Products |
|---|---|
| Mandatory Access Control LSM | SELinux, AppArmor, SMACK, Tomoyo |
| Capability / path-based LSM | Landlock, Yama, LoadPin |
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
| Mechanism | Products |
|---|---|
| eBPF programs attached via KRSI / LSM BPF | Tetragon (Cilium), Cilium network path, KRSI primitives |
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
| Mechanism | Products |
|---|---|
| eBPF detection; optional kill signal | Falco (detection only, no kill), Tetragon (detect + kill), Sysdig Secure |
These products 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
| Mechanism | Products |
|---|---|
| Userspace runtime composing seccomp-bpf, namespaces, cgroups | bubblewrap, Firejail, Flatpak sandbox, Snap confinement, OpenShell (NVIDIA) |
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
| Mechanism | Products |
|---|---|
| Kernel module or eBPF agent: telemetry, detection, response | CrowdStrike Falcon, SentinelOne Singularity, Microsoft Defender for Endpoint, Elastic Defend, Wazuh |
The agent provides detection and response capabilities that Root Lock by HeartSuite 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 products do not overlap with Layers 2–5 enforcement. They answer different questions and should run alongside host enforcement.
| Category | Products | What they answer |
|---|---|---|
| SIEM / SOAR | Splunk, Elastic Security, Microsoft Sentinel, IBM QRadar, Sumo Logic, Graylog, Wazuh, Cortex XSOAR, Tines, Torq | Fleet-wide event correlation, alerting, playbook response |
| NDR / NTA | Darktrace, ExtraHop Reveal(x), Vectra AI, Corelight, Cisco Secure Network Analytics, Arista NDR | Passive network behavioral analysis, lateral-movement detection |
| Vulnerability / posture | Tenable Nessus, Qualys VMDR, Rapid7 InsightVM, Greenbone/OpenVAS, Wiz, Orca, Snyk, Trivy, Grype, Clair | CVE enumeration, patch prioritization, posture scoring |
| HIDS / FIM | OSSEC, AIDE, Tripwire, Samhain | Alert-only file-integrity monitoring, no blocking |
| Backup / recovery | Veeam, Rubrik, Cohesity, BackupPC, restic | Recovery from destructive events — separate category |
Takeaway
Root Lock by HeartSuite 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 product sits at Layer 3 (LSM hooks, eBPF programs) or higher — meaning a sufficiently privileged attacker can disable it remotely without rebooting. The Layer 2 position is what makes physical presence the only bypass path.
For the product-by-product comparison with bypass analysis, see How It Compares.
Feedback
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.