[Changing the topic of this subthread that has nothing to do with PAM.]

We used to prevent this by grabbing the X server so no other programs
could run, but then the GNOME accessibility architecture forced us to
stop that and allow other programs to connect to the server and
interact with input & output while authenticating (not to mention Xevie,
required by accessibility, which allows intercepting all input events
to record and or modify them).

However, we only have a Trusted Path when running Trusted Extensions
desktops, which use the Xtsol extension, which does far more than the
Security extension does, and I believe it provides all the protection
needed, but I don't know enough of the details and would hope the TX
guys (Glenn?  Lok?) can explain that.   I believe Xevie is disabled when
the Trusted desktops are running, and wouldn't be surprised if the
common accessibility helpers are unusable as well.

Frankly, I don't really see any "gaping hole in Xauth", no matter how
hard people try to spread FUD about it - it only risks the user exposing
themselves if they run untrustworthy programs or disable security with
xhost + - it doesn't allow attacks on the system itself.

        -Alan Coopersmith-           alan.coopersmith at sun.com
         Sun Microsystems, Inc. - X Window System Engineering


Brian Cameron wrote:
> 
> A more interesting issue, in my opinion, has to deal with the
> fact that it is obviously necessary for the screensaver to run
> with the user's Xauth permissions.  So it is very easy for any
> other program running as the user to snoop the password being
> entered into the screensaver using a technique like Xspy:
> 
>    http://www.acm.vt.edu/~jmaxwell/programs/xspy/xspy.html
> 
> I believe this violates the following Trusted Path requirement:
> 
>        N.B. part of trusted path is that it must not be possible for
>         any program to interpose on or impersonate the trusted
>         path.  Thus no program, nefarious or not, may view or
>         modify trusted path communication.
> 
> Using GrabServer in the lock screen program would fix this, but this
> is not a good option since that causes problems for programs that want
> to continue to draw things to the Xserver (such as if you have a Firefox
> Flash video playing behind the lockscreen)
> 
> Perhaps the Xserver security extension is a good option, but none
> of the screensavers on Solaris currently use this, or deal with the
> this problem in any way.
> 
> When I talked with the gnome-screensaver maintainer about making
> changes to gnome-screensaver to fix the "Trusted Path" related PAM
> issues we discuss above, his remark was (paraphrase) "why is Sun
> so worried about trusted path in the PAM stack, when you have this
> gaping hole with Xauth?"
> 
> Brian


Reply via email to