[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]