Failed X11 authentication does the wrong thing

[Darren Moffat]

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

>> >and doing su - both changes the value of ~ and makes it impossible for
>> >you to read the file because it has to be readable only by the owner.
>> 
>> Not true at all, there is no enforcement of the permissions on the
>> .Xauthority file by xauth or anyone else that I know of and there are
>> no restrictions mentioned in the standard X11R6.4 man page for xauth.
>
>I didn't intend to imply that it was a fundamental limitation, just that
>it had to be that way for security reasons.

But you used the words ;-)  I think I know what you mean though.

>> Okay so this involves the user opening up the permissions on their
>> .Xauthority file to everyone if the users home directory is NFS mounted.
>
>Or any other user on the local system even if the user's home directory
>is not NFS mounted.

If you do the chmod yes,  what ai was trying to say was that if the
home directory is local then root could read it anyway so you wouldn't
need to change the perms.

>> If it is local then root could read it anyway (at least on traditional unix
>> filesystems). 
>
>True.  I believe I've seen cases where su'ing to root (without '-') results
>in the original user's .Xauthority file being owned by root, which messes
>things up too.

The only 3 cases I can think of how that happens is:

1. Local homedir no pre exising .Xauthority, the su action creates one
2. As above but over NFS and homedir is 0777
3. A setuid xauth - bad idea!

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

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.

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

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

/usr/ucb/ps e  (Or if your are on a BSD system I guess that is /usr/bin/ps )

/usr/bin/ps on Solaris can't do that since it is no longer setuid and there
is no way to access someone elses environment via proc unless you are 
priveleged.  

Even still I don't agree with putting security information into
environment variable or on the command line.

--
Darren J Moffat