Re: [Qemu-devel] [PATCH V12 00/15] virtio-9p: chroot environment for passthrough security model

["M. Mohan Kumar" <mohan@in.ibm.com>]

> I agree, regardless of libvirt's needs, p9fs needs to be secure for any
> non-root user using QEMU. As non-root I should be able todo
> 
>   $ qemu -virtfs $HOME/shared
> 
> and have strong confidence that symlink attacks can't be used by the
> guest to access other locations nuder $HOME.
> 
> > A virtfs feature that needs root therefore needs to be in a separate
> > process.  Either QEMU needs to fork or virtfs could use a separate
> > daemon binary.
> 
> One other idea I just had is 'fakechroot'. This is basically an LD_PRELOAD
> hack which wraps the C library's native chroot(), open() etc call to do
> chroot in userspace, thus avoiding a need for root privileges.
> 
> Either you could just invoke QEMU via fakechroot, enabling your code from
> these patches to be used as non-root. Or we could take the code from the
> fakechroot library and use that directly in the p9fs code to apply the
> path security checks
> 
With fakechroot is that I can still do following:
chroot("/etc/cups");
fd = open("../passwd", O_RDONLY);

It does not check access beyond the chroot path. Also in virtio-9p case, a 
modified guest kernel can send a symbolic link and that could resolve outside 
chroot path.

passthrough security model in virtio-9p needs root privilege not only for 
chroot() syscall but also to do chown and chmod on files created by the guest.

So IMHO fakechroot can't be used in this case.