Re: Questions about PAM, GDM and gnome-screensaver

[Brian Cameron <Brian Cameron Sun COM>]

Jon:

> > On Solaris, the users who have the strongest "Trusted Path" requirement
> > are most likely using CDE still.  CDE has the lock program integrated
> > into dtsession, which runs setuid root.  One nice thing about this
> > approach is if the screen saver crashes it also brings down the session
> > and takes you back to the login screen.
>
> But that doesn't fulfill the requirements of a trusted path alone.
> How do you prevent snooping and trojans for example.

Ideally the lock screen should grab server to avoid snooping.  Since
the process doesn't run as the user, and with GrabServer, it should
not be possible to snoop.

This doesn't, as you say, protect against trojans.  I think this is a
separate problem than Trusted Path, and one that requires some
consideration.

> > In JDS, we use a modified xscreensaver.  The GUI runs as the user and
> > the backend, which interacts with PAM, runs as root.
>
> But since the GUI runs as the user - game over, right?   Even if you
> do something like draw the window a different color or something that
> still isn't a trusted path.

GrabServer should protect against snooping.  If we want to protect
against trojans, then we need something more clever.

> > > Also please describe your plan
> > > for how you think we can achieve a trusted path for reauthentication
> > > and credential renewal while operating within a user's graphical
> > > session.
> > I suggested that merging GDM and gnome-screensaver might be one
> > approach.  Hacking gnome-screensaver so that the PAM interaction
> > is handled by a separate daemon process that runs as root with a
> > D-Bus interaction between them would get us as close as xscreensaver
> > currently gets us.  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 still don't think any of these things get you any closer to having a
> trusted path.

It seems the only hole that remains is trojans, no?  This seems to be
a problem across the board with all lock screen programs.  Why do you
say this approach doesn't get us closer to having a trusted path?

> One  thing is that equating running as root to having a trusted path
> or being completely secure seems pretty dense to me.

That's not what I am saying, nor is it reflective on Sun's Trusted Path
requirements.  the Trusted Path requirements only suggest that the lock
screen program run in a fashion where the username/password entry cannot
be snooped or modified by any other program running as the user.

Running the GUI as a different user is one way to achieve this, another
way is to run it as the user with GrabServer.

On Solaris, there is a requirement that end users cannot interact with
PAM directly because doing so opens the door for users to write programs
that violate Trusted Path requirements.  Sun feels it is better to
require that PAM interaction is done by a system user with appropriate
rights to interact with PAM.  This helps to ensure that if PAM crashes,
for example, a core file won't be left in the user's directory with
username/password information inside it.

So it isn't fair to say that things need to run as "root".  That's just
how its been done to date on Solaris.  PAM interaction could, as I say,
be done by any user with appropriate rights to interact with PAM.

> As I've said before, one possible approach is to have a well known and
> fixed hot key that switches to another X server where the auth stuff
> can be done.  This solves the most of the snooping problem, and also
> makes it possible for the user to verify that the prompt is not a
> trojan - unless the system itself is compromised.

That is a neat suggestion, although wouldn't this sort of solution
only work with VT on the console (and not, XDMCP remote desktops, for
example)?  Or is there a way to swap the user's running Xserver off
to the side and replace it with one running a lockscreen temporarily,
then swap the user's Xserver back once authenticated?

Brian