[PATCH v2 00/24] Provide some actual restriction of qemu

[Ian Jackson <ian.jackson@eu.citrix.com>]

With this series, it is possible to run qemu in a way that I think
really does not have global privilege any more>

I have verified that it runs as a non-root user.  I have checked all
of its fds and they are either privcmd (which I have arranged to
neuter), or /dev/null, or harmless sockets and pipes, or evtchn.

Unfortunately this needs a new "xentoolcore" library, which all the
existing libraries register with so that the restrict call is
effective.

Also there are a number of lacunae.  In particular:

 - if we are not using a shared uid, we should kill all processes
   belonging to the chosen uid both at domain start time and at
   domain shutdown time

 - we should have qemu chroot

 - some audit and/or review of the resulting situation would be
   good before we offer security support for the new boundary

 - use of rlimits may be useful to mitigate the risk of DOS
   by a compromised qemu

 - cdrom insert would have to be done via fd passing and is not
   yet implemented

 - we need to think about what happens during migration (currently
   privileges are dropped very late, certainly after the receiving
   qemu has read the migration stream from its
   now-supposedly-untrusted peer)

The series depends for its functionality on the qemu series I have
just posted, but should be harmless without the new qemu patches
(except for the build compatibility patch to link against
xentoolcore).

I won't list the changes since v1.  They are minor and are the result
of review comments.

This repost is based on today's xen.git#master.  It will need rebase
onto staging before committing, obviously, but that shouldn't be hard.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel