svn commit: r239598 - head/etc/rc.d

[David O'Brien]

On Thu, Sep 06, 2012 at 09:19:41PM +0200, Dag-Erling Smrgrav wrote:
> David O'Brien <obrien at FreeBSD.org> writes:
> > Dag-Erling Smørgrav <des at des.no> 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 at FreeBSD.org)