Re: Questions about PAM, GDM and gnome-screensaver

[Brian Cameron <Brian Cameron Sun COM>]

Ted:

> On Fri, 2008-01-04 at 14:59 -0600, Brian Cameron wrote:
> > 1) Since the lockscreen runs in the user's Xserver, there are
> >     ways to snoop or corrupt the password via X interfaces.  There
> >     doesn't seem to be an easy answer for fixing this.  Making
> >     the Xserver GrabServer has been mentioned, but isn't a great
> >     solution.
>
> Yeah, so it seems the only way to get around this is the use the
> Security extension.  I wasn't sure from the other e-mails, what does Sun
> do to solve this problem today?  Would not being able to block this
> attack be a regression?

Sun doesn't currently protect against this kind of attack very well.
In CDE, screen lock is managed by dtsession, which does grab the
keyboard and mouse, but not the server.  When using GNOME,
xscreensaver is used which likewise doesn't protect against this
kind of attack.  Since the server isn't grabbed, this leaves the
door open for snooping the keys as they are typed via X-calls.

I think that Sun would like to address this problem, but not being
able to block this attack would ot be a regression.  In other words,
I think Sun's lock screen programs are not conforming to Trusted
Path requirements (as required by Sun) very well.

> If the solution uses PolicyKit could Sun provide their own
> Authentication Agent that implements this the same way as today?  It
> would seem that the same requirements would be in place for other
> PolicyKit authentications.

It isn't clear to me how you propose PolicyKit would be a part of
the solution.  Perhaps you could clarify.

On Solaris, there is a preference to using RBAC (Role Based Access
Control) for access control.  There has been some talk about making
PolicyKit a wrapper around RBAC on platforms that use RBAC, but
it is probably a bit early to tell how this will evolve.  PolicyKit
isn't yet a part of Solaris, but I suspect it will get added once
the relationship between RBAC and PolicyKit gets figured out.

> > 2) If PAM isn't run as the user, then PAM won't refresh credentials
> >     that are in userspace (e.g. a Kerberos credential in
> >     gnome-keymanager).  On Solaris, where we don't run PAM as the
> >     user anyway, this proposal doesn't break things any worse than
> >     it currently is.
>
> It seems like this is also solved by the authentication agent.  Since it
> exists in userspace, it is the one who would query gnome-keymanager or
> other source to get the authentication.
>
> http://hal.freedesktop.org/docs/PolicyKit/model-theory-of-operation.html

Yes, this makes sense.  It seems like there is probably some handshaking
that is needed between the user and the user with PAM privilege to make
sure that everything is set up properly on both sides.

> > 3) There are probably situations where the existing behavior of
> >     running PAM as the user is desirable (perhaps on Linux), so
> >     it is probably desirable for it to be possible to configure
> >     which user actually interacts with PAM.  On Solaris this should
> >     probably be a user with enough privilege to interact with PAM
> >     (and not the actual user locking the screen).  On Linux it is
> >     probably okay to run as the user locking the screen.
> >
> > 4) This discussion may just be theoretical since I don't get the
> >     impression that all the parties involved really agree how this
> >     should be done.  Though, the more we discuss, the more likely
> >     we will converge on some clever idea perhaps.
>
> While I'm not a GNOME Screensaver maintainer I would say that I haven't
> seen a "No we hate you" on the list, more of a "I'm not sure this design
> will work out for what you need."  

Oh, I haven't gotten the impression that anybody is being hateful.  I
think people in general recognize that there is some security advantage
to running PAM not as the user, and to ensure that X can't be used to
snoop the username/password entry.

However, addressing these issues does add complexity to the task of
locking the screen.  I can understand why people might not be
enthusiastic about adding such complexity.  Many people might have the
attitude that the lock screen program has been insecure in these ways
forever, so why bother fixing it.

> I would like to see more discussion.
> From the Ubuntu perspective I forwarded a few representative e-mails
> from this thread to one of our security folks, he seemed to think that
> while not required, the idea of moving the screensaver under GDM was a
> good one.

GDM and the lock screen program do a lot of similar tasks.  It seems
better to have one daemon which is in charge of doing things like
talking to PAM and audit rather than having two.  I realize that
PAM/audit is handled a bit different for login authentication and for
screen lock, but I still think it probably makes more sense to have
this code in one place rather than two.

> There are a few services that seem to be lacking in GDM in general.  It
> would make sense that he login prompt would have a reasonable
> screensaver and power management.  But, in general I think that this
> discussion doesn't cover those.

I know Jon is working on integrating power management into GDM.

> The two things that I'm concerned about are usability and accessibility.
> Once the password dialog is removed from the user's settings I'm not
> sure how you maintain their theme (perhaps color blind issues) or their
> external hardware (screen reader, etc.).  How does the Sun locking
> dialog work today with those features?  I imagine they are requirements
> for many of the gov't contracts Sun has.

It doesn't work well.  Currently Sun's hacked xscreensaver uses the
LoginHelper interface to support accessibility.  This is supposed to
help xscreensaver know which programs are allowed to display on top of
the lock screen dialog.  This way programs like GOK and the magnifier
can run on top of the lock screen program to provide needed tools for
users with a11y needs.

The problem is, however, that this has never worked very well.  To my
knowledge it is only actually implemented in the hacked xscreensaver
that Sun ships and not on Linux with gnome-screensaver, etc.  I
understand LoginHelper has a lot of bugs that make it nonfunctional for
many users.  So, it isn't a great solution.

My personal feeling is that it might make more sense to integrate
simple on-screen-keyboard and magnification features directly into
the lock screen dialog.  The lock screen password entry would
only require a more simple on-screen keyboard than is required for
general desktop use.  Magnification could probably be handled by simply
providing a hotkey which increases/decreases the fontsize used by
the lock screen program.

Since Orca doesn't use X at all (it just takes the info from the
GUI via the CSPI interface, and then pipes it to text-to-speech or to a
braille display), it is more easy to support running orca with the lock
screen program (or GDM).  You don't have to worry about Xauth issues
anyway.

From an accessibility perspective, it probably is okay if the user's
theme settings are lost as long as it is easy to get them back again.
Perhaps a hotkey for switching to a11y themes would be needed.  It
would be better, but not necessary, if there were some handshaking
between the user and the lock screen program to set the  theme properly
in a more automatic fashion.

Running the lockscreen GUI as the user with the Security extension
might be a good solution for keeping the user's theme without extra
hassle.

I would say all the above analysis is also true for GDM.  It
probably would make more sense to integrate on-screen-keyboard,
magnification, theming, etc. directly into GDM using the same sort of
techniques rather than supporting launching AT programs like GOT
or gnome-mag directly.

Brian