Date: Sun, 02 Sep 2012 15:20:31 -0700 From: Doug Barton <dougb@FreeBSD.org> To: "David E. O'Brien" <obrien@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: <5043DBAF.40506@FreeBSD.org> In-Reply-To: <201208221843.q7MIhLU4077951@svn.freebsd.org> References: <201208221843.q7MIhLU4077951@svn.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 08/22/2012 11:43, David E. O'Brien wrote: > Author: obrien > Date: Wed Aug 22 18:43:21 2012 > New Revision: 239569 > URL: http://svn.freebsd.org/changeset/base/239569 > > Log: > Remove old entropy seeding after consumption initializing /dev/random PRNG. > Not doing so opens us up to replay attacks. I object to this change, and would like to see it discussed more. When I did the original implementation of the entropy seeding scripts this issue was discussed, and the decision not to remove the entropy after seeding was deliberate. There are 3 possibilities. First, the system boots normally, gets seeded, and runs for a period of time longer than ($entropy_save_num x cron interval), which by default is 88 minutes. In this case all of the entropy files will be replaced, so the "postrandom" change will be spurious. In the second case, the system boots successfully, gets seeded, but runs for less than the default 88 minutes. In that case there will be at least (uptime / cron interval) new files, and the same number of old files removed. So while some of the entropy will be "stale" at next reboot, it won't all be the same, so even the stale entropy is better than nothing in helping to reseed. 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 reduces the available seeding material without adding anything new. From a security perspective, that's worse than the possibility of a replay attack. For all 3 cases, it's important to keep in mind a few things. Primarily, yarrow is designed to avoid exactly the kind of "replay" problem that this change was intended to fix, so it's almost certainly at best unnecessary. Of nearly equal importance it should be kept in mind that we add a non-zero amount of unique material at every boot, so a true replay attack isn't possible, even without this change. In short, this change is at best unnecessary, and possibly detrimental. I'd like to see the postrandom script backed out, but I'll leave it open for others to comment. On a less serious note: > Modified: head/etc/rc.d/random > ============================================================================== > --- head/etc/rc.d/random Wed Aug 22 18:35:17 2012 (r239568) > +++ head/etc/rc.d/random Wed Aug 22 18:43:21 2012 (r239569) > @@ -4,7 +4,7 @@ > # > > # PROVIDE: random > -# REQUIRE: var initrandom > +# REQUIRE: initrandom var This change is spurious, rcorder(8) doesn't care what order they come in. > # BEFORE: netif > # KEYWORD: nojail shutdown > > @@ -14,6 +14,9 @@ name="random" > start_cmd="random_start" > stop_cmd="random_stop" > > +extra_commands="saveseed" > +saveseed_cmd="${name}_stop" I don't understand the need for this. 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?5043DBAF.40506>