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