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

["Daniel P. Berrange" <berrange@redhat.com>]

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