-----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 <[email protected]> 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 <[email protected]> >>> 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. Cheers, - -- Xin LI <[email protected]> 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----- _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "[email protected]"