If I understand it correctly, landlock is an API used by an app to sandbox itself. The app itself controls the sandboxing. Bubble wrap is user space tooling external to the app, so the app had no direct awareness or control of its sandboxing. The scenarios each is intended for are orthogonal to one another.

Landlock can be used to sandbox a launched sub process, as it is here, just as the Kernel APIs used by Bubblewrap could (and sometimes are!) used by programs to sandbox themselves.

not exactly correct. bubblewrap, firejail, and i not sure, but maybe even apparmour, all remove capabilities and create+join restricted fs/net namespaces, and then fork the actual thing you want to execute. so it's exactly the same concept, but those use the cap and cgroups.

I also would like to understand the differences relative to bubblewrap

Bubblewrap is very limited, for example it doesn't allow to grant access to /proc/self/exe without giving access to whole /proc subsystem. So I had to write an emulation of /proc in Python and mount it with FUSE to work around this. I wonder if this issue is fixed in landlock, firejail and others.

Also bubblewrap cannot ask for a decision in runtime: you must set up the rules beforehand.

Emulating /proc isn't super interesting when you can simply enter a new process namespace.

This doesn't allow hiding things like /proc/cpuinfo or /proc/cmdline or /proc/modules etc.

Same question. One thing I really dislike in Bubblewrap is that I must share the whole net user namespace even if all I want to do is use UNIX domain sockets.

Since I only see net options specifying ports, does this handle this use case?

> if all I want to do is use UNIX domain sockets

I routinely --unshare-net with UDS ro-binds.

You may be using abstract sockets (@/path/uds.sock) and those do require the same netns I think.

Landlock supports scoped abstract UNIX socket: https://docs.kernel.org/userspace-api/landlock.html#ipc-scop...

Landlock doesn't use namespaces, they are orthogonal.