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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
