From owner-freebsd-rc@FreeBSD.ORG Mon Sep 3 20:13:28 2012 Return-Path: Delivered-To: freebsd-rc@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id 41F8E1065673; Mon, 3 Sep 2012 20:13:28 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 43664151B6A; Mon, 3 Sep 2012 20:12:26 +0000 (UTC) Message-ID: <50450F2A.10708@FreeBSD.org> Date: Mon, 03 Sep 2012 13:12:26 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120728 Thunderbird/14.0 MIME-Version: 1.0 To: Arthur Mesh References: <201208221843.q7MIhLU4077951@svn.freebsd.org> <5043DBAF.40506@FreeBSD.org> <20120903171538.GM1464@x96.org> In-Reply-To: <20120903171538.GM1464@x96.org> X-Enigmail-Version: 1.4.3 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-security@FreeBSD.org, freebsd-rc@FreeBSD.org, Mark Murray , "David E. O'Brien" Subject: Re: svn commit: r239569 - head/etc/rc.d X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 20:13:28 -0000 On 09/03/2012 10:15, Arthur Mesh wrote: > Doug, > > On Sun, Sep 02, 2012 at 03:20:31PM -0700, Doug Barton wrote: >> In the third case, the system boots, but is then rebooted again before >> the cron interval has had a chance to replace even 1 file. This is the >> case where removing the old entropy is particularly pathological. It > > I believe you're missing the point that we don't just cleanup old > entropy file -- we re-generate it via "/etc/rc.d/random fastsaveseed" call in > postrandom_start() I didn't miss it. What postrandom does is delete all of the (by default) 8 files in /var/db/entropy that were the product of the previous boot's output. Then it re-generates /entropy, which was written out at the last shutdown, ideally after enough uptime for /dev/random to have been properly seeded, with a new file generated from a poorly seeded entropy pool as part of the boot process. IMO both of those are bad ideas, and lower both the quantity and quality of the entropy available at the next boot, should that happen prior to the (again, by default) 88 minutes it takes for the system to update /var/db/entropy. >>> +extra_commands="saveseed" >>> +saveseed_cmd="${name}_stop" >> >> I don't understand the need for this. > > That's how "/etc/rc.d/random fastsaveseed" translates in to "/etc/rc.d/random > stop", which does the jobs of re-generating seed file. Got that now, thanks. > In the end, assuming machine boots up passed postrandom script, we're left with > no stale seed files, but a freshly generated ${entropy_file_confirmed}, which > should be sufficient to seed next bootup. I understand how you're thinking about this, but unfortunately I'm quite certain your thinking is incorrect. As I pointed out in my last message, Yarrow is designed to cope with the possibility of replay attacks, and even with feeding in the same entropy files (after a short boot) the amount of new material we introduce at each boot fully alleviates this concern. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909)