Re: dev/random

On Wed, Apr 14, 2004 at 12:31:31AM -0400, Robert Watson wrote:
> 
> On Tue, 13 Apr 2004, Chuck Swiger wrote:
> 
> > > Consider a PC in a University's PC access hall/lab. Would you (paranoid
> > > as you are!) trust _anything_ on that machine's hard disk?
> > 
> > I'm not paranoid...they really are out to get me.  :-) [1]
> > 
> > Anyway, in the circumstances pertaining to this thread, aren't we
> > talking about diskless clients in a university lab, and an
> > access-controlled fileserver locked away in a rack somewhere which has
> > the disks? 
> 
> I have to say that if you're loading your kernel out of TFTP, and your
> root file system is running out of NFS, the chances are you won't mind
> loading /entropy out of NFS.

It's probably reasionable to try pulling data from /entropy while
bootstrapping, but in a diskless environment, unless you add some sort
of regeneration scheme to the server, you may be worse off then if you'd
just stuck with the output of various commands.  At least /bin/date
produces different output each time you boot...

I'll admit the for the security model on my diskless cluster, I could
happily seed my PRNG with the output of a decently random version of
chargen on the boot server.  If only we had netcat in the base. :-)

> Sounds like a tunable is called for that can be turned on in that
> environment, and possible a console warning if the system is stalled >1
> second during boot waiting on entropy...

I like the idea of a console warning on blocked reads of /dev/random.

One issue we hit recently is that we don't enable any of the harvesters
until initrandom is run.  We may want to enable them by default and have
initrandom disable them based on rc.conf settings rather then the other
way around.

-- Brooks

-- 
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4