Re: Questions about PAM, GDM and gnome-screensaver

["William Jon McCann" <mccann jhu edu>]

On Dec 19, 2007 7:11 PM, Brian Cameron <Brian Cameron sun com> wrote:
>
> Jon:
>
> > On Dec 19, 2007 3:05 PM, Brian Cameron <Brian Cameron sun com> wrote:
> > ...
> >> For one thing I think there is a pretty significant difference in
> >> how "Trusted Path" is considered by Linxu vs. Solaris:
> >>
> >> Linux   - The goal seems to be to avoid running process with privilege,
> >>            even when doing security sensitive functionality like PAM.
> >>
> >> Solaris - The goal is to ensure that the interaction cannot be
> >>            tampered with or disclosed.  This takes priority over any
> >>            risks running PAM itself with lower privilege.  That said,
> >>            Solaris does support "least privilege" for ensuring that
> >>            PAM modules can be implemented to run with as little
> >>            privilege as possible regardless who calls it.
> >
> > Can you please describe why you think that what you are doing now can
> > be considered using a Trusted Path?
>
> 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.

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

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

>  > And I'd appreciate it if you could specifically address some
> > of the points raised by Ray and others in previous threads.
>
> In my discussion, I've tried to answer all the points raised so far.
> Are there any that I specifically missed that you are thinking of?
> Ray, are there further questions you have?
>
> Ray's past questions mainly seemed to be about gaining a better
> understanding of why we wanted to run PAM interactions as root, which I
> think should be more clear now.  Also, by reading Ray's comments, I get
> the impression that he thought we wanted to run the gnome-screensaver
> GUI as root, which is not true.  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.

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

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.

Jon