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 :|
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list