Hash: SHA512

On 12/24/13 15:26, Paul Hoffman wrote:
> On Dec 24, 2013, at 2:53 PM, Xin Li <delp...@delphij.net> wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
>> On 12/24/13 14:36, Paul Hoffman wrote:
>>> On Dec 24, 2013, at 12:44 PM, Xin Li <delp...@delphij.net>
>>> wrote:
>>>> I think we shouldn't save entropy inside jails, as the data
>>>> is not going to be used by rc script (pjd@126744).  If there
>>>> is no objections, I will commit this changeset on January 1,
>>>> 2014.
>>> Even if it is not used by an rc script, it might be used by
>>> some userland program (running as root, of course) that knows
>>> about the directory and wants some fresh entropy for its own
>>> use.
>> Why a userland application would want to use these?  Would you
>> mind elaborating what kind of use that would be?
> I don't have a specific application in mind, and certainly not one
> for a jail. However, I'm not sure what the value in removing a
> feature for a jail if we don't know if anyone is using that
> feature. Thus, my question.

I see.

>> My understanding is that the saved entropy is used for
>> bootstraping the system only: any applications that wants good
>> random numbers should just use /dev/random because relying on
>> something saved on disk is the worst way for someone who wants
>> more entropy.
> Quite true. Note, however, that we don't delete the saved entropy
> after booting and add it just before shutdown: we leave it there
> for some reason. I'm not sure why a jail is so different of an
> environment that it should be treated differently than a normal
> (non-jail) environment. Maybe there is a reason, but I'm not seeing
> it.

Definitely not for seeding some userland applications :)  If the
application wants secure random numbers, it should rely on /dev/random
because it has more entropy sources and is less predicable.

>>> Is there a problem with saving the directory in jails? It 
>>> certainly isn't taking up much space.
>> No, it's not about space.  What I am concerned is that it may
>> have wasted entropy: each time (every */11 minute) the system
>> would get 2048 bytes out from /dev/random per jail.  This
>> deterministic behavior may trigger reseeds earlier than wanted.
> I did not understand this. What changes in the system does removing
> /var/db/entropy cause? (If this is answered in a longer article, a
> pointer to it would be useful to me (and maybe others).)

No, we are not talking about removing /var/db/entropy.  What I am
proposing to do is to disable entropy savings from jails.  Here is why:

The way a PRNG works is that it uses one or many entropy sources to
"feed" its internal state, and generate a series of pseudo-random
numbers from the internal state via a PRF.

FreeBSD collects entropy from several sources: Ethernet, interrupts,
software interrupts, etc., as well as hardware RNG that is available
to the system, and use all these entropy to derive the internal state
of its PRNG.

When reading from /dev/random, one essentially consumes entropy that
is fed into the random device, and eventually it would cause a reseed.
 In an ideal world, we would want this to be less predicable and
controllable from a potential attacker.

Normal applications tends to read /dev/random in small bites, and do
so in a discrete and nearly random manner, assuming we have a lot of
processes running.  Saving entropy, on the other hand, happen in
larger chunks at a determined time.  With multiple jails running, one
would have a lot of big chunk reads from the /dev/random device,
making its behavior more deterministic, which could have bad consequences.

- -- 
Xin LI <delp...@delphij.net>    https://www.delphij.net/
FreeBSD - The Power to Serve!           Live free or die

freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to