Re: Questions about PAM, GDM and gnome-screensaver


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

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.

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

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

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]