On Wed, Feb 04, 2015 at 05:52:12PM +0100, Philipp Marek wrote: > Here are my 2¢. > > > > >> (1) we could get our act together and audit and fix those filter > > > >> definitions. Remove superfluous usage of root rights, make use of > > > >> advanced filters for where we actually need them. We have been > > > >> preaching > > > >> for that at many many design summits. This is a lot of work though... > > > >> There were such efforts in the past, but they were never completed for > > > >> some types of nodes. Worse, the bad filter definitions kept coming > > > >> back, > > > >> since developers take shortcuts, reviewers may not have sufficient > > > >> security awareness to detect crappy filter definitions, and I don't > > > >> think we can design a gate test that would have such awareness. > Sounds like a lot of work... ongoing, too. > > > > > >> (2) bite the bullet and accept that some types of nodes actually need > > > >> root rights for so many different things, they should just run as root > > > >> anyway. I know a few distributions which won't be very pleased by such > > > >> a > > > >> prospect, but that would be a more honest approach (rather than > > > >> claiming > > > >> we provide efficient isolation when we really don't). An added benefit > > > >> is that we could replace a number of shell calls by Python code, which > > > >> would simplify the code and increase performance. > Practical, but unsafe. > > I'd very much like to have some best-effort filter against bugs in my > programming - even more so during development. > > > > (4) I think that ultimately we need to ditch rootwrap and provide a proper > > privilege separated, formal RPC mechanism for each project. > ... > > we should have a nova-compute-worker daemon running as root, that accepts > > an RPC command from nova-compute running unprivileged. eg > > > > CreateImage("instane0001", "qcow2", "disk.qcow") > ... > > This is certainly alot more work than trying to patchup rootwrap, but > > it would provide a level of security that rootwrap can never achieve IMHO. > A lot of work, and if input sanitation didn't work in one piece of code, > why should it here? > > I think this only leads to _more_ work, without any real benefit. > If we can't get the filters right the first round, we won't make it here > either.
The difference is that the API I illustrate here has *semantic* context about the operation. In the API example the caller is not permitted to provide a directory path - only the name of the instance and the name of the disk image. The privileged nova-compute-worker program can thus enforce exactly what directory the image is created in, and ensure it doesn't clash with a disk image from another VM. This kind of validation is impractical when you are just given a 'qemu-img' command line args with a full directory path, so there is no semantic conext for the privileged rootwrap to know whether it is reasonable to create the disk image in that particular location. 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 Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev