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

[Corey Bryant]

On 08/23/2011 11:50 AM, Kevin Wolf wrote:
> Am 23.08.2011 17:26, schrieb Daniel P. Berrange:
>> >  On Tue, Aug 23, 2011 at 11:13:34AM -0400, Corey Bryant wrote:
>>> >>
>>> >>
>>> >>  On 08/22/2011 02:39 PM, Blue Swirl wrote:
>>>> >>>  On Mon, Aug 22, 2011 at 5:42 PM, Corey Bryant<coreyb at linux.vnet.ibm.com>   wrote:
>>>>>> >>>>>
>>>>>> >>>>>
>>>>>> >>>>>    On 08/22/2011 01:25 PM, 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.
>>>>>>>> >>>>>>>
>>>>>> >>>>>
>>>>>> >>>>>    I do like the idea of a privileged qemu-fe performing the open and passing
>>>>>> >>>>>    the fd to a restricted qemu.
>>>> >>>  Me too.
>>>> >>>
>>>>>> >>>>>      However, I get the impression that this won't
>>>>>> >>>>>    get delivered nearly as quickly as fd: passing could be.  How soon do we
>>>>>> >>>>>    need image isolation for NFS?
>>>>>> >>>>>
>>>>>> >>>>>    Btw, this sounds similar to what Blue Swirl recommended here on v1 of this
>>>>>> >>>>>    patch:http://lists.gnu.org/archive/html/qemu-devel/2011-05/msg02187.html
>>>> >>>  I was thinking about simply doing fork() + setuid() at some point and
>>>> >>>  using the FD passing structures directly. But would it bring
>>>> >>>  advantages to have two separate executables, are they different from
>>>> >>>  access control point of view vs. single but forked one?
>>>> >>>
>>> >>
>>> >>  We could put together an SELinux policy that would transition
>>> >>  qemu-fe to a more restricted domain (ie. no open privilege on NFS
>>> >>  files) when it executes qemu-system-x86_64.
>> >
>> >  Thinking about this some more, I don't really think the idea of delegating
>> >  open of NFS files to a separate qemu-fe is very desirable. Libvirt makes the
>> >  decision on the security policy that the VM will run under, and provides
>> >  audit records to log what resources are being assigned to the VM. From that
>> >  point onwards, we must be able to guarantee that MAC will be enforced on
>> >  the VM, according to what we logged via the auditd system.
>> >
>> >  In the case where we delegate opening of the files to qemu-fe, and allow
>> >  its policy to open NFS files, we no longer have a guarentee that the MAC
>> >  policy will be enforced as we originally intended. Yes, qemu-fe will very
>> >  likely honour what we tell it and open the correct files, and yes qmeu-fe
>> >  has lower attack surface wrt the guest than the real qemu does, but we
>> >  still loose the guarentee of MAC enforcement from libvirt's POV.
> On the other hand, from a qemu POV libvirt is only one possible
> management tool. In practice, another very popular "management tool" for
> qemu is bash. With qemu-fe all the other tools, including direct
> invocation from the command line, would get some protection, too.
>
> Kevin

True, but like you said it provides just some protection.  To really be 
useful qemu-fe would need the ability to label qemu guest processes and 
image files to provide MAC isolation.

-- 
Regards,
Corey