Open Stack

On Thu, Jul 10, 2014 at 05:36:59PM +0400, Dmitry Guryanov wrote:
> I have a question about mounts - in OpenVZ project each container has its own 
> filesystem in an image file. So to start a container we mount this filesystem 
> in host OS (because all containers share the same linux kernel). Is it a 
> security problem from the Openstack's developers vision?
> 
> 
> I have this question, because libvirt's driver uses libguestfs to copy some 
> files into guest filesystem instead of simple mount on host. Mounting with 
> libguestfs is slower, then mount on host, so there should be strong reasons, 
> why libvirt driver does it.

We consider mounting untrusted filesystems on the host kernel to be
an unacceptable security risk. A user can craft a malicious filesystem
that expliots bugs in the kernel filesystem drivers. This is particularly
bad if you allow the kernel to probe for filesystem type since Linux
has many many many filesystem drivers most of which are likely not
audited enough to be considered safe against malicious data. Even the
mainstream ext4 driver had a crasher bug present for many years

  https://lwn.net/Articles/538898/
  http://libguestfs.org/guestfs.3.html#security-of-mounting-filesystems

Now that all said, there are no absolutes in security. You have to
decide what risks are important to you and which are not. In the case
of KVM, I think this host filesystem risk is unacceptable because you
presumably chose to use machine based virt in order get strong separation
of kernels. If you have explicitly made the decision to use a container
based virt solution (which inherantly has a shared kernel between host
and guest) then I think it would be valid for you to say this filesystem
risk is one you are prepared to accept, as it is not much worse than
the risk you already have by using a single shared kernel for all tenants.

So, IMHO, OpenStack should not dictate the security policy for things
like this. Different technologies within openstack will provide protection
against different attack scenarios. It is a deployment decision for the
cloud administrator which of those risks they want to mitigate in their
usage.  This is why we still kept the option of using a non-libguestfs
approach for file injection.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|