-----BEGIN PGP SIGNED MESSAGE-----
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>
>>>> 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,
>>> 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
>> 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.
>> 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
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
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"