Open Stack

On Thursday 10 July 2014 14:47:11 Daniel P. Berrange wrote:
> 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.
> 

Thanks, Daniel, it seems you've answered this question second time :)

> 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.
> 

That's exactly what I'd like to know.
I've also found the spec about starting LXC container from a block device: 
https://github.com/openstack/nova-specs/blob/master/specs/juno/libvirt-start-lxc-from-block-devices.rst

Is it up-to-date?


> Regards,
> Daniel

-- 
Dmitry Guryanov