Port virtiofsd's filesystem-related security mechanisms

[n0toose]

The following seems interesting:

• Implement Seccomp #895
• Implement --readonly parameter #896
• Make Uhyve aware of process-wide limits #897
• imitate SeccompAction for the WIP Landlock change (see Introduce Landlock isolation support #816): https://gitlab.com/virtio-fs/virtiofsd/-/blob/main/src/seccomp.rs#L33

If any source code-related files are copied, the license header will be preserved (plus, some additional author-related metadata as a courtesy to the original implementers). We should also "give credit" somewhere in the program; the software is licensed under BSD-3-Clause and Apache-2.0, which should be compatible with the MIT license.

[n0toose]

@jounathaen although I can't guarantee that I'll be able to do everything in the end, are you, at least in principle, against any of the changes mentioned above?

[jounathaen]

I definitely need more information on what you want to do. Maybe you can elaborate here a little or explain it to me in person.

[n0toose]

That's a meeting for another day, but, in short, virtiofsd may be acting as a daemon for a communication protocol, but its "threat model" regarding processing foreign files using commands from an untrusted guest OS is like Uhyve's. What if a VM creates more files than what is possible on the host OS? What if we could combine Landlock and seccomp, the latter of which allows us to restrict system calls (which is still a bit paranoid, but good to have)?

That come be at the expense of other ideas I had - if time allows -, such as extending supported system calls. The question is "adapt it how?", so I will probably have to rush out Landlock first.