Open Stack

On Thu, Jul 10, 2014 at 06:18:52PM +0400, Dmitry Guryanov wrote:
> 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?

Yes, just recently approved and code for it is in process of review.

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