qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2] security.rst: add Security Guide to develope


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [PATCH v2] security.rst: add Security Guide to developer docs
Date: Fri, 3 May 2019 11:32:16 -0600
User-agent: Mutt/1.11.4 (2019-03-13)

On Fri, May 03, 2019 at 10:04:10AM +0100, Alex Bennée wrote:
> Stefan Hajnoczi <address@hidden> writes:
> > +Isolation mechanisms
> > +~~~~~~~~~~~~~~~~~~~~
> > +Several isolation mechanisms are available to realize this architecture of
> > +guest isolation and the principle of least privilege.  With the exception 
> > of
> > +Linux seccomp, these mechanisms are all deployed by management tools that
> > +launch QEMU, such as libvirt.  They are also platform-specific so they are 
> > only
> > +described briefly for Linux here.
> > +
> > +The fundamental isolation mechanism is that QEMU processes must run as
> > +**unprivileged users**.  Sometimes it seems more convenient to launch QEMU 
> > as
> > +root to give it access to host devices (e.g. ``/dev/net/tun``) but this 
> > poses a
> > +huge security risk.  File descriptor passing can be used to give an 
> > otherwise
> > +unprivileged QEMU process access to host devices without running QEMU
> > as root.
> 
> Should we mention that you can still maintain running as a user and just
> make the devices you need available to the user/group rather than
> becoming root? For example I generally make /dev/kvm group accessible to
> my user account.

Sure.  I checked that /dev/vhost-* device nodes are root:root on Fedora
so at least the distro doesn't expect you to do that.  The /dev/kvm
device node is root:kvm so it's easy to do it by joining the kvm group
there.

Stefan

Attachment: signature.asc
Description: PGP signature


reply via email to

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