Re: [libvirt] [Qemu-devel] [PATCH v4] Add support for fd: protocol

On Mon, Aug 22, 2011 at 12:25:25PM -0500, Anthony Liguori wrote: > On 08/22/2011 11:50 AM, Daniel P. Berrange wrote: >> On Mon, Aug 22, 2011 at 11:29:12AM -0500, Anthony Liguori wrote: >>> I don't think it makes sense to have qemu-fe do dynamic labelling. >>> You certainly could avoid the fd passing by having qemu-fe do the >>> open though and just let qemu-fe run without the restricted security >>> context. >> >> qemu-fe would also not be entirely simple, > > Indeed. > >> because it will need to act >> as a proxy for the monitor, in order to make hotplug work. ie the mgmt >> app would be sending 'drive_add file:/foo/bar' to qemu-fe, which would >> then have to open the file and send 'drive_add fd:NN' onto the real QEMU, >> and then pass the results on back. >> >> In addition qemu-fe would still have to be under some kind of restricted >> security context for it to be acceptable. This is going to want to be as >> locked down as possible. > > I think there's got to be some give and take here. > > It should at least be as locked down as libvirtd. From a security > point of view, we should be able to agree that we want libvirtd to > be as locked down as possible. > > But there shouldn't be a hard requirement to lock down qemu-fe more > than libvirtd. Instead, the requirement should be for qemu-fe to be > as/more vigilant in not trusting qemu-system-x86_64 as libvirtd is. > > The fundamental problem here, is that there is some logic in > libvirtd that rightly belongs in QEMU. In order to preserve the > security model, that means that we're going to have to take a > subsection of QEMU and trust it more. Well we have a process that makes security decisions, and a process which applies those security decisions and a process which is confined by those decisions. Currently libvirtd makes& applies the decisions, and qemu is confined. A qemu-fe model would mean that libvirt is making the decisions, but is then relying on qemu-fe to apply them. IMHO that split is undesirable, but that's besides the point, since this is not a decision that needs to be made now. 'qemu-fe' needs to have a way to communicate with the confined process ('qemu-system-XXX') to supply it the resources (file FDs) it needs to access. The requirements of such a comms channel for qemu-fe are going to be the same as those needed by libvirtd talking to QEMU today, or indeed by any process that is applying security decisions to QEMU.