From owner-freebsd-current@FreeBSD.ORG Wed Dec 25 00:04:54 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 747A6B7D; Wed, 25 Dec 2013 00:04:54 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 53E971C9C; Wed, 25 Dec 2013 00:04:54 +0000 (UTC) Received: from zeta.ixsystems.com (unknown [69.198.165.132]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id B340926F99; Tue, 24 Dec 2013 16:04:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1387929893; bh=eeS15T/iqC+rl8QEVvnpaFWBhjRYZIm92WjrlX2S//4=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=DNcJ0AZDGWMqncuNOXgrqPW312FasZm06BoRDxOrxGc+CjTYCU9Okhqnk1clLYsE6 mlg3qpnwOOzAPJ2YtOxFA9bqOAoDU4aerbNDpvb0vBlkURglpnFj85UVORpx4Ibc1a 2TerPpNl5JLoAGybjo0reQVvQKSEnalJAy46C5T0= Message-ID: <52BA2125.8050404@delphij.net> Date: Tue, 24 Dec 2013 16:04:53 -0800 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: Paul Hoffman , d@delphij.net Subject: Re: [PATCH RFC] Disable save-entropy in jails References: <52B9F232.1090002@delphij.net> <278988C7-1749-413D-A5E2-ABE6753B3766@proper.com> <52BA1065.6000403@delphij.net> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-security@freebsd.org" , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Dec 2013 00:04:54 -0000 -----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 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 >>> 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 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-----