libhal-policy -> PolicyKit

[Ludwig Nussel]

On Wednesday 08 March 2006 13:58, David Zeuthen wrote:
> 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?

In general yes.

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

Without additional confinement technology a hostile program could
also just hijack others by using ptrace. It could also install a key
logger and repeat the authentication procedure. So you basically
have to trust the user as a whole rather than individual programs.

> 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 

You can trust the user but can the user trust himself? I for myself
don't :-) E.g I don't want to accidently shutdown the computer
because I have authenticated to format a floppy some minutes ago.
Could be personal paranoia though :-) Anyways, if the authentication
agent uses pam you'd get that god mode/caching feature automatically
on distributions that support it. The user won't see the difference
between a cookie that lasts for some time and the authentication
agent handing out new cookies without popping up a dialog.

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

I can't answer that question for you ;-)

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

I don't understand the purpose of additional_grants but I don't have
a clue about SELinux either.

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

Maybe, except for the PAM problem.

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

I don't know enough about dbus. The pam conversation is basically a
callback function with a form as parameter. The form contains an
arbitrary number of messages and prompts. You'll have to fill in the
values for the prompts and return from the callback function. PAM
may perform as many conversations as it needs to.

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

Most of them get it wrong. usermode does it properly to some extend.
I just can't get used to it's code though. FWIW I've started writing
a clone with some more features and a library for integrating it
into other applications: http://www.suse.de/~lnussel/pamwrapper/
There's a pam module included that allows you to configure the
conversation it performs via text file. You can use it to test how
applications using pam authentication behave.

cu
Ludwig

-- 
 (o_   Ludwig Nussel
 //\   SUSE LINUX Products GmbH, Development
 V_/_  http://www.suse.de/