On Tue, Sep 27, 2022, at 1:27 PM, German Maglione wrote:
>
>> > Now all the development has moved to rust virtiofsd.
Oh, awesome!! The code there looks great.
> I could work on this for the next major version and see if anything breaks.
> But I prefer to add this as a compilation feature, instead of a command line
> option that we will then have to maintain for a while.
Hmm, what would be the issue with having the code there by default? I think
rather than any new command line option, we automatically use
`openat2+RESOLVE_IN_ROOT` if the process is run as a nonzero uid.
> Also, I don't see it as a sandbox feature, as Stefan mentioned, a compromised
> process can call openat2() without RESOLVE_IN_ROOT.
I'm a bit skeptical honestly about how secure the existing namespace code is
against a compromised virtiofsd process. The primary worry is guest filesystem
traversals, right? openat2+RESOLVE_IN_ROOT addresses that. Plus being in Rust
makes this dramatically safer.
> I did some test with
> Landlock to lock virtiofsd inside the shared directory, but IIRC it requires a
> kernel 5.13
But yes, landlock and other things make sense, I just don't see these things as
strongly linked. IOW we shouldn't in my opinion block unprivileged virtiofsd
on more sandboxing than openat2 already gives us.
