One of the challenges with nova (and I'm working from some earlier conversations, not a first-hand reading of the code) is that we can't restrict file operations to any particular corner of the filesystem, because the location of the libvirt data is stored (only) in the database, and the database is writeable by "unprivileged" nova code. My understanding is that it's considered a feature that the libvirt data directory can be changed at some point, and old instances will continue to operate in their old location just fine.
There's a number of ways to improve that (restrict to a list of configured dirs; limit access to dirs owned by a particular (non-root) uid/gid; etc) but any translation of the nova file-manipulation code to something more secure will rapidly run up against this "so how do we work out what should actually be allowed?" policy discussion. The conclusion of that discussion will probably require broader nova changes than simply adopting privsep - just fyi. - Gus On Fri, 10 Jun 2016 at 09:51 Tony Breeds <t...@bakeyournoodle.com> wrote: > On Fri, Jun 10, 2016 at 08:24:34AM +1000, Michael Still wrote: > > On Fri, Jun 10, 2016 at 7:18 AM, Tony Breeds <t...@bakeyournoodle.com> > > wrote: > > > > > On Wed, Jun 08, 2016 at 08:10:47PM -0500, Matt Riedemann wrote: > > > > > > > Agreed, but it's the worked example part that we don't have yet, > > > > chicken/egg. So we can drop the hammer on all new things until > someone > > > does > > > > it, which sucks, or hope that someone volunteers to work the first > > > example. > > > > > > I'll work with gus to find a good example in nova and have patches up > > > before > > > the mid-cycle. We can discuss next steps then. > > > > > > > Sorry to be a pain, but I'd really like that example to be non-trivial if > > possible. One of the advantages of privsep is that we can push the logic > > down closer to the privileged code, instead of just doing something > "close" > > and then parsing. I think reinforcing that idea in the sample code is > > important. > > I think *any* change will show that. I wanted to pick something > achievable in > the short timeframe. > > The example I'm thinking of is nova/virt/libvirt/utils.py:update_mtime() > > * It will provide a lot of the boiler plate > * Show that we can now now replace an exec with pure python code. > * Show how you need to retrieve data from a trusted source on the > priviledged > side > * Migrate testing > * Remove an entry from compute.filters > > Once that's implace chown() in the same file is probably a quick fix. > > Is it super helpful? does it have a measurable impact on performance, > security? > The answer is probably "no" > > I still think it has value. > > Handling qemu-img is probably best done by creating os-qemu (or similar) > and > designing from the ground up with provsep in mind. Glance and Cinder would > benefit from that also. That howveer is waaay to big for this cycle. > > Yours Tony. > __________________________________________________________________________ > 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 > -- > Message protected by MailGuard: e-mail anti-virus, anti-spam and content > filtering.http://www.mailguard.com.au/mg > Click here to report this message as spam: > https://console.mailguard.com.au/ras/1OBOU7cIz8/WIVtx4TniRa9AoBchPxBc/0.62 > >
__________________________________________________________________________ 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
