Landlock LSM: Secure Linux Apps ohne root-Rechte

Landlock LSM: Secure Linux Apps ohne root-Rechte

Imagine downloading an application and running it without restriction – the tool instantly gaining full access to your entire home folder, cryptocurrency wallet, or even internal corporate files. This is still possible in most standard Linux environments. We blindly trust applications while our system remains vulnerable. But this era could soon be over.

The innovative technology Landlock enables programs to be securely sandboxed without requiring root privileges. It's a new Mandatory Access Control (MAC) feature integrated into the Linux kernel as a Loadable Security Module (LSM). Landlock allows each user to create sandbox policies defining which files and network resources an application may use. No complex SELinux policies, no deep system changes – just clean, user-defined sandboxing.

Why traditional sandboxing solutions fail:

Various approaches have been used over the years to restrict apps: AppArmor, SELinux, Firejail, Flatpak sandboxes. However, all these tools have a major drawback – they either require root privileges or are extremely complex to configure. In typical developer setups or multi-user systems, this means either trusting software completely or investing hours in security configurations.

With Landlock, this paradigm changes. Any user can create their own sandbox policies without needing administrator rights, which is revolutionary for those working with untested software like penetration testers, plugin developers, or simply opening suspicious documents.

Example 1: Simple Filesystem Restriction with landlock-confined:

The landlock package includes practical tools like landconfine that demonstrate how easy the use case becomes:

# Creates a temporary sandbox with restricted file access

# Only /tmp and /usr/share/icons may be read

landconfine --no-net --files = /tmp,/usr/share/icons -- firefox

In this example, Firefox starts with significantly reduced attack surface. The browser can only access temporary data and icons - no personal files, no config folders. Even if a vulnerability in the browser is exploited, the damage remains localized. Personally, I find this approach groundbreaking. I've battled complex container solutions for simple isolation. Landlock makes it trivial.

Under the hood: How Landlock works:

Landlock operates through a multi-tier Enforcement Mechanism. First, an Access Rights Map is defined, precisely determining which operations are allowed. Then hierarchical rules (Rulesets) are created, linking paths and their permissions. Finally, the Ruleset is activated via Syscalls (landlock_restrict_self). The magic happens in the kernel: Every file access attempt is checked against the active rules. If something doesn't match, the application simply receives "Permission denied" - without any external tool involved.

Example 2: Manual Sandbox with landlock(2) syscall:

For those who want more control, they can use the C library liblandlock. Here's a minimalist Python example with ctypes:

import ctypes

import os

# Load liblandlock

lib = ctypes.CDLL(liblandlock.so.1)

# Define Rule: Only /home/user/documents readable

path_bstr = b"/home/user/documents"

rules = [(path_bstr, ctypes.c_uint64(0x0001))] # READ permission

# Create handle for Ruleset

handle = lib.landlock_create_ruleset(rules, len(rules), None)

# Apply restrictions to current process

lib.landlock_restrict_self(handle, 0)

os.close(handle)

# Now this Python process is sandboxed!

print("Landlock activated. Attempts to read outside the allowed path...")

This code demonstrates how to programmatically build a sandbox around your own process. Ideal for scripts that temporarily work with sensitive data but shouldn't see anything else afterward. My assessment: This low-level API opens doors for frameworks that can automatically implement sandboxing - think Jupyter Notebooks or CI/CD agents that need to run isolated.

Network restrictions added in kernel 6.3:

Originally, Landlock only restricted the filesystem. With kernel 6.3, network permissions were added, allowing complete control over socket operations. An application can now be completely disconnected from the internet while still accessing local files.

Example 3: Combination of File and Network Restrictions:

# Starts a text editor completely offline

# Allows only write access to /home/user/docs, blocks all network access

landconfine --net = none --files = /home/user/docs:rwx -- nano report.txt

This combination is perfect for redacted document editing. Even if malware is accidentally run, it can't send data outside. What I find exciting is the granularity. You can precisely control whether TCP, UDP or Unix Domain sockets are allowed, even in partially networked environments.