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:

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

That's all I could spot with a cursory look :)


Thierry Carrez (ttx)

OpenStack Development Mailing List (not for usage questions)

Reply via email to