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

[Xen-devel] [PATCH 00/22] Provide some actual restriction of qemu



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 a still-RFC qemu series I
have just posted, but should be harmless without the new qemu patches.

Thanks,
Ian.

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.