Date: Mon, 03 Sep 2012 14:13:18 -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: <50451D6E.30401@FreeBSD.org> In-Reply-To: <20120903203505.GN1464@x96.org> References: <201208221843.q7MIhLU4077951@svn.freebsd.org> <5043DBAF.40506@FreeBSD.org> <20120903171538.GM1464@x96.org> <50450F2A.10708@FreeBSD.org> <20120903203505.GN1464@x96.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 09/03/2012 13:35, Arthur Mesh wrote:
> On Mon, Sep 03, 2012 at 01:12:26PM -0700, Doug Barton wrote:
>> 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.
>
> 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.
It is certainly not likely to be well seeded at that point, especially
on low end systems.
> On next reboot /entropy will get re-written anyway.
... which illustrates my point that at best the change is superfluous.
>> 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.
>
> I believe this is better than what we have today, since it prevents a
> case where system crashes before cronjob (that writes to
> saved-entropy.X) gets to run at all. This patch reduces this window to
> matter of a second or so.
You're still assuming that feeding the same entropy files in on
successive boots is a problem, which hasn't been proven yet.
> If you think quantity is very important here, (which I don't believe is
> true) I am fine with not deleting /var/db/entropy/* on boot (It doesn't
> make things better or worse).
>
>>> 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.
>
> You could be correct about Yarrow, but the Bruce Schneier explicitly
> recommends to recycle already used seed with a new one. Reference is
> provided in the code.
Right, which is why we rotate the files in /var/db/entropy, and write
out a new /entropy file as part of the shutdown process. I'm not
disagreeing with your premise that new/different entropy files _should_
be used. I'm disagreeing with your premise that deleting/replacing the
old ones at boot time is an improvement.
> Also, our findings have shown that on some very low end systems, these
> seed files are pretty much the only source of entropy early during boot.
Hopefully you saw Ian's report along that line. I'm sensitive to the
idea of certain low end systems not providing a whole lot of entropy
from the commands that are fed in as part of the "better than nothing"
process. But it's also useful to note that rc.d/initrandom starts the
hardware entropy harvesting process as well, so even though we're not
getting a lot of entropy from the "better than nothing" commands we're
still stirring the pool with new material early in the boot process.
But the fact that on these low end/embedded systems there is very little
entropy available at boot time actually makes it more important that we
don't delete what little we have.
> Moreover, we also uncovered other problems with the way things are
> consumed by Yarrow via /dev/random.
> We will provide more details on our findings a bit later.
Please do ... probably security@ is the right forum for that. Sooner
than later if you think that it affects the rc.d related discussion.
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?50451D6E.30401>