Add Landlock support

[fira959]

One of the sandboxing features currently missing is landlock, which would allow for easy and comprehensive filesystem isolation.
In many usecases, a combination of seccomp and landlock would make good alternative to the use of namespaces.

[valoq]

@l0kod Would this be something you are willing to support? I keep coming back to this project as a good starting point for documentation resulting from this discussion and having landlock here would make for a much simpler approach to new projects.

[l0kod]

It would definitely make sense for Sandboxed API to leverage a sandboxing mechanism such as Landlock!

Relying on namespaces (#173) made sense when Sandboxed API started because Landlock didn't exist at that time, but I think it would be good now to provide a safer and more powerful alternative with Landlock.

I'm focusing the kernel development, the Rust library, and new user space tools for now, so I cannot devote more time to patch Sandboxed API, but I'll definitely review proposed changes.

[cblichmann]

We are currently scoping our work for 2025 and this is a reasonable request. The PolicyBuilder could be extended with the filesystem parts of Landlock at least.

We'll update this bug, once we know more. Happy to discuss concrete design ideas before reviewing actual PRs :)

[l0kod]

We are currently scoping our work for 2025 and this is a reasonable request. The PolicyBuilder could be extended with the filesystem parts of Landlock at least.

Sounds good! I guess Sandboxed API and the Landlock Rust libraries use the same builder pattern, so this PolicyBuilder should be fine for all the sandbox configuration.

We'll update this bug, once we know more. Happy to discuss concrete design ideas before reviewing actual PRs :)

I think the main concept which may not be obvious is the default best-effort approach. Because Landlock is gaining new features with new kernel versions, and to protect users as much as possible with the available features, it would be good to make it easy to follow this approach. As a more specific approach for Sandboxed API, I think it would be good to also take into account the potentially already available kernel features (e.g. user namespaces).

One approach would be to first not directly expose Landlock-specific features through the API, but update the implementation to leverage them, especially if required-until-now features are not available (e.g. user namespaces) and Landlock could be used as a fallback. In a second step, because Landlock enables a more fine-grained access control, the Sandboxed API will need to be extended to leverage these extra features.

Following the principle of least privilege (on the long run), it would be nice for Sandboxed API to be usable without requiring user namespaces. That will exclude use cases that require a specific view of the filesystem, but just an access control should be enough for most sandboxing use cases. Anyway, all possible actions may not be controlled by Landlock yet, but we are working to make it possible. 😉