* [Qemu-devel] Re: [RFC][PATCH 00/01]qemu VM entrypoints
[not found] <C2C6EC59.36BC%dwindsor@gmail.com>
@ 2007-07-21 2:51 ` David Windsor
0 siblings, 0 replies; only message in thread
From: David Windsor @ 2007-07-21 2:51 UTC (permalink / raw)
To: qemu-devel@nongnu.org
On 7/20/07 6:42 PM, "James Morris" <jmorris@namei.org> wrote:
> On Fri, 20 Jul 2007, Anthony Liguori wrote:
>
>> James Morris wrote:
>>> On Fri, 20 Jul 2007, Daniel P. Berrange wrote:
>>>
>>>
>>>> It could be - if your put the policy at the control API layer instead of
>>>> in QEMU itself.
>>>>
>>>
>>> Then you can bypass MAC security by invoking qemu directly.
>>>
>>
>> You can bypass MAC security by writing your own binary that uses the KVM
>> kernel interfaces.
>
> Yep, I was thinking only about qemu.
>
> I guess you'd have OS policy preventing normal domains from accessing
> /dev/kvm (or /dev/lguest etc.), while a security-aware launcher would
> enforce access control policy over which domains could launch which disk
> images as VMs, and also setup the execution context & fork.
>
Yes, the use case I was targeting was an environment in which access to
/dev/kvm from normal user domains was not permitted.
> So, perhaps this would be better done at the libvirt layer (i.e. make
> libvirt the object manager).
>
The more that I think about this, I think that libvirt may indeed be the
correct place for the vm:entrypoint hook. Rather than have individual
userspace backends be responsible for setting up the correct execution
context and forking, it makes sense for libvirt itself to set up the correct
context for the qemu process prior to launching qemu. And as Daniel said,
it would allow policy writers to write coherent policy about VMs regardless
of the userspace backend used.
The SELinux specific bits of the patch are still relevant, I think I will
just move the enforcement code to libvirt.
>
>
> - James
^ permalink raw reply [flat|nested] only message in thread