openstack team mailing list archive

["Richard W.M. Jones" <rich@xxxxxxxxxxx>]

On Tue, Aug 14, 2012 at 11:30:29AM -0700, Matt Joyce wrote:
> I have to ask.  Wasn't FUSE designed to do alot of this stuff?  It is
> userspace and it doesn't do nasty stuff to file systems.  Why aren't we
> going that route?

FUSE is not really related to this issue.  It's just the API.

You can use libguestfs over FUSE.  Indeed that's how OpenStack works
right now, albeit using the external 'guestmount' program, whereas
with libguestfs >= 1.18 you'll be able to use the much cleaner
'mount-local' core API.

  http://libguestfs.org/guestmount.1.html
  http://libguestfs.org/guestfs.3.html#mount-local

The issue is what thing, underneath the API, is actually accessing the
filesystem.  If you're mounting stuff directly on the host, then that
thing is the host kernel, which is really the worst scenario from a
security p.o.v.

If (as some have suggested) you're using a userspace program on the
host, then you've got a userspace program which can be exploited that
then has direct access to the host.

With libguestfs, accessed either via the libguestfs native API or over
FUSE, you've got the regular qemu/KVM process buffering you from any
exploits.  In essence, this is the same situation as when you're
running any VM, so it's just as safe (or unsafe) as Nova is already.

  http://libguestfs.org/guestfs.3.html#architecture
  http://libguestfs.org/guestfs.3.html#api-overview
  http://libguestfs.org/guestfs.3.html#security

With libguestfs *and* libvirt (in libguestfs >= 1.19.25), you've got
not just the qemu wrapper, but also SELinux controlling exactly what
the qemu process can see and do in the host, ie. sVirt.

  http://selinuxproject.org/page/SVirt
  https://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Security-Enhanced_Linux/chap-Security-Enhanced_Linux-sVirt.html

Rich.

-- 
Richard Jones
Red Hat