Date: Thu, 06 Sep 2012 17:18:43 -0700 From: Doug Barton <dougb@FreeBSD.org> To: obrien@freebsd.org Cc: Arthur Mesh <arthurmesh@gmail.com>, freebsd-security@freebsd.org, RW <rwmaillists@googlemail.com>, freebsd-rc@freebsd.org Subject: Re: svn commit: r239569 - head/etc/rc.d Message-ID: <50493D63.9070104@FreeBSD.org> In-Reply-To: <20120906234438.GA19715@dragon.NUXI.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>
next in thread | previous in thread | raw e-mail | index | archive | help
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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50493D63.9070104>