REFERENCE

Scope & Limitations

What LinSentry audits, and the structural limits it shares with every configuration-based auditor.

Kernel-level rootkits (LKM rootkits / syscall hooking)

If an attacker loads a malicious kernel module, they can hook the syscalls that ps, ls, netstat, /proc, and ss all rely on. The rootkit hides its own process, its open ports, its files — from every one of those tools, system-wide.

LinSentry's checks all work by asking the OS for information, using those same binaries. If the kernel is lying to userspace, LinSentry inherits the lie — the entire trust chain (script → syscall → kernel → truth) is broken at the root.

What actually helps: kernel integrity tools like IMA/EVM, offline analysis (booting from a clean trusted medium and comparing), eBPF-based runtime monitors, or memory forensics (Volatility).

Supply-chain compromise inside legitimately installed packages

This is the pattern behind incidents like the 2024 xz-utils backdoor: malicious code deliberately inserted into a trusted, signed package by a compromised maintainer or build pipeline. File permissions are correct. The package manager says it's verified.

Every check that looks at configuration and access control passes — because the malicious code isn't a config error, it's logic hidden inside a binary that's supposed to be there. A permissions/config auditor has no mechanism to evaluate what a binary does. That requires reproducible builds, SBOM (software bill of materials) tracking, or binary/behavioral analysis — a different category of tool entirely.