ES1.6 Linux Kernel and eBPF for Security

The Linux process model from a security perspective

Linux processes share fundamental concepts with Windows but differ in important security-relevant ways. Every Linux process has a PID, a parent PID, a UID/GID (the user and group identity), a set of capabilities (fine-grained privileges), and a namespace context (which determines what the process can see — PID namespace, network namespace, mount namespace).

The security-relevant differences from Windows: Linux uses UID 0 (root) as the superuser with no equivalent to Windows’ token-based privilege model — root can do everything. Linux capabilities provide fine-grained privilege decomposition (CAP_NET_RAW for raw socket access, CAP_SYS_PTRACE for debugging other processes, CAP_SYS_ADMIN for broad administrative operations) but most software runs as root rather than with minimal capabilities. Linux namespaces provide process isolation — a process in a separate PID namespace cannot see processes in other namespaces, which is how containers achieve process isolation. But namespace isolation is not security isolation — a container escape moves from the container’s namespaces to the host’s namespaces, gaining visibility of all host processes.

For endpoint security, the key concept is that Linux privilege escalation often means going from a non-root user to root (UID 0). The paths include: exploiting SUID binaries (executables that run with the file owner’s permissions regardless of the calling user), abusing sudo misconfigurations (sudo rules that grant more access than intended), exploiting kernel vulnerabilities (DirtyPipe, DirtyCow, container escape CVEs), and misconfigured capabilities (a process with CAP_SYS_ADMIN can perform most administrative operations).

eBPF: the kernel-level visibility revolution

eBPF allows small, verified programs to run in the Linux kernel at specific hook points — system call entry/exit, network packet processing, file system operations, scheduler events. The eBPF program observes the event, collects data (process ID, command line, file path, network destination), and sends it to a user-space program for processing and alerting. The eBPF verifier ensures the program cannot crash the kernel, create infinite loops, or access unauthorized memory.

For endpoint security, eBPF provides what ETW provides on Windows: real-time visibility into kernel operations without modifying the kernel itself. Defender for Linux’s mdatp agent uses eBPF to monitor process execution, file access, and network connections on Linux endpoints. Falco (from the CNCF) uses eBPF to detect runtime anomalies in containers and Kubernetes environments. Tracee (from Aqua Security) uses eBPF for security event tracing and forensics. Tetragon (from Cilium/Isovalent) uses eBPF for security observability and enforcement.

The eBPF advantage over traditional approaches: real-time observation (events are captured as they occur, not parsed from logs after the fact), kernel-level visibility (the eBPF program sees system calls before they execute, not just the results), low overhead (eBPF programs run in kernel space with verified safety guarantees), and no kernel module risk (eBPF programs are sandboxed — they cannot destabilize the kernel the way traditional kernel modules can).

Namespaces and cgroups: the container security foundation

Linux containers (Docker, Kubernetes pods) use two kernel features for isolation: namespaces (which control what a process can SEE) and cgroups (which control what a process can USE). Understanding these mechanisms matters for endpoint security because container escape — an attacker breaking out of a container to reach the host — targets the boundaries that namespaces and cgroups enforce.

Namespaces provide isolation for: PID (the container sees only its own processes, not host processes), Network (the container has its own network stack, IP addresses, and routing), Mount (the container sees only its own filesystem, not the host filesystem), User (the container can have its own UID/GID mapping, allowing root inside the container without root on the host), and IPC/UTS (inter-process communication and hostname isolation). An attacker inside a container with properly configured namespaces cannot see host processes, access host network interfaces, or read host files — unless they exploit a namespace escape vulnerability.

Cgroups (control groups) limit resource consumption: CPU time, memory usage, IO bandwidth, and device access. For security, cgroups prevent a compromised container from consuming all host resources (denial of service) and restrict which host devices the container can access (preventing direct disk or device access that could bypass namespace isolation).

Container escape techniques target namespace boundaries: mounting the host filesystem into the container (if the Docker socket is exposed inside the container), exploiting kernel vulnerabilities that allow namespace transitions (the kernel is shared between all containers and the host), and abusing misconfigured capabilities (CAP_SYS_ADMIN granted to the container provides near-root host access). eBPF-based detection tools (Falco, Tracee, Defender for Linux) detect container escape attempts by monitoring: system calls that cross namespace boundaries, capability usage that exceeds the container’s expected profile, and file access patterns that indicate host filesystem access from within a container.

At NE, the 6 RHEL manufacturing servers do not run containers. The 2 Ubuntu web servers may run containerized web applications. If containers are deployed, the endpoint security architecture extends to: eBPF-based runtime monitoring for each container, namespace and cgroup configuration verification through OSQuery (ES11.9), and Sysmon for Linux capturing process and network events with container context (Event ID fields include the container ID).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# Check kernel version (eBPF requires 4.15+ for BPF, 5.8+ for full features)
uname -r

# Check if BPF is enabled in the kernel
cat /boot/config-$(uname -r) | grep CONFIG_BPF

# Check for eBPF-related mounts
mount | grep bpf

# If Defender for Linux is installed, check its sensor mode
mdatp health --field real_time_protection_subsystem 2>/dev/null
# Should show "ebpf" for eBPF-based monitoring

eBPF programmes for security: how they work

An eBPF programme attaches to a kernel hook point (a specific system call, a network event, a scheduler event) and executes a small, verified programme every time that hook point is triggered. The programme can: read kernel data structures (process information, file descriptors, network socket state), filter events (only report events matching specific criteria), and send data to user-space (where the security tool processes it).

The verification step is critical: before an eBPF programme loads, the kernel’s BPF verifier checks that the programme: terminates (no infinite loops), does not access out-of-bounds memory, does not dereference null pointers, and does not call unauthorised kernel functions. This verification guarantees that the eBPF programme cannot crash the kernel or cause data corruption — making eBPF fundamentally safer than loadable kernel modules (LKMs), which can do anything the kernel can do without verification.

For Defender for Linux, the eBPF programmes attach to: tracepoints for process creation (sched_process_exec) and termination (sched_process_exit), kprobes for file system operations (vfs_open, vfs_write), and network hooks for socket operations (tcp_connect, inet_sendmsg). Each programme captures the event data (process ID, user ID, file path, destination IP) and sends it to the mdatp user-space daemon for processing and transmission to the MDE cloud. The result: kernel-level visibility equivalent to what Windows provides through ETW, but using a fundamentally different mechanism that is more secure (verified programmes) and more flexible (eBPF programmes can be updated without kernel recompilation).

Troubleshooting

“Defender for Linux’s mdatp shows real_time_protection_subsystem as ‘fanotify’ instead of ’ebpf’.” The mdatp agent falls back to fanotify (a file access notification mechanism) when eBPF is not available — typically because the kernel version is too old or eBPF kernel modules are not loaded. Check the kernel version (needs 5.8+) and ensure the BPF kernel config options are enabled. Upgrading to a supported kernel version enables the eBPF subsystem, which provides more comprehensive monitoring than fanotify.

“We deployed auditd rules but the audit.log is growing at 2GB per day.” Auditd rule scope is likely too broad. Audit all syscalls (audit -a always,exit -S all) generates enormous volume. Target specific high-value syscalls: execve (process execution), connect (network connections), open/openat (file access to sensitive paths), init_module/finit_module (kernel module loading). Module ES13 provides tuned auditd configurations for security monitoring.