From owner-freebsd-security@FreeBSD.ORG Fri Sep 14 21:55:22 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F545106566B for ; Fri, 14 Sep 2012 21:55:22 +0000 (UTC) (envelope-from markm@FreeBSD.org) Received: from gromit.grondar.org (grandfather.grondar.org [93.89.92.32]) by mx1.freebsd.org (Postfix) with ESMTP id 43CCE8FC18 for ; Fri, 14 Sep 2012 21:55:22 +0000 (UTC) Received: from uucp by gromit.grondar.org with local-rmail (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TCdm3-0005AQ-0X for freebsd-security@freebsd.org; Fri, 14 Sep 2012 22:50:07 +0100 Received: from localhost ([127.0.0.1] helo=groundzero.grondar.org) by groundzero.grondar.org with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TCdlD-000C1N-4g; Fri, 14 Sep 2012 22:49:15 +0100 To: Ben Laurie In-reply-to: References: <50453686.9090100@FreeBSD.org> <20120911082309.GD72584@dragon.NUXI.org> <504F0687.7020309@FreeBSD.org> <201209121628.18088.jhb@freebsd.org> <5050F477.8060409@FreeBSD.org> <20120912213141.GI14077@x96.org> <20120913052431.GA15052@dragon.NUXI.org> From: Mark Murray From: Mark Murray Date: Fri, 14 Sep 2012 22:49:14 +0100 Message-Id: Cc: Arthur Mesh , Ian Lepore , Doug Barton , freebsd-security@freebsd.org, RW , "Bjoern A. Zeeb" Subject: Re: svn commit: r239569 - head/etc/rc.d X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 21:55:22 -0000 Ben Laurie writes: > > My proposed solution is intended so address, if not solve that > > problem, by preventing file writes from filling up the harvest > > queue. Yarrow already has pretty good data hashing; there is no > > point in duplicating that. > > Fine: then when the queue fills, run the Yarrow algorithm. I can certainly trigger a reseed at will, but allowing external writes to overwhelm the system by doing a $ cat /dev/zero > /dev/random ... just ain't gonna happen. No, sir. > If not, then whatever you run instead must also be sound. XOR isn't. You have a way to go before you convince me on this one. I'll buy this argument if it is a routine/regular/risky ocurrence that the output of (say) $ ( ps -gauxwww ; netstat -arn ; sysctl -ao ) | gzip | ... ... can be demonstrated to have insignificant entropy when harvested using my proposed method. BTW - you may want to actually see the method. > > Note that I have already agreed that external preconditioning of > > the data is a good idea; I like the idea of compression and some > > external hashing (but not the speed of these duting boot). > > I don't, because you can't rely on it. That is, I'm not against it, > but we can't rely on it. You have to rely on something; Yarrow needs some entropy to cold-start, and on a freshly installed OS, this is rocking-horse shit. This is where BIG problems start because it is at this time that (eg) SSH keys are built. We make some effort to get the user to "kayboard bash", but experience has shown that annoyed users screw up, and annoyed engineers are often worse. On a properly shut-down box this is better-controlled as entropy can be cached for restart. What we have works; but for reasons discussed is imperfect. Proposed fixes make it better. Perfection will always be asyptotically unattainable. M -- Mark R V Murray Pi: 132511160