PVF worker: consider securing with landlock

[mrcnski]

ISSUE

Overview

I just found out about landlock. We are already working on a seccomp-based solution but that has been delayed due to, in a nutshell, the difficulty of knowing which syscalls are safe to block. Landlock might be easier and less controversial to implement, as it has a smaller scope (only restricts FS access). I expect it to be a temporary solution that can be totally replaced by seccomp sandboxing once that lands, but if it's quick to implement we should do it now. There is a Rust crate.

Alternative

If for some reason landlock doesn't work out, we can consider using chroot to restrict FS access. Its use as a security mechanism is widely discouraged, even by the manpage, but it may be better than nothing for now, and I think the caveats don't apply to us.

Related issues

#7266 is a prerequisite.

[sandreim]

I consider this another layer of defense in depth , but it seems to require kernel configuration support which might make it harder for node operators to enable it: https://docs.kernel.org/userspace-api/landlock.html#kernel-support

[mrcnski]

We should anyway check if it's enabled before running it. We can add a recommendation to enable it to the validator's guide.

[mrcnski]

I checked on my Linux environment (GCP) and Landlock is enabled there:

$ sudo dmesg | grep landlock
[    0.553664] landlock: Up and running.

I found an example for restricting the current thread and checking whether the operation was successful. This seems like low-hanging fruit, so I'll implement this and add a note about it to the validator's guide (maybe with this guide?). Also seems worthwhile to send to telemetry whether Landlock is enabled or not.