Re: [PATCH RFC] Disable save-entropy in jails

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 12/24/13 15:26, Paul Hoffman wrote:
> On Dec 24, 2013, at 2:53 PM, Xin Li <delphij_at_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 <delphij_at_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_at_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.

Cheers,
- -- 
Xin LI <delphij_at_delphij.net>    https://www.delphij.net/
FreeBSD - The Power to Serve!           Live free or die
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJSuiElAAoJEJW2GBstM+nsW8wP/iJOuLK7gl4xcaZ0WQM9ZbcF
dRo9Wuao4aytIPNcI7BcRvFPkQIVd/N6tIwmi98Uy3vLG1FAkZlSkPT9IXGWKwtX
lil1tfPlGt4+lMPirD7AFkk99DUfMO7nY2TuWw6DG6w6gfbzoBkZfxEZTTBv5XXl
ZtNMsw2CR6xOOY2YTx3HobSnnr4UzwBzT1nif+7W/pYTwQB2LNbnwnVqoDsGn9mv
MMO/9WnYs3/smYDQdChmmybGws4/P53sGjIzds/dv3Gg8ce8fu/ZAPFGCKRzr+uL
CTBCBuaeiRM/BhlG3n6H0o4updgDAOQ0PDH0q6rMXwcg7ODz6tW2x7lJ5hwm/Z2B
nrPCr5p2jk5KE8ULjINypYyIgjbPcgDTZN2ToB+a83RvIf9/DlRMzyOA76b0KsEs
AnygLyG/ZoBqy5s4nrNbLyNERx2T7hrcrGtK4qtMIdpYQK8T/etZZvIebLVPvCGK
kGG9AEgiUYHgG0RASg0LtsiJLi0/LjGzwZl+/Q3lqjrcmV7m6jOLAMT349aWOep9
GXPOcBXxh4emEz2qAQRSn7Y+Xn0T80lIPHb/6Wz04pOIhlMwQPR97X+IfAtybHFf
7HVk4GfhQC/zDiwPKb5Qcx7JRnE3wBZ2vnVaVzPCk9uPImyvMYKDKiNfFl2zlFfS
AdjiKPaOGw2kAZA55dC3
=7Ruf
-----END PGP SIGNATURE-----