From owner-freebsd-current@FreeBSD.ORG Tue Nov 15 00:44:46 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 85FCB106564A; Tue, 15 Nov 2011 00:44:46 +0000 (UTC) (envelope-from ache@vniz.net) Received: from vniz.net (vniz.net [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id F131F8FC13; Tue, 15 Nov 2011 00:44:45 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by vniz.net (8.14.5/8.14.5) with ESMTP id pAF0iikT058594; Tue, 15 Nov 2011 04:44:44 +0400 (MSK) (envelope-from ache@vniz.net) Received: (from ache@localhost) by localhost (8.14.5/8.14.5/Submit) id pAF0ihvQ058593; Tue, 15 Nov 2011 04:44:44 +0400 (MSK) (envelope-from ache) Date: Tue, 15 Nov 2011 04:44:43 +0400 From: Andrey Chernov To: das@freebsd.org, current@freebsd.org, secteam@freebsd.org Message-ID: <20111115004443.GA50429@vniz.net> Mail-Followup-To: Andrey Chernov , das@freebsd.org, current@freebsd.org, secteam@freebsd.org References: <20080916140319.GA34447@nagual.pp.ru> <20080916201932.GA59781@zim.MIT.EDU> <20111112102241.GA75396@vniz.net> <20111112154135.GA21512@zim.MIT.EDU> <20111112171531.GA83419@vniz.net> <20111114013004.GA53392@zim.MIT.EDU> <20111114192721.GA16834@vniz.net> <20111114205855.GB58790@zim.MIT.EDU> <20111114212926.GA28783@vniz.net> <20111114230855.GA59545@zim.MIT.EDU> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111114230855.GA59545@zim.MIT.EDU> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: Re: Is fork() hook ever possible? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 00:44:46 -0000 On Mon, Nov 14, 2011 at 06:08:55PM -0500, David Schultz wrote: > Not quite. OpenBSD's implementation is more careful. I just > noticed a funny thing about FreeBSD's KERN_ARND sysctl: If the > random device isn't (or can't be) loaded, KERN_ARND silently > decides to initialize itself with the output of random(). This > means that whatever minuscule amount of entropy it might have > picked up from the clock is reduced to a maximum of 31 bits. > That's a fantastic way to provide a false sense of security... I agree. Lets separate two things: "no /dev/random for jails" and "no random kernel module is loaded". IMHO kernel module should _not_ be optional anymore, it solves problem you describe and all similar problems at once. Adding KERN_ARND to arc4random() at this moment solves "no /dev/random for jails" problem alone and _not_ pretends to solve "no random kernel module is loaded" problem. When random kernel module will become non-optional, KERN_ARND automagically makes good security in that place too. P.S. Do I answer your doubts about &rdat key initialization in my prev. posting? -- http://ache.vniz.net/