LandLock is a Minor LSM intended for software developers. They incorporate it into their source code to limit where the programs may read/write. Here's a simple Go example:
package main
import (
"flag"
"fmt"
"github.com/landlock-lsm/go-landlock/landlock"
"io/ioutil"
"log"
"os"
)
// simple program that demonstrates how landlock works in Go on Linux systems.
// Requires 5.13 or newer kernel and .config should look something like this:
// CONFIG_SECURITY_LANDLOCK=y
// CONFIG_LSM="landlock,lockdown,yama,loadpin,safesetid,integrity,apparmor,selinux,smack,tomoyo"
func main() {
var help = flag.Bool("help", false, "landlock-example -f /path/to/file.txt")
var file = flag.String("f", "", "the file path to read")
flag.Parse()
if *help || len(os.Args) == 1 {
flag.PrintDefaults()
return
}
// allow the program to read files in /home/user/tmp
err := landlock.V1.RestrictPaths(landlock.RODirs("/home/user/tmp"))
if err != nil {
log.Fatal(err)
}
// attempt to read a file
bytes, err := ioutil.ReadFile(*file)
if err != nil {
log.Fatal(err)
}
fmt.Println(string(bytes))
}
I feel like I need to ask; did you write this comment and the code example yourself, or did you ask an AI to generate it? If it's AI, why didn't you disclose it? If it's the former, why the weird formatting etc instead of linking to one of the official examples at https://github.com/landlock-lsm/go-landlock/blob/main/exampl... ?
I don't understand why someone would wrap an untrusted application with their own code vs using something like Systemd's exec capabilities to do the same without having to have a binary wrapper. What benefits do you see over the systemd solution?
Systemd's exec capabilities are great, but don't allow the application developer to dynamically restrict access rights to resources. So you could restrict a text editor for instance to the file it was launched to edit, instead of a hardcoded directory.
