Date: Thu, 6 Sep 2012 07:28:16 -0700 From: David O'Brien <obrien@FreeBSD.org> To: Doug Barton <dougb@FreeBSD.org> Cc: Arthur Mesh <arthurmesh@gmail.com>, freebsd-security@FreeBSD.org, freebsd-rc@FreeBSD.org, Mark Murray <markm@FreeBSD.org> Subject: Re: svn commit: r239569 - head/etc/rc.d Message-ID: <20120906142816.GA13179@dragon.NUXI.org> In-Reply-To: <50453686.9090100@FreeBSD.org> References: <201208221843.q7MIhLU4077951@svn.freebsd.org> <5043DBAF.40506@FreeBSD.org> <20120903171538.GM1464@x96.org> <50450F2A.10708@FreeBSD.org> <20120903203505.GN1464@x96.org> <50451D6E.30401@FreeBSD.org> <20120903214638.GO1464@x96.org> <50453686.9090100@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Sep 03, 2012 at 04:00:22PM -0700, Doug Barton wrote:
> On 09/03/2012 14:46, Arthur Mesh wrote:
> > On Mon, Sep 03, 2012 at 02:13:18PM -0700, Doug Barton wrote:
> >>> Yes, except /entropy is generated after /var/db/entropy/* and old
> >>> /entropy was fed in to yarrow. So I don't believe saying it's poorly
> >>> seeded at that point is fair.
I agree with Arthur here.
> The static files are provided as a means to stir the pool to unblock the
> device at boot time.
Actually we haven't blocked since 2004. See the ".seeded = 1"
initialization to 'struct random_systat random_yarrow' in
sys/dev/random/randomdev_soft.c
Per r132346:
Start the entropy device insecure/unblocked. I'll be handing over
responsibility for critical randomness requirements (like sshd)
to rc.d/*
Since then, the static files are a means to seed /dev/random to have
it operating securely ASAP. We do not document or take into much
consideration which binaries run in /etc/rc.d/* use /dev/random. Who
knows? Should the system be so aware of /dev/random's consumption?
Or is it better to get yarrow to steady-state ASAP?
Have you booted a machine with:
Index: harvest.c
===================================================================
--- harvest.c (revision 237320)
+++ harvest.c (working copy)
@@ -51 +51 @@ static int read_random_phony(void *, int
-struct harvest_select harvest = { 1, 1, 1, 0 };
+struct harvest_select harvest = { 0, 0, 0, 0 };
and these /etc/rc.conf lines:
entropy_file="NO"
entropy_dir="NO"
entropy_save_sz="0"
entropy_save_num="0"
harvest_interrupt="NO"
harvest_ethernet="NO"
harvest_p_to_p="NO"
I had no blocking during boot. My sysctl output (the last line I added
to verify I had no entropy processed):
kern.random.sys.seeded: 1
kern.random.sys.harvest.ethernet: 0
kern.random.sys.harvest.point_to_point: 0
kern.random.sys.harvest.interrupt: 0
kern.random.sys.harvest.swi: 0
kern.random.sys.harvest.entropy_processed: write=0/0, keyboard=0/0,
mouse=0/0, net=0/0, interrupt=0/0, pure=0/0
> But it is "better" (for sufficiently paranoid
> definitions of "better") to wait as long as possible after boot before
> actually utilizing the device for something important (like creating a
> new seed).
Please state a reference for this conclusion. Are you basing your POV
on common sense? From something in yarrow paper? From some knowledge
of /dev/random producing output with poor entropy?
The yarrow paper speaks of it being "preferable to have what ever extra
entropy there is in the PRNG's key". But that doesn't mean wait forever.
What do you feel is the minimal amount of pooled up entropy one should
have for /dev/random to give high quality randomness?
This is also why I changed the order of the seed inputs in 'initrandom'.
In our implementation, writes to /dev/random are handled as any good
device driver should. The input is buffered, and then an asynchronous
kernel thread is schedule to process the input. So the seed is not
worked into the system at the point the write(2) returns. Thus I put
our best entropy input ahead of our lesser one to do what I could to
reduce the time until /dev/random's outputs are "secure".
> Ummm ... I think you have the logic backwards on this. :) We have a
> system, designed with fairly thorough knowledge of how Yarrow works, and
> taking all possible scenarios into account. It's stood the test of time
> for many years now.
Has it? Have you done an analysis of its operation? A recent code
review? A cryptographic analysis of /dev/random's output vs. input?
I'm quoting the Yarrow paper and later Fortuna PRNG as documented in
Practical Cryptography.
Have you seen the
/* 7. Dump to seed file */
/* XXX Not done here yet */
comments in sys/dev/random/yarrow.c:reseed()?
Are you saying one cannot improve upon our implementation?
For instance, best as I can tell we have not fully implemented the Yarrow
design. The design depends on a specialized statistical estimator that is
used to detect abnormal situations in which the samples have a very low
entropy.
> > Also, please consider the fact that Schneier explicitly recommends
> > against reusing same entropy seed files...
>
> Yeah, I've covered that.
I'm sorry I missed that.
Could you state it again as I couldn't find where you addressed not
reusing seed input.
> What if, instead of replacing /entropy, we add an additional file in
> /var/db/entropy at boot time that is numerically 1 higher than
> $entropy_save_num ? (Note, I have to fix the rotation script to account
> for this, but I have had "improve the rotation script" on my TODO list
> for a long time now, and this is a good excuse for me to get a round
> 'tuit.) That way should the reboot happen before the default 11 minutes
> that kicks in the cron job we still have fresh entropy to reseed with,
> and we're not losing anything that we had already. When the rotation
> script runs it will delete the (IMO) low quality file created at boot,
> and saved-entropy.1 will be a fresh, clean file with (again, arguably)
> higher quality entropy that will be used at the next boot time.
I really don't see the need for this much additional complication.
> I briefly considered a different solution like appending to /entropy
> instead of replacing it,
That still leaves a replay of the part you're proposing to append to.
> but one of the reasons I'm queasy about
> touching that file at boot time is that in the event that the system
> crashes shortly after boot (which happens to those of us who track
> -current rather often) I don't want the / file system to have been
> written to.
I don't have that that kind of trouble with -CURRENT in a long time.
Even if we did, I don't think we should be optimizing for -CURRENT.
If that is what you're wanting to optimize, then why aren't you
proposing a change to /etc/rc.d/FILESYSTEMS to push it farther
down the 'rcorder /etc/rc.d/*' ordered list? 'FILESYSTEMS' exists
to say basic file systems are mounted and fully usable. If /
shouldn't be writable then make a change to keep it R/O longer.
Once a file system is mounted R/W, it is dirty if not cleanly unmounted.
What is not writing to / solve? It is still dirty if one crashes.
Is there a SU or SU+J specific bug you're thinking about?
Note that some (many?) of us have a large / containing /usr and /var due
to the new FreeBSD (and PC-BSD) installer, or following what Solaris and
Irix did on workstations. In these cases our / is getting written to
pretty early in boot.
Even with a / that does not contain /usr or /var, what is the time delta
you're saving? Amd will write to / when one logs in with NFS mounted
home dirs. Should we add a 10 minute delay before allowing any non-root
login so that we don't write to / shortly after boot? Opps, tcsh will
write a history file to /, so we should also change root's shell to
/bin/sh.
There me be some other /etc/rc.d/ script that writes to / -- should we
add a mechanism to push that to the end of the 'rcorder' ordering?
> Having the /entropy file written out at shutdown time is a
> "necessary evil" given that we can't be sure that /var is available in
> the early stages of rc,
Again, I don't understand your issue with writes to /. It isn't a R/O
file system. I would understand saying '/entropy' is ugly and clutter in
/. That's why on the system I'm writing this on I have it in /var (since
/var is part of my /).
> What do you think about the idea of adding a new file in /var/db/entropy?
I don't believe I see a use in that.
Please lists its qualities. How is it generated? Is it regenerated and if
so when and how? What is its lifetime? When will it be used?
--
-- David (obrien@FreeBSD.org)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120906142816.GA13179>