From owner-freebsd-rc@FreeBSD.ORG Thu Sep 6 20:03:26 2012 Return-Path: Delivered-To: freebsd-rc@FreeBSD.org Received: by hub.freebsd.org (Postfix, from userid 664) id EBCBE1065679; Thu, 6 Sep 2012 20:03:26 +0000 (UTC) Date: Thu, 6 Sep 2012 13:03:25 -0700 From: David O'Brien To: Dag-Erling =?unknown-8bit?B?U23DuHJncmF2?= Message-ID: <20120906200325.GA17159@dragon.NUXI.org> References: <201208222337.q7MNbORo017642@svn.freebsd.org> <5043E449.8050005@FreeBSD.org> <20120904220126.GA85339@dragon.NUXI.org> <50468326.8070009@FreeBSD.org> <20120906164514.GA14757@dragon.NUXI.org> <867gs7qcsl.fsf@ds4.des.no> <20120906184400.GF13179@dragon.NUXI.org> <86lignot6a.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <86lignot6a.fsf@ds4.des.no> X-Operating-System: FreeBSD 10.0-CURRENT X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Arthur Mesh , freebsd-security@FreeBSD.org, Doug Barton , freebsd-rc@FreeBSD.org, Mark Murray Subject: Re: svn commit: r239598 - head/etc/rc.d X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@freebsd.org List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 20:03:27 -0000 On Thu, Sep 06, 2012 at 09:19:41PM +0200, Dag-Erling Smrgrav wrote: > David O'Brien writes: > > Dag-Erling Smørgrav writes: > > > However, it does not vary from one boot to another, or even from one > > > machine to another if they run the same FreeBSD version with the same > > > device.hints and loader.conf on the same hardware configuration. > > ... and same BIOS version. > > > > I found on some Dell desktops and HP servers I looked at that the > > 'hint.acpi.0' MIB could vary depending on BIOS version, and 'smbios' > > MIB did vary between systems. > > kenv(1) on the machine I'm typing this on produces 2128 bytes, less than > 1% of which will vary between machines with the same motherboard. DES, I am not sure what you are arguing. Are you asking for 'kenv' to be removed from better_than_nothing() ? Or are you just making sure folks are aware it is not a source of strong entropy? Currently 'kenv' does not have a way to display a specific MIB so its hard to reduce the output to just that which may vary. 'date' has 28 characters of output, well formed in such a way to reduce the search space. The variance alone in 'kenv' output on the tier-1 vendor machines I inspected had much more than that (> 100 characters). We could reduce the boiler plate by: kenv | sed 's/.*"\(.*\)"/\1/' which reduced 2786 bytes of output to 660 on an HP test machine. > The UUID is all-zeroes except for the lower 48 bits, which are > identical to the on-board NIC's MAC address. I'm seeing smbios.system.uuid="6c7e35be-5599-db11-ae96-39bc833c4d3c" -and- smbios.system.uuid="44454c4c-5200-1053-804a-b7c04f594631" I already acknowledged that smbios output can be crappy on some systems. The MAC is not in the 'kenv' output, so I'm not sure how that statement applies. > The BIOS version consists of two > characters ("F8") and a release date ("01/08/2007"). > If the attacker > knows what motherboard I have, he can easily figure out the handful of > possible BIOS revisions and release dates, and the first 24 bits of the > MAC address (00:16:e6). I already said an attacker could have a local login on the system. That would give them full knowledge of the kenv output. Same attacker can figure out the 'date' output from uptime, etc... > > I'm not saying 'kenv' is perfect, but it was something I found in > > /[s]bin that varied between systems so it was a good replacement for > > one of the 'pas' runs. > > ...except ps(1) varies between reboots and over time, especially if you > include fields like majflt, minflt, nivcsw and nvcsw, and to a lesser > extent systime and usertime (it would help if they had greater > resolution); whereas kenv(1) does not and can be identical or nearly so > on multiple machines. Does 'ps' vary that much across the two invocations that we had in 'initrandom'? Please post a diff to back up any "yes" answer. We already have an invocation of 'ps'. Please suggest a *different* command invocation. -- -- David (obrien@FreeBSD.org)