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

[Corey Bryant <coreyb@linux.vnet.ibm.com>]

On 08/22/2011 01:25 PM, 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.
>

I do like the idea of a privileged qemu-fe performing the open and 
passing the fd to a restricted qemu.  However, I get the impression that 
this won't get delivered nearly as quickly as fd: passing could be.  How 
soon do we need image isolation for NFS?

Btw, this sounds similar to what Blue Swirl recommended here on v1 of 
this patch: 
http://lists.gnu.org/archive/html/qemu-devel/2011-05/msg02187.html

Regards,
Corey

>> 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.
>
>> 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
>> directly.
>>
>>> 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.
>
> Regards,
>
> Anthony Liguori