Go-Landlock

Landlock is a Linux kernel feature (introduced in Linux 5.13) that provides an unprivileged sandboxing mechanism. It allows a process to restrict its own access to:

• Filesystem access
• Some network operations
• Some IPC operations

Go-Landlock provides a Go interface to leverage these kernel capabilities for easier unprivileged sandboxing.

Because Go is multithreaded and goroutines dynamically map to OS threads, Landlock policies cannot be applied to a single thread reliably. To ensure security, the Go-Landlock API always enables the given Landlock policy for the entire process rather than just the calling thread.

Depending on the kernel version, Go-Landlock uses one of two mechanisms to achieve this:

1. ABI V8+ (Linux 7.0+): Uses the LANDLOCK_RESTRICT_SELF_TSYNC flag via the landlock_restrict_self system call.
2. ABI < V8: Uses the libpsx library to execute the system call on every OS thread in the process.

For cgo programs, libpsx intercepts pthread calls to ensure all threads (including those not started by the Go runtime) are covered using Unix signals.

You can build reusable libraries of Landlock rules using landlock.CompositeRule. This allows you to bundle multiple rules into a single landlock.Rule object, avoiding manual list appending when constructing rulesets.

Note that calling landlock.CompositeRule() with no arguments creates an empty composite rule, which acts as a no-op and adds nothing to the Landlock ruleset at the C API layer.

// DNSLookup bundles the Landlock rules required for basic DNS lookup.
func DNSLookup() landlock.Rule {
  return landlock.CompositeRule(
    landlock.RODirs("/etc"),
    landlock.ConnectTCP(53),
  )
}

To sandbox a Go program using Landlock, call landlock.V10.BestEffort().RestrictPaths(...) after your program has completed its initialization work. This method allows you to define specific directory permissions, such as read-only (RODirs) or read-write (RWDirs). Once invoked, the program is restricted to only accessing the specified paths.

err := landlock.V10.BestEffort().RestrictPaths(
    landlock.RODirs("/usr", "/bin"),
    landlock.RWDirs("/tmp"),
)

To onboard a program to Landlock, perform a threat model analysis of all inputs the program reads and processes. Distinguish between inputs controlled by the calling process (considered safe) and attacker-provided inputs (must be processed within the sandbox).

Threat Model Checklist:

• stdin
• Input files explicitly opened by the program
• Configuration files
• Configuration files used by libraries
• Incoming network requests
• Responses to outgoing network requests

To ensure a secure and functional sandbox, structure your program startup as follows:

1. Open safe inputs first: Open and process configuration files or other trusted inputs before Landlock enforcement. File descriptors opened before enforcement remain valid and usable after enforcement.
2. Enforce Landlock: Apply the narrowest possible sandboxing policy.
3. Process attacker-provided inputs: Handle untrusted data only after the sandbox is active.

If the program only processes a fixed number of attacker-provided files, you can open them before enforcement and begin reading them after enforcement is active.

Landlock provides presets for common filesystem access patterns. Use these to simplify policy creation:

• landlock.ROFiles: Read-only access to files.
• landlock.RODirs: Read-only access to directories.
• landlock.RWFiles: Read-write access to files.
• landlock.RWDirs: Read-write access to directories.

Advanced Filesystem Requirements:

• Linking/Renaming across directories: If your program needs to link or rename files across different directories, you must grant the LANDLOCK_ACCESS_FS_REFER right using FSRule.WithRefer(). Note that this requires Landlock ABI V2 or higher.
• Device IOCTLs: If your program needs to invoke IOCTLs on newly opened device files, you must specifically grant that access right using FSRule.WithIoctlDev().

Landlock's ability to restrict network access is limited. For comprehensive network sandboxing, you should augment Landlock with other mechanisms like Seccomp-BPF.

Known Limitations:

• Non-TCP protocols: A variety of protocols outside of TCP are currently not restrictable by Landlock.
• Multipath TCP: The bind() operation for Multipath TCP is not yet restrictable, though resulting TCP servers remain backwards compatible with vanilla TCP clients.