Angus Lees wrote: > So inspired by the "Rootwrap on root-intensive nodes" thread, I went and > wrote a proof-of-concept privsep daemon for > neutron: https://review.openstack.org/#/c/155631
Nice work! Trying to check where the security model is actually weaker than the one provided by rootwrap here... If I read this correctly, one of the drawbacks compared to the rootwrap approach is that all the functions are accessible on any node running the privsep daemon. When properly packaged, the rootwrap system only has the relevant filter definition files present, which dramatically reduces what you allow to run as root there. For example, nova-metadata nodes can only run iptables to add a firewall rule, since that's the only filter definition file shipped on those nodes. That's a benefit of shipping allowed commands in the configuration, rather than in the code. With the proposed system, the nova-metadata node running with nova-privsep would have access to any function defined there, including the rather permissive file manipulations that nova-compute needs. Maybe one way to solve that would be to have several different privsep daemons in nova to run on the various types of nodes, each with their own set of allowed functions... Additionally, rootwrap was extremely lean in terms of dependencies -- basically only allowing Python stdlib module imports to reduce the envelope of code you need to trust to run things as root. Here you are reusing the Neutron agent framework, which has a pretty long list of module imports, which are all imported before the rights are dropped. That means you end up blindly trusting a widely larger envelope of modules. My suggestion would be to not run it as an agent but as a standalone daemon with an aggressively-limited set of module imports (ideally only stdlib). That's all I could spot with a cursory look :) Cheers, -- Thierry Carrez (ttx) __________________________________________________________________________ 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