Leveraging Landlock telemetry for Linux detection engineering
Landlock is a relatively new Linux Security Module (LSM), integrated into the kernel since version 5.13. Landlock allows the creation of sandboxes for your applications, on top of the existing system-wide access control mechanisms. Essentially, any process, whether you trust them or not, whether they are privileged processes or unprivileged ones, can be restricted, adding a valuable layer of defence-in-depth. Landlock creator listed several open source projects already leveraging Landlock: zathura, pacman, cloud hypervisor, suricata, polkadot, wireproxy, gnome localsearch, xz utils. Several sandbox tools such as FireJail and setpriv have integrated Landlock as well.
Landlock is a great hardening tool that effectively restricts an application’s actions. However, its application is not limited to system hardening, as it also presents significant value for detection engineering. Landlock has been fully integrated within the Audit system since Linux kernel 6.15. No specific audit rule is needed. By default, the execution of new programs via the execve() system call does not generate logs; enabling this behaviour requires passing specific flags to sys_landlock_restrict_self(). A log being raised means two things: The application is not used for its original purpose since it was compiled with these Landlock restrictions. It should never be a false positive since the application was designed at its core with the Landlock restrictions. For detection engineers, this new telemetry opens up new possibilities for crafting precise, behaviour-based detections that can identify threats at runtime with a very low false positive rate. Every violation attempt of the restrictions applied to a program will be logged if the environment variable LL_FORCE_LOG is set to 1. This sets the flag LANDLOCK_RESTRICT_SELF_LOG_NEW_EXEC_ON, allowing the execution of new programs via the execve() system call.
To illustrate Landlock’s logging capabilities, we start our “sandboxer” binary with an interactive “bash” shell, and restrict with Landlock the filesystem permissions to be read-only on the “/” path, and read-write on the “/tmp” path. If we try to write anywhere else other than “/tmp”, the audit logging gives us these raw documented Landlock audit messages: type=UNKNOWN[1423] msg=audit(1764079004.833:1261): domain=1266faee0 blockers=fs.make_reg path="/home/user/sandbox_c" dev="sda1" ino=1183972. The 1423 message code is the following one: #define AUDIT_LANDLOCK_ACCESS 1423 /* Landlock denial */. Similarly to our previous example, we add some restrictions to limit TCP connections to port 443. Then, trying to connect with the “curl” command to “https:google.com” (meaning on port 80). The resulting log event, here for IPv4, is: type=UNKNOWN[1423] msg=audit(1764080735.711:1623): domain=1266faef9 blockers=net.connect_tcp daddr=142.250.179.110 dest=80. With the go-libaudit library, these messages can be reassembled and enriched with system context for detection or hunting.
To read the complete article, see: Leveraging Landlock telemetry for Linux detection engineering
🌟 Join the RISE-USA event on February 18-19: Register here using the password “d7Jf#ga5Pr”!
🌍 Don’t miss RISE-IRELAND on April 14-15: Register here!