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.
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.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|