>>> 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_addfile:/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.
>>> So I'd see that you'd likely end up with the
>>> qemu-fe security policy being identical to the qemu security policy,
>> Then there's no point in doing qemu-fe. qemu-fe should be thought of as
>> QEMU supplied libvirtd plugin.
>>> with the exception that it would be allowed to open files on NFS without
>>> needing them to be labelled. So I don't really see that all this gives us
>>> any tangible benefits over just allowing the mgmt app to pass in the FDs
>>>> But libvirt would still need to parse image files.
>>> Not neccessarily. As mentioned below, it is entirely possible to
>>> enable the mgmt app to pass in details of the backing files, at
>>> which point no image parsing is required by libvirt. Hence my
>>> assertion that the question of who does image parsing is irrelevant
>>> to this discussion.
>> That's certainly true.
>> Anthony Liguori