Re: GNOME privilege library

[Sean Middleditch <elanthis awesomeplay com>]

On Thu, 2005-01-13 at 17:52 +0000, Mike Hearn wrote:
> 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.

Right.  Like I said, I was avoiding implementation details - they're
rather irrelevant at this stage.  ;-)  I was thinking D-BUS though,
although I was leaning more towards a helper invoking the backend and
using D-BUS point-to-point.  If the bus's security model is trusted and
up to the task, it certainly works using service activation.  My only
qualm then is that you need two services for each backend, one for when
it runs unprivileged and one for when it runs privileged.

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

Right.  That's why I used the term "privilege" instead of "root."
Privileges can take many forms, from SELinux controls to capabilities to
running as a certain user/group to simply being in some other daemon's
access list.  I don't want the application to ever have to care what a
privilege is or how it works - it just knows which service/backend it
wants and how to talk it.

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

Console helper supports far more than just running as root.  It also is
somewhat sudo-like in that only apps that administrator specifies can be
started using consolehelper, and that the settings for how an
application is given privileges can be set for each application.

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

Unless you disable normal su, of course.  That's something that one
might expect an administrator to do.  On a system that uses sudo, for
example, these trojans are very hampered, because only the apps that are
listed in the sudo configuration can be run with elevated privileges.
You can't trick a user into running an arbitrary program as root.  You
can still trick them to steal passwords and such, but that is a separate
and distinct problem, one that can be solved in addition to this one.
(For example, by using X extensions that allow a keypress combination to
close the focused window if its not owned by root, or whatever.)

I do not claim this system stops social engineering attacks, but it does
make it possible to remove one form of them.  That's always a good
thing.  ;-)


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

Completely not true.  The *administrator* has to want it, not the user.
If the administrator says, "only this program can be invoked by normal
users as root, and only by entering their password," then that's that.
If a user can get around that we have a major security hole.


> >   - API does not make *any* assumptions about authentication system in
> >     use on the system
> 
> That might be tricky :)

So long as the API is just "start this backend," the application and API
don't need the details.  The actual library code might have all sorts of
authentication-system-dependent code, but that can be swapped in and out
without modifying or even recompiling the application.  The application
should never, ever be responsible for asking for a password from the
user or directly invoking any security helper tools like su - that
should all be abstracted by the library.

>  
> 
> > 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 :)

Again, that isn't necessary with this system!  The time-config program
says "I need to run gnome-config-time-backend".  That's all time-config
ever does.  On OSes that have nothing more than su, that's what will
happen, sure.  On a system with PAM-timestamp, it'll only be entered
once every now-and-again.  On a system with SELinux, sudo, they'll be
entering their own password.  On a system where the admin sets it so
gnome-config-time-backend can be executed setuid root by anyone in a
certain group (and the user is in the group) no password will ever be
asked for.

The purpose of the library is to let us get apps running *now* and be
able to change all of the details of how authentication works and how
interaction with the user during authentication works whenever and
however we want, without ever breaking the applications.

> 
> thanks -mike
> 
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>