qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: M. Mohan Kumar
Subject: Re: [Qemu-devel] [PATCH V12 00/15] virtio-9p: chroot environment for passthrough security model
Date: Tue, 13 Sep 2011 11:59:38 +0530
User-agent: KMail/1.13.7 (Linux/2.6.40-4.fc15.x86_64; KDE/4.6.5; x86_64; ; )

> 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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]