<div dir="ltr"><div><div>On Fri, Oct 18, 2013 at 1:05 AM, Kent Borg <<a href="mailto:kentborg@borg.org">kentborg@borg.org</a>> wrote:</div><div><br></div><div>> On 10/17/2013 08:32 AM, Adam Back wrote:</div><div>></div>
<div>>> I think the more worrying case is a freshly imaged rack mount server,</div><div>>> immediately generating keys or outputting random numbers to the network or</div><div>>> in response to network queries.</div>
<div>>></div><div>></div><div>> There are certainly larger system issues, and anyone doing</div><div>> auto-provisioning of servers and generating keys before any entropy has</div><div>> accumulated could get burned.  Though to be fair to /dev/random, isn't this</div>
<div>> a larger Linux distribution issue?  Don't automatically generate keys on</div><div>> first boot.  RNGs that need seed data should not be run empty.</div><div>></div><div>> But is this something that /dev/urandom might do better?  Should blocking</div>
<div>> be added to /dev/urandom immediately after boot until some reasonable</div><div>> threshold has been reached at least once?  Or on first boot are common</div><div>> distributions restoring a bad seed file and /dev/random can't tell?  Arrgh,</div>
<div>> I am starting to think that the RNG is the wrong place to fix it.</div><div>></div><div>> Should RNGs attempt to detect uninitialized states and refuse to run?</div><div><br></div><div><br></div><div>Sometime in the last two months I described the somewhat widespread issue</div>
<div>at VM hosting/cloud providers of provisioning VM's with the same</div><div>/dev/urandom seed from the image template. firstboot scripts typically only</div><div>get run at image generation, and then the urandom seed is frozen in amber,</div>
<div>as it were, in the VM image template file. It is a fairly trivial fix to</div><div>re-seed it from /dev/random (one line in the right place).</div><div><br></div><div>The obvious place to do that, when the VM is actually provisioned, ends up</div>
<div>hurting deployment time due to sometimes blocking on /dev/random reads to</div><div>re-seed /dev/urandom. This has led people to toss up their hands and do the</div><div>Wrong Thing of just provisioning, sometimes thousands, of VM's with the</div>
<div>same /dev/urandom seed.</div><div><br></div><div>Quequeing up pre-provisioned system images with the one liner to re-seed</div><div>/dev/urandom from outside the image itself (other per-system security</div><div>related config can happen here, too) takes care of it, but then you get</div>
<div>people whining about shuffling around image files rather than quick copy on</div><div>write delployments of VM images.</div><div><br></div><div>Then someone at that provider has to realize you just do the queueing</div>
<div>per-storage system used by each hypervisor host against copy-on-write</div><div>images. This chain of logic and refinements thereto have not, to my</div><div>knowledge, been written up in any widely known best practices document. I'd</div>
<div>love to be shown somewhere they have to point people at if it exists.</div><div><br></div><div>-David Mercer</div></div></div>