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

[Anthony Liguori]

On 08/23/2011 09:26 AM, Corey Bryant wrote:
> On 08/22/2011 03:25 PM, Anthony Liguori wrote:
>> On 08/22/2011 01:22 PM, Daniel P. Berrange wrote:
>>> 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.
>>
>> But the fundamental difference is that libvirtd uses what's ostensible a
>> public, supported interface. That means when we add things like this,
>> we're stuck supporting it for general use cases.
>>
>> It's much more palatable to do these things using a private interface
>> such that we can change these things down the road without worrying
>> about compatibility with third-party tools.
>>
>> Regards,
>>
>> Anthony Liguori
>>
>
> Is this a nack for the fd: protocol?

No, I think we're trying to understand what the options are.

Regards,

Anthony Liguori

  Or do we want to implement the fd:
> protocol as a stepping stone on the way to a privilege-separated qemu
> model? I know the fd: protocol is not ideal, but it does provide NFS
> image isolation, perhaps much sooner than privilege-separated qemu can.
>