brainstorming for UDS-N - Cloud Infrastructure

[Stéphane Graber]

On Wed, 2010-09-29 at 15:12 -0500, Jamie Strandboge wrote:
> On Wed, 2010-09-29 at 10:55 -0400, Stéphane Graber wrote:
> > On Wed, 2010-09-29 at 09:25 -0500, Jamie Strandboge wrote:
> > > On Tue, 2010-09-28 at 20:05 -0400, Stéphane Graber wrote:
> > > I believe we can greatly improve our VM server solution (my biggest wish
> > > > at the moment is for some kind of ACLs on VMs running in libvirt) and
> > > > prepare to have a rocking solution for the next LTS.
> > > > 
> > > When using qemu/kvm, libvirt can use the AppArmor security driver to
> > > confine VMs to only the files they need. This provides guest isolation
> > > and userspace host protection. This is on by default in Ubuntu's libvirt
> > > since Karmic and is also upstream.
> > 
> > I agree that libvirt itself can't do any scary changes on the system
> > when using apparmor. What I was more thinking about is the case where
> > you have a shared virtualization server with multiple users running VMs.
> > 
> > Something that's seen in other VM infrastructure is that ability to let
> > users create VM and manage them while still preventing them from
> > accessing/altering anyone else's VM running on that same host.
> 
> I think you may have misunderstood me. libvirtd is not confined, the
> individual VMs are confined. VMs launched from libvirt *are* isolated
> from each other (assuming no kernel holes ;). Eg:
> 
> $ cat /etc/apparmor.d/libvirt/libvirt-ff4bb2a2-edb4-30fb-cf72-6715bdbaf34a*
> #
> # This profile is for the domain whose UUID matches this file.
> #
> 
> #include <tunables/global>
> 
> profile libvirt-ff4bb2a2-edb4-30fb-cf72-6715bdbaf34a {
>   #include <abstractions/libvirt-qemu>
>   #include <libvirt/libvirt-ff4bb2a2-edb4-30fb-cf72-6715bdbaf34a.files>
> 
> }
> # DO NOT EDIT THIS FILE DIRECTLY. IT IS MANAGED BY LIBVIRT.
>   "/var/log/libvirt/**/dev-squeeze-amd64-1.log" w,
>   "/var/lib/libvirt/**/dev-squeeze-amd64-1.monitor" rw,
>   "/var/run/libvirt/**/dev-squeeze-amd64-1.pid" rwk,
>   "/home/jamie/vms/kvm/dev-squeeze-amd64-1/disk1.img" rw,
> 
> 
> That said, this doesn't prevent users on the system from messing with
> one another's VMs. You have to have access to qemu:///system (ie be in
> the 'libvirtd' group, which should be considered a privileged group) in
> order to have MAC (ie AppArmor or SELinux) protection. Multi-user
> virtualization server systems would probably want to look at
> qemu:///session, which runs wholly unprivileged as the user. In this
> manner, standard DAC would provide the isolation, but it isn't as
> convenient to use.

Right, currently my issue is when having multiple VMs, "owned" by
different users and accessed remotely through virt-manager so accessing
on qemu:///session

Even though the VMs are isolated from each other using apparmor it won't
prevent a colleague of mine to shut down "my" VM as all of us are in
libvirtd.

In an ideal world, an "administrator" should be able to grant access
rights to "users" including the right to create new VMs (ideally limited
to a specific storage pool) and then have that user allow other users to
access that VM.

That way only the "owner" and the "administrators" would be able to
access and modify a VM, others would just see their own VMs.
That's kind of what I'm currently missing with libvirt and virt-manager
when used on VM servers shared across the company.


-- 
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20100929/a31d30e8/attachment-0001.pgp