On Tue, Sep 06, 2011 at 03:48:22PM +0100, Stefan Hajnoczi wrote: > On Mon, Sep 05, 2011 at 09:48:21PM +0530, M. Mohan Kumar wrote: > > Qemu need to be invoked by root user for using virtfs with passthrough > > security model (i.e to use chroot() syscall). > > > > Question is: Is running qemu by root user expected and allowed? Some of the > > virtfs features can be utilized only if qemu is started by root user (for > > example passthrough security model and handle based file driver need root > > privilege). > > > > This issue can be resolved by root user starting qemu and spawning a process > > with root privilege to do all privileged operations there and main qemu > > process dropping its privileges to avoid any security issue in running qemu > > in > > root mode. Privileged operations can be done similar to the chroot patchset. > > > > But how to determine to which user-id(ie non root user id) qemu needs to > > drop > > the privileges? Do we have a common user-id across all distributions/systems > > to which qemu process can be dropped down? Also it becomes too complex i.e > > when > > a new feature needing root privilege is added, a process with root privilege > > needs to be created to handle this. > > > > So is it allowed to run qemu by root user? If no, is it okay to add the > > complexity of adding a root privilege process for each feature that needs > > root > > privilege? > > I believe libvirt performs the privilege dropping itself and then > invokes QEMU. So in the context of KVM + libvirt we do not have > privileges in QEMU. Of course the administrator can edit > /etc/libvirt/qemu.conf and configure the user to run QEMU as (i.e. > root). But the intention here is to run QEMU unprivileged. > > QEMU has its own -runas switch which may be used when QEMU is run > directly by a user or by custom scripts. This switch looks up the user > and switches to their uid/gid/groups. > > We need to think carefully before adding privileged features to QEMU > since they usually require extra configuration to safely limit the group > of users who may use the feature. These features will be unavailable to > unprivileged users on a system.
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 Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
