Fearture Request: Landlock

[andrew-2e128]

Landlock provides fine grained control over individuals files or directories, there are already other sandboxing software that does exactly this like the go written landrun

this will be very handy to control access to individual files easily instead of filtering syscalls with seccomp

[rusty-snake]

#519

this will be very handy to control access to individual files easily instead of filtering syscalls with seccomp

That are two unrelated things.

[smcv]

See containers/bubblewrap#519, and specifically https://github.com/containers/bubblewrap/pull/519#pullrequestreview-1156361461.

Making use of Landlock is not a use-case, it's an implementation detail. The starting point for any feature should be what benefit you are aiming to provide to some user (probably a user of a higher-level component like Flatpak, rather than a user of bubblewrap); and then if a new option that makes use of Landlock is the best way to provide that benefit with a reasonable maintenance cost, it can be used, or if something else is a better way to do it, that can be used instead.

So, please start any feature request from a solution-neutral problem statement: less like "I want to use Landlock" and more like, for example, "I want to allow creating regular files in /tmp but prevent creating symlinks, because [reason]".

If Landlock does turn out to be a good solution, there are two requirements for getting a new feature into bubblewrap:

1. Someone (not necessarily a maintainer) needs to implement the feature. The maintainers of bubblewrap have very limited time, so we are unlikely to be able to pick up and implement a feature just because someone says it would be nice.
2. A maintainer (or at least a contributor trusted by the maintainers) needs to review it:
   • this reviewer needs to be a second person who is not the author, which means that if a maintainer (for example me) does the implementation, then they need to wait for a second trusted person to have enough time available to review it
   • and, they need to be able to assess whether the new feature is useful, has a benefit exceeding its maintenance cost, and is a good solution to the problem that it claims to be solving, for which a solution-neutral problem statement is much more useful than a request to add some specific technology

there are already other sandboxing software that does exactly this like the go written landrun

bubblewrap does not aim to be the only piece of sandboxing technology that anyone will ever need. If landrun fits your needs better, you are very welcome to use landrun, or even combine bubblewrap with landrun; we are not going to feel offended if you have chosen not to use bubblewrap.

[wrr]

The closed issue https://github.com/containers/bubblewrap/issues/330 could potentially be addressed with LANDLOCK_SCOPE_ABSTRACT_UNIX_SOCKET introduced by Landlock ABI v6:

LANDLOCK_SCOPE_ABSTRACT_UNIX_SOCKET This limits the set of abstract unix(7) sockets to which we can connect(2) to socket addresses which were created by a process in the same or a nested Landlock domain.

A sendto(2) on a non-connected datagram socket is treated as if it were doing an implicit connect(2) and will be blocked if the remote end does not stem from the same or a nested Landlock domain.

A sendto(2) on a socket which was previously connected will not be restricted. This works for both datagram and stream sockets.

This would allow bubblewrapped processes to have access to network without having access to X11.

[rusty-snake]

without having access to X11

/tmp/.X11-unix

[wrr]

without having access to X11

/tmp/.X11-unix

Restricting access to /tmp/.X11-unix is already possible with bind mounts, but restricting access to abstract sockets, such as @"/tmp/.X11-unix/X0" is not possible with bind mounts. Currently only creating a new network namespace allows to restrict access to existing abstract sockets.

[smcv]

The closed issue #330 could potentially be addressed with LANDLOCK_SCOPE_ABSTRACT_UNIX_SOCKET introduced by Landlock ABI v6 ... This would allow bubblewrapped processes to have access to network without having access to X11.

Great, but then the feature request is/should be something like: "I want the wrapped process to have access to IPv4/IPv6 networking, but without being able to access abstract Unix sockets like the one for X11" (as opposed to "I want to use Landlock"). Do you see the difference?

[smcv]

I'm going to close this as too broad to be actionable, but if there are user-facing sandboxing use-cases like #330 that can be solved using Landlock, please feel free to propose MRs that implement those use-cases using Landlock - it is probably a good tool to have available. I've reopened #330 and left a comment there, pointing to the LANDLOCK_SCOPE_ABSTRACT_UNIX_SOCKET suggestion.