[8428] in bugtraq
Re: X11 cookie hijacker
daemon@ATHENA.MIT.EDU (David Dawes)
Thu Nov 5 16:37:29 1998
Date: Thu, 5 Nov 1998 14:48:45 +1100
Reply-To: David Dawes <dawes@RF900.PHYSICS.USYD.EDU.AU>
From: David Dawes <dawes@RF900.PHYSICS.USYD.EDU.AU>
X-To: der Mouse <mouse@Rodents.Montreal.QC.CA>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: <199811041639.LAA16849@Twig.Rodents.Montreal.QC.CA>; from der
Mouse on Wed, Nov 04, 1998 at 11:39:02AM -0500
On Wed, Nov 04, 1998 at 11:39:02AM -0500, der Mouse wrote:
>>>>>>> drwxrwxrwx 2 root root 1024 Oct 30 19:57 /tmp/.X11-unix
>>>>>> Hang on, aren't those dangerous permissions?
>> XFree86 is still waiting for someone to come up with a real solution
>> to the problem.
>
>>> Potential solutions:
>
>>> - set the sticky bit on /tmp/.X11-unix, make sure the bit stays
>>> there
>
>This loses big as soon as a second user tries to fire up an X server
>after the first one has exited.
It isn't so bad if the X server removes the old socket when it exits.
It currently doesn't, but I'm looking into fixing that.
We're currently testing the sticky bit option as short-term partial
solution for XFree86 3.3.3, which is due out very soon (as has already
been pointed out, it doesn't help at all on some SYSV-based OSs).
>>> - make it world-unwritable, make sure it stays this way (this works
>>> if all your Xservers run with some extra privileges)
>
>But only then. Lots of servers don't.
>> I assume from this list that you don't have a real solution?
>
>In the right contexts, any of those could be a real solution - the
>problems I've listed are not necessarily problems in any particular
>installation.
>
>If you want us to come up with your idea of a "real solution", first
>you'll have to clarify what that means. I have a couple of ideas, but
>I'm not about to get into a cycle of proposing an idea only to have it
>dismissed as a non-"real" solution without any indication what I have
>to do to it to make it more "real".
My definition of a "real solution" is one that solves the problem without
introducing compatibility problems, loss of functionality, or other new
problems.
Two other solutions that people have suggested so far are:
- making all the servers setgid to some special "x11" group
- providing a small setgid (or setuid) helper program that creates the
socket and which only removes an existing socket if it isn't in use
(ie it can't be connected to).
Both of these probably qualify.
David
