Privsep is intended to provide some security in depth. The idea is based on the principal of least privilege. We assume that an attacker has exploited some bug in Nova and is able to execute arbitrary code. If privsep is doing its job, the attacker should at least not be able to perform any privileged operations which Nova does not normally perform. For developers, from the spec[1]: "The intention is to allow slightly more code into the privileged portion - enough that we now have sufficient “context” to make better security decisions. For example move from “run chown” to “take ownership of VM output file”." Unfortunately, I suspect out of expediency in the initial forklift from rootwrap, we've lost this critical principal of moving security-critical logic into privsep itself. Consequently, a brief and non-exhaustive audit reveals we have privsep functions to do the following: fs.py: * mount anything of any type, including remote storage, anywhere. * unmount anything * shred any file or block device, without restriction path.py: * read any file or block device, without restriction * overwrite any existing file or block device utils.py: * send any signal to any process Just the existence of these methods in nova's privsep module essentially gives the unprivileged nova process unfettered root access, which entirely defeats the purpose of privsep. As it stands today, privsep gives us literally nothing. I suspect that it's worse than rootwrap, in fact. If privsep protection is something we want, we need to do 2 things: 1. Immediately stop adding or using generic privsep functions. 2. Audit privsep properly for problematic methods, and remove them. For example, in libvirt.driver.get_console_output() we do nova.privsep.path.writefile(console_log, 'a+', data). Instead, we should have, eg, nova.privsep.libvirt.ensure_console_log_for_instance(instance). This would determine the instance path from its own secure config (see [1] again), and touch that file. We should probably also compile a list of privsep anti-patterns if there isn't one already to make life simpler for reviewers. For example, I suggest that no privsep function should take as an argument a path, or any other reference to a system resource; it should determine these itself. I view this as essentially a continuation of the privsep forklift. As with all such large mechanical changes I expect this to be disruptive and unloved by reviewers. Is it something we'd be prepared to prioritise? Matt [1] https://specs.openstack.org/openstack/oslo-specs/specs/liberty/privsep.html -- Matthew Booth Red Hat OpenStack Engineer, Compute DFG Phone: +442070094448 (UK)