On Mon, Aug 22, 2011 at 6:22 PM, Daniel P. Berrange <berrange@xxxxxxxxxx> 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.
>
> So inventing a 'qemu-fe' does not make the need for passing FDs into
> QEMU go away, nor does it improve/change the overall security of the
> architecture, it is merely a different architectural choice. It does
> however require alot more development work to create this new 'qemu-fe'
> program and get it debugged & generally usable in production deployments
>
> So adding FD passing to QEMU blocks creation of a 'qemu-fe' program,
> but is not dependant on it. Thus we can add FD passing to QEMU today
> and be a step closer to being able to create a 'qemu-fe' in the future,
> while also enabling libvirtd & other mgmt apps to take advantage of
> this to solve the immediate security problem we have with NFS today,
> without having to wait a months or years for 'qemu-fe' to get into a
> usable state.
The advantage of this qemu-fe approach is that block format internals
does not need to be shared between QEMU and libvirt.
FD passing can still be useful for other purposes.
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list