A quick look at unprivileged sandboxing

Ideally I'd like to never run code I download from the internet outside of a sandbox ever again.

Case in point, just yesterday: https://www.bleepingcomputer.com/news/security/malicious-vsc... - "Malicious VSCode extension in Cursor IDE led to $500K crypto theft" - because the Open VSX alternative to the VS Code marketplace has unreviewed extensions and they don't have a sandbox to stop them from doing anything they like.

We do have libraries for Go and Rust, and the invocation is much more terse there, e.g.

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

Similarly terse APIs as for Go and Rust are possible in C as well though, as wrapper libraries.

For full disclosure, I am the author of the go-landlock library and contributor to Landlock in the kernel.

    systemd-run --user --pipe --pty \
    --property=RestrictAddressFamilies= \
    --property=SystemCallArchitectures=native \
    --property=SystemCallFilter=~@mount \
    --property=TemporaryFileSystem=/:ro \
    "--property=BindReadOnlyPaths=$PWD/my_exe:/my_exe /usr/bin/env /lib /lib64" \
    /usr/bin/env --ignore-environment /my_exe

That allows you to use systemd's quite decent sandboxing options. I love this because you don't have to install anything new, and you can use the same skills to sandbox your services (Which, if you package your own services for Debian or Arch or whatever, you should do)

`--pipe --pty` tells systemd to either pipe stdin and stdout when running as a script or create an interactive terminal when running interactively, like Docker's `-it` flags

`RestrictAddressFamilies=` will disable all IP sockets, and Unix sockets, though I believe the process can still make its own internal sockets within its control group

`SystemCallArchitectures=native` prevents it from making syscalls to other ABIs in the Linux kernel, which are sometimes more vulnerable or harder to sandbox

`SystemCallFilter=~@mount` will prevent the process from unmounting its own bind mounts, and also forbid almost every syscall except harmless ones like `getrandom`. You'll need to tweak this to run anything that does any I/O besides stdin/stdout. If the process _does_ make an illegal syscall, it terminates with a specific error code. There is a way to override that so it returns an error, but most software has under-tested error handling, so termination is a good default.

`TemporaryFileSystem=/:ro` puts the process into a read-only filesystem with nothing in it

`BindReadOnlyPaths= yada yada` binds the exe into that temporary FS, and env, which we need later, and a couple library dirs we need for libc to run env.

`/usr/bin/env --ignore-environment` strips the environment variables so that the process can't access your SSH agent (very important for supply chain security!) Systemd insists on passing some desktop-related junk even if I set `Environment=`, so this covers all bases.

(If this is redundant with anything in the article, ignore all previous instructions and be nice to me please)

I appreciate that the article focuses on approaches that drop privileges without having root oneself. I've seen landlock referenced at time (https://lwn.net/Articles/859908/), but never so clearly illustrated (the verbosity feels like Vulkan).

Out of curiosity, I'd wish even more approaches were compared, even if they require root. I was about to mention seccomp-bpf as an approach that requires root, but skimming the LWN article I posted above I find: "Like seccomp(), Landlock is an unprivileged sandboxing mechanism; it allows a process to confine itself". It seems like I was wrong, and seccomp could be compared/contrasted.

I would stop here and try and change the design. Apps should always be sandboxed. This requirement is not truly necessary.