libhal-policy -> PolicyKit

[David Zeuthen]

On Wed, 2006-03-08 at 11:46 +0100, Ludwig Nussel wrote:
> The mysterious authentication agent could in fact be a library or
> program talking to some daemon or setuid program like polkit-su. 

You have to be uid 0 to use PAM, right?

> The
> difference is that the agent doesn't exec any helper that talks to
> hald on behalf of the user. It just modifies the policy. For
> granting one-time permissions some kind of cookie could be used.
> Therefore you don't need to develop an additional protocol for
> talking to gnome-format-su-helper as gnome-format-su-helper isn't
> needed.

Ah, this sounds pretty clever. However, should we be worried about
one-time-permissions e.g. a cookie? It seems to me that if we did this
we would leave a window open for other processes in the desktop session
to utilize the privilege before the asking process did. 

This may not be a big deal, if you got hostile code in the desktop
session you almost already lost and there is not much interesting said
hostile code could do except invoke methods on HAL. Stealing the user
data in $HOME seems much more interesting.

In fact this might be a welcomed feature.. after all the user _did_ auth
so we should be able to trust him; the cookie might last, say, five
minutes and allow all policy checks for uid 500 to succeed while the
cookie is in effect. A nifty icon might appear in the notification area
denoting "god mode". For the record, this is what consolehelper does 

 http://www.redhat.com/docs/manuals/linux/RHL-8.0-Manual/custom-guide/s1-access-console-enable.html

and I think it sounds sane in this case too. Or am I on crack?

Ignoring the PAM bits you mentioned in [1] for a while, how about just
having the org.freedesktop.PolicyKit service sitting on the system
message bus. It's simple, it exports one object with one interface with
the following bits

 methods:
   boolean requestAuth   (String policy, 
                          String password,
                          Grants[] additional_grants)
   boolean hasFullPrivs  (uid_t user)
   void dropFullPrivs    (uid_t user)
 signals:
   void fullPrivsStarted (uid_t user)
   void fullPrivsExpired (uid_t user)

where additional_grants is a an array of what uid's and gid's to allow
going forward on successful auth (can be extended to be more than just
uid and gid just like libpolkit, e.g. SELinux contexts or whatever).

Also, when "god mode" starts.. the signal fullPrivsStarted() is emitted
and when it expires the daemon fires off fullPrivsExpired(). One would
use these signals for maintaining a notification icon, the
hasFullPrivs() when starting it and the dropFullPrivs() for voluntarily
dropping the privs.

Would something like this fly?

> 1) if PAM is involved it may request other credentials so a model that is
> restricted to 'pass password via fd' is insufficient.

Do you think it's possible to wrap the PAM authentication conversation
sanely in a D-BUS service? Btw, someone from SUN is talking about
teaching the gnome-screensaver lock dialog about more than just PAM
password

 http://mail.gnome.org/archives/screensaver-list/2006-February/msg00005.html

That seems a bit related. I wonder if any graphical su helpers (or
screensavers) supports anything but password authentication.

Cheers,
David