On Wed, Jun 17, 2020 at 08:55:36AM -0400, Colin Walters wrote:
> On Wed, Jun 17, 2020, at 8:50 AM, Stefan Hajnoczi wrote:
> 
> > Something along these lines should work. Hopefully seccomp can be
> > retained. It would also be necessary to check how not having the shared
> > directory as / in the mount namespace affects functionality. For one,
> > I'm pretty sure symlink escapes and similar path traversals outside the
> > shared directory will be possible since virtiofsd normally relies on /
> > as protection.
> 
> Yes, though two points:
> 
> - As I said, I don't care about that for my use case; the operating system we're testing is going to e.g. run on bare metal hosting workloads itself, so if it's malicious we have already lost (reliability against *accidental* damage is always nice though, like a stray rm -rf in some test script walking into the host)

It's not just for security, it's also for functional correctness.
Have you checked what happens when absolute symlinks are accessed?

If we're lucky well-behaved clients use FUSE_READLINK before accessing
path components. Then the symlink resolution happens in the FUSE client.
But if not, absolute symlinks will access the wrong files (oops!).

Accidental race conditions are possible too, especially when both guest
and host access the shared directory tree.

> - Probably the best long term fix would be to use https://lwn.net/Articles/796868/ anyways

Yes, I think this is a requirement for achieving correctness without
pivot_root()/chroot() due to the issues mentioned above.