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