Re: GNOME privilege library

[Colin Walters <walters redhat com>]

On Thu, 2005-01-13 at 11:26 -0500, Sean Middleditch wrote:

> 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.

I think this is a good approach as well.

> 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.  

At present, SELinux has no capability to override the normal DAC
permissions.  So it can't be used for e.g. Mike's example, where an
application wants access to the USB ports.  The application has to have
the normal DAC permissions (which in this case basically means uid 0).

> Additionally, random applications should not be able to just start any
> process with privileges.  

This is very difficult to achieve.  I don't think we should try to solve
it right now, at least not in the way you propose.  The LD_PRELOAD
environment variable that other people have raised is just one of the
many varied means of possible influence one application can have on
another.  Another example is ~/.gtkrc, or X.

The first goal is to have a defined means of granting a user additional
privileges.  Unix has traditionally only offered setuid applications,
which are obviously bad for a huge number of reasons.    

We've actually been solving this problem recently in what I consider the
right way: a system D-BUS service (running as root) which interacts with
the user session in a well-defined way.  Look at HAL and NetworkManager.
HAL grants console users the ability to mount devices by
modifying /etc/fstab in a specific way.  It also exports a lot of
information that would otherwise require root privileges to obtain (e.g.
card link status).  NetworkManager is an even better example - it
provides a simple D-BUS API which ordinary users can use, and the
ability to control wireless networks is restricted to the console user.
The user is not granted arbitrary control over networking.

> Imagine a trojan application a user downloads
> that informs the user it needs root privileges 

My opinion is that at this point you've already lost - execution of
arbitrary code in the same security domain as the rest of the desktop
session.  The right solution is to prevent this execution, or to ensure
it is in a separate security domain.  But this is a whole separate
topic.

> /usr/libexec/gnome-procman-renice is only registered
> to /usr/bin/gnome-procman, for example.  If ~/Downloads/random-trojan
> tries to use it the API would refuse, until the administrator granted
> that binary access.  It's notable that SELinux already provides this
> feature - but again, we cannot rely on it being available everywhere
> GNOME is used.

SELinux *can* provide this feature, but the code must be written to
support it.  Let's say that you run gnome-procman in a separate security
domain (e.g. user_gnome_procman_t), and only allow it to execute e.g.
procman_renice_t (the label on /usr/libexec/gnome-procman-renice).  But
if ~/Downloads/random-trojan is run in the same domain as the rest of
the desktop (e.g. user_t), then you have essentially lost since there is
a great deal of flow from user_t to user_gnome_procman_t, via ~/.gtkrc
or X or whatever.  This isn't really a SELinux issue - I don't see how
any security mechanism could solve this without reengineering the code
without the assumption that the entire desktop is one big security
equivalence class.

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

Agreed.

>   - applications can start and stop the backend process at any time

Not sure I see how this is particularly useful.

>   - API provides clean and safe abstraction over starting and
>     communicating with the backend process

D-BUS :)

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

The approach we've been taking in Fedora is that the user is just not
prompted for authentication.  For example, NetworkManager doesn't force
you to enter the root password to switch wireless networks.  Nor does
HAL force you to enter the root password to access your USB key.  As
Havoc mentioned earlier, I think this is generally the right approach.

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

Let's write this one off as not solvable for now.