Re: [Qemu-devel] Re: [libvirt] Libvirt debug API

[Avi Kivity <avi@redhat.com>]

On 04/26/2010 04:14 PM, Anthony Liguori wrote:
>>>
>>> IOW, libvirt does not run guests as separate users which is why it 
>>> needs to deal with security in the first place.
>>
>> What if one user has multiple guests?  isolation is still needed.
>
>
> Don't confuse a management application's concept of users with using 
> separate uid's to launch guests.

Then someone needs to manage those users.  A user can't suid to any 
random user.  You need someone privileged to allocate the new uid and su 
into it.

>
>> One user per guest does not satisfy some security requirements.  The 
>> 'M' in selinux stands for mandatory, which means that the entities 
>> secured can't leak information even if they want to (scenario: G1 
>> breaks into qemu, chmods files, G2 breaks into qemu, reads files).
>
> If you're implementing a chinese firewall policy, then yes, you want 
> to run each guest as a separate selinux context.  Starting as separate 
> users and setting DAC privileges appropriately will achieve this.
>
> But you're not always implementing that type of policy.  If the guest 
> inherits the uid, selinux context, and namespaces of whatever launches 
> the guest, then you have the most flexibility from a security 
> perspective.
>
> How do you launch a libvirt guest in a network namespace?  How do you 
> put it in a chroot? 

You pass the namespace fd and chroot fd using SCM_RIGHTS (except you 
probably can't do that).

> Today, you have to make changes to libvirt whereas in a direct launch 
> model, you get all of the neat security features linux supports for free.

But you lose tap networking, unless you have a privileged helper.  And 
how is the privileged helper to authenticate the qemu calling it?

>>> And I've said in the past that I don't like the idea of a qemud :-)
>>
>> I must have missed it.  Why not?  Every other hypervisor has a 
>> central management entity.
>
> Because you end up launching all guests from a single security context.

Run multiple qemuds?

But what you say makes sense.  It's similar to the fork()  /* do 
interesting stuff */ exec() model, compared to the spawn(..., hardcoded 
list of interesting stuff).

>>> Yeah, that's where I'm at.  I'd eventually like libvirt to use our 
>>> provided API and I can see where it would add value to the stack (by 
>>> doing things like storage and network management).
>>
>> We do provide an API, qmp, and libvirt uses it?
>
> Yeah, but we need to support more features (like guest enumeration).


What are our options?

1) qemud launches, enumerates
2) user launches, qemu registers in qemud
3) user launches, qemu registers in filesystem
4) you launched it, you enumerate it

>> That's wrong for three reasons.  First, selinux is not a uid 
>> replacement (if it was libvirt could just suid $random_user before 
>> launching qemu).  Second, a single user's guests should be protected 
>> from each other.  Third, in many deployments, the guest's owner isn't 
>> logged in to supply the credentials, it's system management that 
>> launches the guests.
>
> (1) uid's are just one part of an applications security context.  
> There's an selinux context, all of the various namespaces, 
> capabilities, etc.  If you use a daemon to launch a guest, you lose 
> all of that unless you have a very sophisticated api.

True.  In a perfect world, we'd use SCM_RIGHTS to channel all of these 
to libvirt or qemud.

On the other hand, users don't want to do all these things by hand.  
They want management to do things for them.  Self launch is very 
flexible, but it's not an API, and cannot be used remotely.

We could use qemud plugins to allow the user to customize the launch 
process.

>
> (2) If you want to implement a policy that only a single guest can 
> access a single image, you can create an SELinux policy and use static 
> labelling to achieve that.  That's just one type of policy though.

It's also not going to work in an environment that doesn't preserve all 
security labels (like direct access to volumes; /dev is on tmpfs these 
days).

> (3) The system management application can certainly create whatever 
> context it wants to launch a vm from.  It's comes down to who's 
> responsible for creating the context the guest runs under.  I think 
> doing that at the libvirt level takes away a ton of flexibility from 
> the management application.

If you want to push the flexibility slider all the way to the right you 
get bare qemu.  It exposes 100% of qemu capabilities.  And it's not so 
bad these days.  But it's not something that can be remoted.


-- 
error compiling committee.c: too many arguments to function