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