Re: [PATCH] ELF: implement AT_RANDOM for future glibc use

On Tue, Oct 07, 2008 at 01:19:42AM +0200, Andi Kleen wrote:
And you won't deny that session keys are more important than mmap
placement, will you?

Right, I would tend to agree that session key strength is more important
than ASLR strength.

I'd really love to see this solved. My goal is to get a mainline glibc
patch for a low-cost randomized stack guard value.

Your current implementation is high cost.
...
random32() is not a cryptographically strong RNG. I suspect it would
be pretty easy to reverse engineer its seed given some state. It hasn't
been designed to be protected against that.

It's being used for randomness in the networking code, so it's at least
mildly random "enough".

IMHO it needs a new class of random numbers in the kernel that use
some cryptographically strong RNG (there are a couple of candidates
like yarrow) which is very rarely seeded
from the entropy pool[1] and use that for these applications.
A couple of other users in the kernel would benefit that too,
most users of get_random_bytes() probably should be reviewed
for their true requirements.

Sure, but this is a larger (and pre-existing) problem.

Ideally expose it to userland too so that dumb users like
tmpfile can use it too.

Would you propose that it get hooked to /dev/urandom?

-Kees

--
Kees Cook
Ubuntu Security Team
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/