Re: GNOME privilege library

[Mike Hearn <mike navi cx>]

On Thu, 13 Jan 2005 11:26:17 -0500, Sean Middleditch wrote:
>
> [snip lots of sensible thinking]
>

> The case against using a backend process with a non-privileges front-end
> has mostly to do with complexity.  There is a need to be able to
> arbitrarily start and stop a backend with or without privileges and to
> communicate with that backend safely.  Writing the code to manage this
> is very low-level and error-prone.  I believe that the GNOME framework
> should provide simple API to manage this scenario so that more apps can
> quickly, easily, and securely build an application that uses a
> privileged backend.

The most obvious API for this is just letting DBUS or Bonobo start
services with a higher privilege level. This is the technique used on
Windows to solve the same problem: frontends communicate with services
running with administrator access typically via DCOM. For instance iTunes
does that to access the USB ports directly, something a regular app cannot
do.

> This gets to the main point.  The GNOME privilege API should not be
> built around invoking an application, but instead should be built
> entirely around starting and communicating with a backend process.

That's RPC which GNOME already has good support for. Leveraging that to
make this use case as simple as possible seems wise.

> The trickiest part of this is, of course, the authentication itself.
> The problem with libgnomesu is that it's built around the idea of
> starting an application as a specific user.  That is an implementation
> detail.  On an SELinux using system, there may be no need to run as root
> - simply switch to using a more privileged role.  

Or indeed the backend process may be running at a lower privilege level
than the frontend but selectively have particular permissions regular apps
don't. 

> On a sudo-using system
> the sudo rules should be used.  On a system that already provides a rich
> authentication-management solution such as consolehelper, that system
> should be utilized.

I'm not sure I'd call consolehelper a rich management solution. It's just
a fancy way of displaying a "Please enter the root password" dialog except
at app startup instead of Just-In-Time.

> Additionally, random applications should not be able to just start any
> process with privileges.  Imagine a trojan application a user downloads
> that informs the user it needs root privileges and pops up the
> authentication dialog; this is an easy and common social-engineering
> attack.  

I strongly disagree with this. Social engineering is a research level
problem, it's certainly not something that can be fixed or even
partially addressed with a framework design. Eg a trivial way around that
is to simply ask the user to open up a terminal and paste su -c
"myprogram" in then enter the root password.

Or you can do what autopackage does and write a fancy GUI frontend to su
using all kinds of weird pty tricks. There's nothing wrong with this
technique.

I think we have to be totally clear and unambiguous on this point:
security is *not* achieved by annoying the user. Once the user has made a
decision to run I-LOVE-YOU.bin or whatever we lost already,
making it hard for them to act on their decisions doesn't solve anything
at this point. 

That means defending against social engineering becomes helping the user
to reach the right decision by providing them with enough information to
see through the deception, eg by having a distributed
whitelisting/blacklisting system.

Requiring scripts and binaries to have the +x bit set is dumb for similar
reasons: it's trivially worked around by checking the right box in
the UI and simply slows the user down. That's not the right way to make a
usable desktop.

> If, instead, the framework only allows certain apps to be
> started with privileges, this attack cannot work.  While consolehelper
> takes this approach, it cannot be relied on since many OSes do not
> provide it, and others specifically do not want to use it.

That's impossible to do without fundamentally redesigning the OS and all
the apps: Linux has always allowed any arbitrary program to run as root if
the user wants it to, that cannot be changed now.

> Summary of API:
>   - all privileges are in backend processes, not the GUI application
>     itself

Right ...

>   - applications can start and stop the backend process at any time -
>   API provides clean and safe abstraction over starting and
>     communicating with the backend process

DBUS should already provide this, no?

>   - API does not make *any* assumptions about authentication system in
>     use on the system

That might be tricky :)

>   - API is pro-active on security by only allowing certain applications
>     to use certain backend

Now that's certainly possible with SELinux as DBUS is a user-space AVC,
it's rather harder with regular UNIX security. But let's be clear about
what the point is, it's "principle of least privilege" in action, it's not
going to stop social engineering.
 
> The final piece of the puzzle is in regards to the backend/application
> registration.  

DBUS services API already does most of this I think.

> Do the requirements and general design seem acceptable?  Are there any
> use-cases that we want to support that this will not work for?  Are
> there any additional features that we need?  Is there any authentication
> system that this cannot handle?  Any general objections?

The concept of having the user enter a magic password over and over to
achieve basic sysadmin tasks like setting the date/time seems pretty
broken usability-wise to me but I have no idea how else to do it :)

thanks -mike