Re: GNOME privilege library

[Carlos Garnacho <carlosg gnome org>]

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

I agree a lot, it matches with my future plans for the
gnome-system-tools backends, where there should be an standard
comunication channel with the frontends (my main candidates were DBUS
and SOAP) and an API abstracting all the comunication.

	Regards

> 
> > 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
> 
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list