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 :| _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
