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.
