8:41 a.m.
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