[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
signature.asc
Description: PGP signature