[Gllug] Security from scratch or just stick with Astaro?

[Daniel P. Berrange]

On Sun, Apr 13, 2008 at 12:20:12AM +0100, Nix wrote:
> On 11 Apr 2008, Richard Jones uttered the following:
> >                                                               Everyone
> > basically uses qemu to emulate these devices and qemu has a small
> > history of vulnerabilities, eg. CVE-2007-1320 (emulated Cirrus Logic
> > bounds check) and CVE-2007-1321 (emulated NE2K buffer overflow).
> > 
> > With Xen, the qemu process runs as root, but it was never designed for
> > that.
> 
> Indeed not: the thought is somewhat shiver-inducing.

This is something we're actively trying to address. QEMU under Xen has
been under a loosely confined SELinux domain for a while, and in Fedora
9 we've put QEMU / KVM under SELinux control too. We're going to be 
taking this further in Fedora 10 to isolate QEMU instances from each
other too and further restrict the host device access they have.

At the same time work is being done on KVM to eliminate the limitations
that force us to run KVM as a privileged user. So in theory at least 
it will be reasonable to let unprivileged users access run KVM directly.
Currently this isn't practical because unprivileged will be able to
pin arbitrary amounts of RAM leading to a DOS on the host.

We're also considering how it might be possible to let QEMU drop privileges
after startup, though this isn't as easy as it sounds if you want to keep
the ability to do device hotplug.

> >       Here's an email you may [not] enjoy reading:
> > http://marc.info/?l=debian-security&m=120343592917055&w=2 (thanks to
> > Dan Berrange for pointing that one out).
> 
> Hm. `If it doesn't add a bad overhead' is, well, somewhat worrying (I
> suppose that if there was a bug such that secure virtualization was
> impossible without, say, taking a trap at every single emulated
> instruction, it might not be worth taking that hit...)

This particular security issue was blown out of all proportion - there
was no measurable impact from the additional bounds checks and (if using
raw files) the only impact was that the user might be able to cause the
size of their disk to be extended.

> > Another good route for compromising the host from the guest is through
> > monitoring and provisioning tools.  For example you may be tempted to
> > try to mount a guest's partitions inside your host, but no one really
> > knows what happens if the guest is being malicious and creates
> > hand-crafted partition tables, filesystem superblocks or LVM PV
> > metadata.
> 
> Oh yes indeed. NFS-mounting it is a bit safer (the NFS client is more
> careful than a random filesystem driver). (Of course if your guest is
> being malicious, you have big problems anyway.)

We've got a few crazy ideas floating around with QEMU and the VirtIO 
drivers, such as being able to boot diskless QEMU instances using the
Plan9-FS virtio subsystem to have their root FS actually be just a
chroot style directory root on the host machine.

Dan.
-- 
|: http://berrange.com/     -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://freshmeat.net/~danielpb/    -o-   http://gtk-vnc.sourceforge.net :|
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: Digital signature
URL: <http://mailman.lug.org.uk/pipermail/gllug/attachments/20080413/9ac2d908/attachment.pgp>
-------------- next part --------------
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug