Re: Questions about PAM, GDM and gnome-screensaver

[Brian Cameron <Brian Cameron Sun COM>]

Ray:

> > For example, one issue with running gnome-screensaver or PAM as the user
> > is that it could be affected by the user environment (perhaps by a
> > GTK_MODULE) or might be snoop-able if the user can, for example,
> > inspect the memory of other processes running as the same user.  This
> > obviously breaks Trusted Path rules as defined on Solaris.
>
> By snoopable do you mean, "someone with user's privileges grabbing the
> password as it gets typed" ?

Right.  Or, if a PAM module (or something) were to crash, it shouldn't
leave a corefile with the user's password information in the corefile.
Things like this.

> > I think that these requirements also suggest that the GUI part of.
> > the program that asks for username and password should not run as
> > the user.  I am not quite sure how this should work in practical terms,
> > but I am still investigating.
>
> Okay, good.  So we do both agree that the lock dialog GUI shouldn't be
> run as root.

Right.

> > One nice thing about GDM is
> > that it is already keeping track of displays, has Xauth knowlege to be
> > able to run a GUI program as the "gdm" user on any display running as
> > another user. and already has a  mechanism for passing username/password
> > information from a GUI running as a system user to a root-running daemon
> > that talks to PAM.
>
> I don't think running gdm-user processes in the session is a good
> idea.  You either
> ignore xsettings and don't get the right theme and a11y modules, or
> you allow xsettings and violate your rule above about not letting
> GTK_MODULES go into the pam program.

Assuming that GDM were to manage the lock screen, perhaps it could be
configured so you can specify whether to run the lock screen as the user
or another user.  Some users might care more about the added protection
provided by running the GUI as another user, and not care about theming.
Theming is probably not used that extensively in a lock screen program,
and on Solaris, we'd probably need to sacrifice theming to meet Sun's
interpretation of Trusted Path requirements (whether it benefits
security in reality or not I guess is another discussion).

> > Also, why have two daemons when one will do fine?
> > The more I think about it, the more this direction seems to make
> > sense from a "make sure its as difficult as possible to disclose
> > sensitive information from the lock screen" perspective.
>
> It doesn't solve the "credentials renewal" problem we talked about
> before though.

On Solaris, I believe we use pam_setcred to refresh credentials 
(REINITIALIZE/REFRESH).  I'm attaching the manpage for reference.  I'm
assuming you do this some other way on Linux?

----

From your other email:

>> It probably makes sense to provide an option
>> where gnome-screensaver will grabserver to ensure other Xprograms
>> running as the user can't snoop.  Then this option could be on by
>> default on Solaris.
>
> I would advise against that.  It's broken.  If you grab the server
> then all single-threaded gui network applications are going to time
> out since they'll be blocking waiting on X and not processing network
> I/O.

GrabServer isn't for everybody.  It probably makes sense for it to
be a configurable option.  Or perhaps there is a better way to prevent
snooping.  But I think the choices are either run the GUI as a different
user and sacrifice theming or run with GrabServer.  Or perhaps Jon's
idea of running the lockscreen on a different Xserver altogether
might be an approach.  Or am I missing something?

> It doesn't prevent snooping either.  All grabbing the server does is
> prevent events from getting delivered, it doesn't prevent sniffing the
> key presses as they come in.
>
> A 10 line program that calls XQueryKeymap in a loop can catch key
> presses even when the server is grabbed.

I don't think this is the case.  Note Alan's response.

>> Instead we want to run the GUI as the
>> user, and have this program talk to a daemon (perhaps via D-Bus)
>> which runs as root and is responsible for PAM interaction, much like
>> GDM (and the hacked xscreensaver we currently use) does.  Hopefully
>> this is more clear now.
>
> I don't think it would necessarily be bad if the pam conversation took
> place in a process that's separate from the gui.  I don't think that
> process should run as root though.

I agree.  It probably should be configurable.  It only needs to be a
user with rights to interact with PAM.

Brian



PAM Library Functions                           pam_setcred(3PAM)



NAME
     pam_setcred - modify/delete user credentials for an  authen-
     tication service

SYNOPSIS
     cc [ flag ... ] file ... -lpam [ library ... ]
     #include <security/pam_appl.h>



     int pam_setcred(pam_handle_t *pamh, int flags);


DESCRIPTION
     The pam_setcred() function is used to establish, modify,  or
     delete  user  credentials.  It is typically called after the
     user has been authenticated and after  a  session  has  been
     opened. See pam_authenticate(3PAM), pam_acct_mgmt(3PAM), and
     pam_open_session(3PAM).

     The user is specified by a  prior  call  to  pam_start()  or
     pam_set_item(), and is referenced by the authentication han-
     dle, pamh. The following flags  may  be  set  in  the  flags
     field.    Note  that  the  first  four  flags  are  mutually
     exclusive:

     PAM_ESTABLISH_CRED       Set user credentials for an authen-
                              tication service.


     PAM_DELETE_CRED          Delete user credentials  associated
                              with an authentication service.


     PAM_REINITIALIZE_CRED    Reinitialize user credentials.


     PAM_REFRESH_CRED         Extend  lifetime  of  user  creden-
                              tials.


     PAM_SILENT               Authentication service  should  not
                              generate any messages.


     If no flag  is  set,   PAM_ESTABLISH_CRED  is  used  as  the
     default.

RETURN VALUES
     Upon success, pam_setcred() returns  PAM_SUCCESS.  In  addi-
     tion  to  the error return values described in pam(3PAM) the
     following values may be returned upon error:



SunOS 5.11          Last change: 13 Oct 1998                    1






PAM Library Functions                           pam_setcred(3PAM)



     PAM_CRED_UNAVAIL    Underlying  authentication  service  can
                         not  retrieve  user credentials unavail-
                         able.


     PAM_CRED_EXPIRED    User credentials expired.


     PAM_USER_UNKNOWN    User unknown to  underlying  authentica-
                         tion service.


     PAM_CRED_ERR        Failure setting user credentials.


ATTRIBUTES
     See attributes(5) for description of  the  following  attri-
     butes:



     ____________________________________________________________
    |       ATTRIBUTE TYPE        |       ATTRIBUTE VALUE       |
    |_____________________________|_____________________________|
    | Interface Stability         |  Evolving                   |
    |_____________________________|_____________________________|
    | MT-Level                    | MT-Safe with exceptions     |
    |_____________________________|_____________________________|


SEE ALSO
     pam(3PAM),   pam_acct_mgmt(3PAM),    pam_authenticate(3PAM),
     pam_open_session(3PAM), pam_set_item(3PAM), pam_start(3PAM),
     libpam(3LIB), attributes(5)

NOTES
     The interfaces in  libpam are MT-Safe only  if  each  thread
     within  the  multithreaded application uses its own PAM han-
     dle.
















SunOS 5.11          Last change: 13 Oct 1998                    2