[Pkg-sysvinit-devel] Bug#587665: Bug#587665: wrong PATH in urandom, find is in /usr/bin

[Henrique de Moraes Holschuh]

On Sat, 03 Jul 2010, Petter Reinholdtsen wrote:
> I gave this another try, and believe this code should work, using only
> ls and the shell builtin set.
> 
>                 # Handle locally increased pool size
>                 set -- $(LANG=C ls -l "$SAVEDFILE")
>                 SAVEDSIZE="$5"
> 
> Works for me.  Does it work for you too?

Yes, but you want "LC_ALL=C" instead of "LANG=C", as LC_ALL is the
"master override".  I have tested it in bash and dash, which is what we
support for #!/bin/sh scripts.

This stuff is done to preserve the size of the pool.  There are two
alternative ways, which don't depend on ls never changing its output
format for something that is reasonably important for security:

1. Have the urandom MINIMUM pool size in /etc/default/rcS or something
like that, and copy it into /proc/sys/kernel/random/poolsize if it
is test -gt (i.e. greater than) the current contents of
/proc/sys/kernel/random/poolsize, BEFORE we feed the new seed.

2. Just copy the contents of /proc/sys/kernel/random/poolsize to a
second file when saving the seed, and copy it back BEFORE restoring the
seed.

All this is Linux-only, I have no idea about the other kernels.

> I agree.  But, for this to work, this part of the script need to be
> removed from the start block, as it require a writable /var/:
> 
>         # Hm, why is the saved pool re-created at boot? [pere 2009-09-03]
>         umask 077
>         dd if=/dev/urandom of=$SAVEDFILE bs=$POOLSIZE count=1 >/dev/null 2>&1
>         ES=$?
>         umask 022
>
> Anyone got any idea why the saved pool is saved at boot, and not only
> on shutdown?

AFAIK, it exists for safety, you don't want to boot twice with the same
seed if seeding overrides the previous contents of the pool, or
otherwise dominates its content so much that it becomes a serious
weakness.

Now, seeding does *not* overwrite previous contents in Linux, but I
sincerely don't know how much crap you can feed the pool before it
becomes dangerous.  Since the pool is just a polinomial, it is probably
not much.  On the way out the pool is protected by SHA1, but we're
dealing with the way _in_...

We basically need someone to that can answer what is worse: feeding
/dev/random nothing for much of the boot process, or feeding it twice
the same N bytes.

And if we keep the seed in /var, this is all moot anyway, it needs to go
to somewhere in / (e.g. /lib/random/seed, /etc/random-seed) to be of any
use to the early boot...

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh