Open Stack

On 4/1/19 9:23 AM, Matthew Booth wrote:
> On Sat, 30 Mar 2019 at 08:32, Michael Still <mikal at stillhq.com> wrote:
>>
>> 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?
> 
> I think the answer here is that we don't have privsep functions like
> that *at all*. So instead of a generic
> privsep.data.discombobulate(device) you have
> privsep.libvirt.volume.foo.discombobulate(volume). I mentioned this as
> a general principal in my original mail which has since been snipped,
> that we should probably *never* pass a reference to a system resource
> (the most obvious example being a path) to a privsep function.
> Instead, privsep has its own config and can work that out for itself.
> This does mean a proliferation of specific privsep functions over a
> few generic ones, but that's how the security model works. In general
> we should expect classes to have a shadow privsep class containing
> security-sensitive logic.

This matches my understanding of the intent behind privsep. Instead of 
trying to figure out how to filter out dangerous paths or whatever, you 
have the privileged code build the path out of sanitized data passed in. 
You still have to be careful about preventing injection attacks (say I 
pass in [uuid]/../../..), but at least you don't have to try to write a 
rootwrap filter for every possible path in every possible driver. The 
privileged driver code itself knows the correct path and won't allow 
anything else.