Re: [gdm-list] Security?

[George <jirka 5z com>]

On Fri, Nov 30, 2007 at 12:43:58PM -0500, Ray Strode wrote:
> So just a couple of comments,
> 
> - In the local case, we probably want to rely on socket peer
> credentials instead of auth cookies anyway (i.e., does the user
> calling XOpenDisplay have a uid that's okay with the server)

That should be in addition to having a safe cookie.  Note the phrase
"probably want to" in your response.  Also note that gdm is likely to get
used in systems which do not have X set up the way you want to.  And you want
gdm to be secure. ???

> - If you ask the X server for an auth cookie (using
> XSecurityGenerateAuthorization), it will give you one back using an
> algorithm very similar to the one we're using now

Then the X server is broken.  X code has generally been very broken with
respect to MIT-MAGIC-COOKIE-1 anyway.   xdm used a rand() initialized with
current time in seconds, not too long ago.  Just because X does it wrong,
doesn't mean that gdm should do it wrong.

> - In the remote case, XDMCP is pretty insecure regardless.  Everything
> goes over the wire unencrypted, for instance.  So you should really
> only be using it if you know you're in a secure environment.

XDMCP is crap, no denying it.  The trouble is that currently knowing the
cookie locally can lead to a user snooping passwords.

> - It wouldn't be hard to make _generate_random_bytes call
> g_random_set_seed every 4 bytes (or use make our own GRand instance
> each call with enough entropy for the size passed in).  I can look
> into doing that.

Why?  why not just read /dev/urandom?  What is the damn obscession with
calling GRand?  I don't see ANY advantage, even in code size.

set_seed with what?  You must feed it random data.  So you have to have
random data.  So what's the point of going through GRand?

Jiri

-- 
George <jirka 5z com>
   A clever man commits no minor blunders.
                       -- Goethe