Linux EDR sensor overview

What this page is

This page is the entry point for the Linux endpoint detection and response sensor. It maps the crate layout to the architecture document and the ADRs, names the staged delivery, and points engineers at the per-component pages.

Why it exists this way

The sensor ships in six staged items per ADR 007. Each item lands as one feature commit so reviewers see the incremental contract: wire types first, then eBPF, then transport, then response actions, then triage, then tamper resistance. Section 7 of the architecture document is the long-term design source of truth; the ADR is the staging plan.

How it works

The sensor lives at crates/edr-linux/ in the Rust workspace, with the kernel-side eBPF code under crates/edr-linux-ebpf/. The user-space daemon links the eBPF object via include_bytes! from OUT_DIR; the build script in crates/edr-linux/build.rs invokes the nightly toolchain pinned by ADR 008 to cross-compile the eBPF crate.

Six modules implement the staged items:

Item	Module	Owner page
1	enrollment	scaffolded with the crate
2	capabilities	scaffolded with the crate
3	runtime, loader, ocsf	eBPF runtime, Network scan detection
4	transport, buffer	Transport and buffer
5	isolation, triage	Host isolation, Live triage
6	guard, update	Tamper resistance

Item 3 originally carried process-execution telemetry only. ADR 044 extends it with network-connection, file-access, and DNS-query events, each on its own ring buffer and OCSF normaliser. The inbound-connection capture that drives scan detection is documented on the Network scan detection page.

Each module is cfg-gated to target_os = "linux" so non-Linux developer hosts (macOS, Windows) still pass cargo check against the crate, which is important because the cross-crate APIs in capabilities, enrollment, and proto are imported by the central Collector code path.

Operational stack notes

The sensor depends on a kernel built with CO-RE eBPF support and the BTF info exposed at /sys/kernel/btf/vmlinux. The minimum kernel release is encoded in loader::MIN_KERNEL_VERSION; KernelInfo::probe_running_kernel checks at startup and refuses to load on older kernels.

The mTLS material (CA chain, sensor client cert, sensor client key) is provisioned during enrollment per enrollment::EnrollmentResponse and stored on disk inside a 600-mode directory the daemon owns.

The default Collector endpoint is https://collector.frankfurt.example:9443 and is overridden per fleet at enrollment time.

What goes wrong

• loader::LoaderError::KernelTooOld, kernel below the floor recorded in MIN_KERNEL_VERSION. The daemon exits; enrolment retries are pointless until the host is upgraded.
• transport::TransportError::Connect, the Collector is unreachable or refusing mTLS. Sensor falls into the offline ring buffer (500 MB by default per Transport and buffer). No telemetry is lost unless the offline window exceeds the buffer's capacity.
• isolation::IsolationError, nftables CLI returned non- zero. Most common cause: nft is not installed on the endpoint. The isolation request fails fast and the analyst sees the typed error in the operator console rather than a generic "command failed".