From owner-freebsd-security@FreeBSD.ORG Thu Sep 6 14:28:17 2012 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: by hub.freebsd.org (Postfix, from userid 664) id D662A106566C; Thu, 6 Sep 2012 14:28:17 +0000 (UTC) Date: Thu, 6 Sep 2012 07:28:16 -0700 From: David O'Brien To: Doug Barton Message-ID: <20120906142816.GA13179@dragon.NUXI.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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50453686.9090100@FreeBSD.org> X-Operating-System: FreeBSD 10.0-CURRENT X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Arthur Mesh , freebsd-security@FreeBSD.org, freebsd-rc@FreeBSD.org, Mark Murray Subject: Re: svn commit: r239569 - head/etc/rc.d X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@freebsd.org List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 14:28:18 -0000 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)