Date: Mon, 03 Sep 2012 13:12:26 -0700 From: Doug Barton <dougb@FreeBSD.org> To: Arthur Mesh <arthurmesh@gmail.com> Cc: freebsd-security@FreeBSD.org, freebsd-rc@FreeBSD.org, Mark Murray <markm@FreeBSD.org>, "David E. O'Brien" <obrien@FreeBSD.org> Subject: Re: svn commit: r239569 - head/etc/rc.d Message-ID: <50450F2A.10708@FreeBSD.org> In-Reply-To: <20120903171538.GM1464@x96.org> References: <201208221843.q7MIhLU4077951@svn.freebsd.org> <5043DBAF.40506@FreeBSD.org> <20120903171538.GM1464@x96.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50450F2A.10708>