Failed X11 authentication does the wrong thing

[Dave Dykstra]

On Thu, Jul 26, 2001 at 12:39:10PM -0700, Darren Moffat wrote:
> >On Thu, Jul 26, 2001 at 12:00:54PM -0700, Darren Moffat wrote:
> >> >That's a fundamental limitation of the way ssh does forwarding of X 
> >> >connections; it stores the authentication information in ~/.Xauthority,
> >> 
> >> I don't believe any of this has anything what so ever to do with the
> >> X11 forwarding functionality of ssh since you get exactly the same behaviour
> >> on a local login.
> >
> >That's true, if you're using xauth.
> 
> xauth is what OpenSSH uses so what other X authentication are you talking
> about that has this limitation ?

It seems that we keep missing each other's meanings in this email
communication media.

I meant to say that any X access using xauth, including what OpenSSH does
for X forwarding, has the limitation.  If you're using plain old xhost
authentication (abhorrent though it is) you don't have the same problem.

My original statement did not intend to imply that I could think of some
better way for OpenSSH to do X authentication, I was just trying to 
explain to the original questioner that the symptom he was talking about
could not be easily solved.

...
> >> I've also written a PAM module for use with su that uses xauth to
> >> make a copy of the cookie for the current DISPLAY out of the src users
> >> .Xauthority and put it into the destination users .Xauthority.  This a
> >> safe way to do it - if I ever get the time I'll update the PAM module
> >> to remove the cookie from the .Xauthority when the session exits.
> >
> >Interesting, but not necessarily safe, if a group of people share the login
> >you su to.  It's too bad that the xauth magic cookie can't be in an
> 
> Which is why people should use RBAC systems rather than su to root ;-)
> (Actually it really needs to be RBAC plus fine grained privilege).

Forgive my ignorance, but what's RBAC?  I guess "something something Access
Control".

> How else do you suggest it is done ?  root needs the cookie to connect
> so you have to give it to them some how, if other people use root and you
> don't trust them then don't log into that machine.

Ah, I was thinking mainly of su'ing to other shared user ids, not root.
That was our disconnect, and may explain all the confusion that we've had
in this discussion.  Does your PAM module only copy the cookies when su-ing
to root?

If you're su-ing to root anyway, perhaps all you need to do is set
$XAUTHORITY to point to the original user's $HOME/.Xauthority.  Oh, I see,
when you're going over NFS, access by the root user id is usually
disallowed.  Was that the main purpose for your PAM module?


> I agree that it isn't idea but it is the best that can be done when using
> the xauth cookie mechanism.

It is indeed very limiting.




On Thu, Jul 26, 2001 at 03:51:40PM -0400, Nicolas Williams wrote:
> On Thu, Jul 26, 2001 at 02:29:19PM -0500, Dave Dykstra wrote:
> > On Thu, Jul 26, 2001 at 12:00:54PM -0700, Darren Moffat wrote:
> > ...
> > > I've also written a PAM module for use with su that uses xauth to
> > > make a copy of the cookie for the current DISPLAY out of the src users
> > > .Xauthority and put it into the destination users .Xauthority.  This a
> > > safe way to do it - if I ever get the time I'll update the PAM module
> > > to remove the cookie from the .Xauthority when the session exits.
> > 
> > Interesting, but not necessarily safe, if a group of people share the login
> > you su to.  It's too bad that the xauth magic cookie can't be in an
> > environment variable.  On the other hand, I think some systems make it easy
> > for other people to dump out your environment variables so that would be no
> > good either.
> 
> Ideally the X libs would support the same sort of concept as the
> ssh-agent but for accessing X cookies.
> 
> In fact, I'd really like to see an all-purpose agent along the lines of
> ssh-agent, but not just for SSH keys: Kerberos ccaches, X cookies, NTLM
> hashes (think about Samba's smbsh/smbwrapper) and so on.


But ssh-agent suffers essentially the same problem when su-ing to other
user ids: the inherited environment variable only points to a unix-domain
socket that's accessible only by the original user and root.  I was trying
to think of a way of passing the authentication through when you su to
another user.

- Dave Dykstra