[nova] Privsep is not giving us any security

Michael Still mikal at stillhq.com
Sat Mar 30 08:21:34 UTC 2019


On Sat., 30 Mar. 2019, 6:28 pm Thierry Carrez, <thierry at openstack.org>
wrote:

> Michael Still wrote:
> > The reality is that privsep was always going to be a process. It's taken
> > more than 80 patches to get close to removing rootwrap.
> >
> > There are other advantages to removing rootwrap, mainly around
> > performance, the integration of library code, and general
> > non-bonkersness (cat to tee to write to a file as root), etc.
> >
> > There is president in the code to mark calls as undesirable, and others
> > could be marked like that as well, but ultimately someone needs to do an
> > audit and fix things... That's more than one person can reasonably do.
> >
> > So, who wants to help try and improve this? Patches welcome.
>
> It's been on my priority-2 TODO list for a while to help with that...
> Now if people would stop adding to my priority-1 TODO list...
>
> Agree that's definitely more than a one-person job, but migrating a
> specific call is also a reasonably self-contained unit of work that (1)
> does not require a deep understanding of all the code around it, and (2)
> does not commit you for a lifelong feature maintenance duty... So maybe
> it would be a good thing to suggest newcomers / students to get a poke
> at? I'm happy to help with the reviewing if we can come up with a topic
> name that helps finding those.
>

One concern I have is that I am not sure it's always as simple as it looks.
For example, we could enforce that device files are always in /dev, but is
that always true on all architectures with all hypervisors? How do we know
that?

We could add enforcement and at the same time add a workaround flag to turn
it off, which is immediately deprecated so people have a release to notice
a breakage. Do we do that per enforcement rule? That's a lot of flags!

Finally, the initial forklift has been a series of relatively simple code
swaps (which is really the root of Mr Booth's concern). Even with taking
the easy path there haven't been heaps of volunteers helping and some of
this code has been in review for quite a long time. Do we really think that
volunteers are going to show up now?

Michael

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190330/ddebb2b7/attachment-0001.html>


More information about the openstack-discuss mailing list