On Wed, 2014-07-16 at 13:17 -0700, Russ Allbery wrote:
> Ben Hutchings <ben@decadent.org.uk> writes:
> > On Wed, 2014-07-16 at 12:47 -0700, Russ Allbery wrote:
>
> >> It would be nice to have a reliable kernel interface for getting
> >> randomness rather than relying on proper chroot configuration.
>
> > There is such an interface. It happens to be a char device. Expecting
> > administrators to create /dev/urandom in a chroot is no more
> > unreasonable than expecting them to create /dev/null or /dev/zero.
>
> I'm not a big fan of that either. :) Also, I think it's relatively rare
> for a library to require those devices exist for secure behavior, although
> perhaps I'm just not knowledgable in this area.
Since Linux 2.6.29, you get 128 random bits at each execve(), which you
can access like this:
/* BEGIN */
#include <stdio.h>
#include <sys/auxv.h>
#ifndef AT_RANDOM
#define AT_RANDOM 25
#endif
int main(void)
{
unsigned int *bits = (unsigned int *)getauxval(AT_RANDOM);
if (bits) {
printf("%08x%08x%08x%08x\n", bits[0], bits[1], bits[2], bits[3]);
return 0;
} else {
fprintf(stderr, "no random bits available\n");
return 1;
}
}
/* END */
This is wanted to support things like stack protection in the C runtime,
which really can't depend on /dev/urandom.
I'm not sure 128 bits are enough in general, though they are still
better than pid and time. And every child process that doesn't execve()
shares them with its parent (a much worse problem than the LibreSSL
bug).
I can only assume that many libraries still fail-unsafe in the absence
of /dev/urandom. They should at least mix in the AT_RANDOM bits.
> >> I'm not sure sysctl should be that mechanism, but I'm quite sympathetic
> >> to the LibreSSL developers here. Relying on a device being present in
> >> a chroot seems rather dubious.
>
> > Less so than blundering on without entropy.
>
> Oh, certainly. I'm in favor of aborting in libssl if /dev/urandom isn't
> available. But it bothers me that one could get to that point. It seems
> like an easy mistake for someone to make, and it seems somehow unclean to
> require access to a char device for randomness.
>
> I'm sure I'll get over it, but I do agree with the feeling that a lot more
> can go wrong when trying to open a character device than with some of the
> other approaches suggested.
Given that no alternative mechanism exists in Linux today, even if a
simpler mechanism was added tomorrow a general purpose library will have
to be prepared to fall back to the char device. And it is really not
that difficult to use, so I don't see much need to add that simpler
mechanism.
Ben.
--
Ben Hutchings
Kids! Bringing about Armageddon can be dangerous. Do not attempt it in
your own home. - Terry Pratchett and Neil Gaiman, `Good Omens'
Attachment:
signature.asc
Description: This is a digitally signed message part