Date: Wed, 25 Dec 2013 14:37:17 +0200 From: Mark R V Murray <mark@grondar.org> To: d@delphij.net Cc: "freebsd-security@freebsd.org" <freebsd-security@freebsd.org>, Paul Hoffman <phoffman@proper.com>, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: [PATCH RFC] Disable save-entropy in jails Message-ID: <22790868-E1B1-4130-83DB-E5CD86DD40A4@grondar.org> In-Reply-To: <52BA2125.8050404@delphij.net> References: <52B9F232.1090002@delphij.net> <278988C7-1749-413D-A5E2-ABE6753B3766@proper.com> <52BA1065.6000403@delphij.net> <A84590F3-3B6D-4D6F-AF4C-F261C82B88AF@proper.com> <52BA2125.8050404@delphij.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_17113B37-5154-4D04-A822-FC5C92A4DA40 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 25 Dec 2013, at 02:04, Xin Li <delphij@delphij.net> wrote: > 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: >=20 > 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. >=20 > 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. >=20 > 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. So far so good. :-) > 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. I doubt it goes as far as =93bad=94, but it certainly does no good. I would support the notion of not caching entropy in jails IFF this didn=92t leak out and prevent harvesting in the jail=92s host AND this gave a noticeable simplification of script code. M --=20 Mark R V Murray --Apple-Mail=_17113B37-5154-4D04-A822-FC5C92A4DA40 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iQCVAwUBUrrRgd58vKOKE6LNAQqTmAP+PFDENFpW/rAJu2PFJBlYv+fexNFTiVG0 6IbkeollEsAOZc5mFI0ehdGzcohgw986usl7zxWSc0PntiIQNR2Z7VMEM3f9tZJy +bvxG3M2VlgMEmVwZqouuoZlz56f4CBQoi6x6FlNGDQWpErxDfvdj+ZiudpkKf3n 2NZW6fyD/PY= =OelK -----END PGP SIGNATURE----- --Apple-Mail=_17113B37-5154-4D04-A822-FC5C92A4DA40--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?22790868-E1B1-4130-83DB-E5CD86DD40A4>