I want this solved so much - across all of the operating systems I use.

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.

This goes straight into my reference list. Sandboxing a process is confusing on Linux.

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.

Landlock is currently still lacking some wrapper libraries that make it easier to use, in C.

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.

I may be biased but the OpenBSD approach with pledge() and unveil() have been my favorite sandboxing mechanisms of all time due to their simplicity: pledge has really understood that as a developer I want to whitelist an intention, not a specific set of syscalls and options, and unveil is chroot on steroids <3

I happen to be researching this, too.

    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)

It's a little more typical to solve this problem by using whole-program sandboxing and just copying the files you need into the "jail" at startup. This drastically increases the number of solutions you have to this problem, probably improves the rigor of the sandbox, and doesn't infect your code.

This is what happens when "systemd is the devil" is actually taken seriously. All of op's scenario is rather trivially implemented as a systems service or run command.

>During the startup phase of the program, it also needs to read some files outside of that directory -- you can apply the confinement only when that phase is done.

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