From owner-freebsd-rc@FreeBSD.ORG Fri Sep 7 00:18:43 2012 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id EE626106564A; Fri, 7 Sep 2012 00:18:43 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id B396014D9DB; Fri, 7 Sep 2012 00:18:43 +0000 (UTC) Message-ID: <50493D63.9070104@FreeBSD.org> Date: Thu, 06 Sep 2012 17:18:43 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: obrien@freebsd.org References: <50450F2A.10708@FreeBSD.org> <20120903203505.GN1464@x96.org> <50451D6E.30401@FreeBSD.org> <20120903214638.GO1464@x96.org> <50453686.9090100@FreeBSD.org> <20120904220754.GA3643@server.rulingia.com> <20120906174247.GB13179@dragon.NUXI.org> <20120906230157.5307a21f@gumby.homeunix.com> <20120906224703.GD89120@x96.org> <50493480.8060307@FreeBSD.org> <20120906234438.GA19715@dragon.NUXI.org> In-Reply-To: <20120906234438.GA19715@dragon.NUXI.org> X-Enigmail-Version: 1.4.3 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Arthur Mesh , freebsd-security@freebsd.org, RW , Peter Jeremy , freebsd-rc@freebsd.org 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: Fri, 07 Sep 2012 00:18:44 -0000 On 9/6/2012 4:44 PM, David O'Brien wrote: > On Thu, Sep 06, 2012 at 04:40:48PM -0700, Doug Barton wrote: >> Arthur, I've asked you repeatedly to demonstrate the truth of this >> claim. You and David are speaking completely theoretically about a >> possible attack vector. I (and others) have repeatedly provided hard >> facts that demonstrate that what you're concerned about cannot happen, >> and yet you repeatedly claim it can. > > "PROVIDED HARD FACTS"? Doug please state them again as I seem to not be > seeing them. Yes, that's part of the problem. :) Thinking about it more, I think that you and Arthur are conflating 2 related-but-different concepts that may explain the confusion. I alluded to this in one of my previous messages, but I think it's important to make it more clear. (It's also worth noting that I'm also guilty of conflating these 2 issues in some of my responses, mea culpa.) The first thing that we want to be sure of at boot time is that we stuff a sufficient quantity of material into the pool so that the device can start providing high-quality random bits as early after boot as possible. The other thing we need to do is to be sure that we don't create a situation that will allow an attacker to determine the interior state of the device, and therefore be able to predict what "random" bits are going to be spit out by it. The latter issue _is_ important, and we did take it into account in both the kernel code and the surrounding infrastructure. But other than for super high-security systems that rely heavily on what comes out of /dev/random it's not a threat model that we spend a lot of time on because nowadays anyone in that kind of situation uses a dedicated hardware device to provide their random bits. So our primary concern is that we stuff enough things into the device early so that it will start spitting out "good" "random" bits ASAP. By default, all of the hardware harvesting is on when the device is first loaded by the kernel. So long before we even get to the rc.d parts of the system the internal state of the PRNG is *already* unpredictable (where the definition of "unpredictable" is conditioned by the threat model described above). When we reach the initrandom point in the process, we add a little more entropy with the "better than nothing" commands, and the contents of /entropy. At that point we have already reduced the possibility of an attacker being able to guess the internal state of the device to a statistically insignificant number for any practical threat model that a FreeBSD system is likely to face. Anyone who still doesn't feel that's enough would want a hardware device anyway. So the only remaining problem is to continue to stuff the highest quality entropy we can into the pool to improve the device's ability to spit out high-quality pseudo-random bits. I do think that you and Arthur have raised an interesting issue by pointing out that the way we have been using the stuff in /var/db/entropy could be improved. I think that my suggestion of "randomizing" the order in which we start using those files addresses both making it harder for an attacker to guess the internal state, and my concern about not discarding useful material in the event of a fast reboot. I also think that my suggestion of adding a new entropy file to /var/db/entropy at boot time (instead of replacing /entropy) helps address the concern you and Arthur raised about making it harder for an attacker to guess the internal state. In other words, I have listened to what you both have said, and tried to make suggestions that address your concerns without completely gutting the existing system. >> It is way past time that you either demonstrate that your claim has >> merit, or stop making it. > > Ditto. David, you and Arthur are the ones making claims that radical changes are necessary to a system that has stood the tests of time for 12 years. You need to prove the claims you're making about the deficiency of the system prior to your changes. 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)