Re: [gdm-list] Security?



Hi,

> 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. ???
Well, I'm saying in cases where we can do away with cookies entirely,
maybe we should.  I was just thinking out loud.

> > - 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.
Maybe not, but if pseudo-random cookies are the status quo and have
been for decades, then that should set some expectations about their
security.  Not saying we can't do better, just trying to add some
perspective.

> > - 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.
Right, we might want to just ditch cookies entirely in the local case
(Given a new enough X server to support peer creds)

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

Reading from /dev/urandom sounds fine.  It would be nice if there was
a g_random_reset_seed () function or some such that would make it
fetch a new seed for us.

--Ray


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]