brainstorming for UDS-N - Cloud Infrastructure

[Jamie Strandboge]

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.

-- 
Jamie Strandboge             | http://www.canonical.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/94066b12/attachment.pgp