Re: Privileged File Access from Desktop Applications

[Jordan Glover <Golden_Miller83 () protonmail ch>]

On Friday, July 12, 2019 12:37 AM, Perry E. Metzger <perry () piermont com> wrote:

> On Thu, 11 Jul 2019 21:20:15 +0100 Simon McVittie smcv () debian org
> wrote:
>
> > On Thu, 11 Jul 2019 at 11:47:10 -0400, Perry E. Metzger wrote:
> >
> > > having to add file i/o subsystems inside of dbus(!) probably does
> > > add lots of threats
> >
> > I think you might be misunderstanding the scope of D-Bus.
>
> Not really. The whole point is that instead of having the operating
> system alone as part of your file security implementation you now
> have a brand new service, an IPC mechanism, and loads of other stuff,
> instead of having your app just do open(2) and write(2) etc.

Do you mean that IPC and D-bus aren't part of the OS? Then what is?

> It seems architecturally bad from a security perspective. The number
> the number of trusted entities, the number of moving parts, the number
> of mechanisms, and thus the number of ways things can go wrong keeps
> going up. This is a mistake. And btw, this is a major piece of
> mechanism being added just to handle the problem of someone wanting to
> pop open an editor inside a GUI to edit a system config file, which is
> not a major attack vector. But, now I have to worry about this new
> file access service providing an attack surface that didn't exist
> before.
>
> What's the right way to handle this stuff? Capabilities,
> probably. It's what they're designed for.

They're completely not designed for this case. Setting CAP_DAC_OVERRIDE
or CAP_SYS_ADMIN is very close to SUID root. See:
https://grsecurity.net/false_boundaries_and_arbitrary_code_execution.php

Jordan