lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170817033148.ownsmbdzk2vhupme@thunk.org>
Date:   Wed, 16 Aug 2017 23:31:48 -0400
From:   Theodore Ts'o <tytso@....edu>
To:     Laura Abbott <labbott@...hat.com>
Cc:     Kees Cook <keescook@...omium.org>,
        Daniel Micay <danielmicay@...il.com>,
        kernel-hardening@...ts.openwall.com, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org, Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCHv3 2/2] extract early boot entropy from the passed cmdline

On Wed, Aug 16, 2017 at 04:14:58PM -0700, Laura Abbott wrote:
> From: Daniel Micay <danielmicay@...il.com>
> 
> Existing Android bootloaders usually pass data useful as early entropy
> on the kernel command-line. It may also be the case on other embedded
> systems.....

May I suggest a slight adjustment to the beginning commit description?

   Feed the boot command-line as to the /dev/random entropy pool

   Existing Android bootloaders usually pass data which may not be
   known by an external attacker on the kernel command-line.  It may
   also be the case on other embedded systems.  Sample command-line
   from a Google Pixel running CopperheadOS....

The idea here is to if anything, err on the side of under-promising
the amount of security we can guarantee that this technique will
provide.  For example, how hard is it really for an attacker who has
an APK installed locally to get the device serial number?  Or the OS
version?  And how much variability is there in the bootloader stages
in milliseconds?

I think we should definitely do this.  So this is more of a request to
be very careful what we promise in the commit description, not an
objection to the change itself.

Cheers,

					- Ted

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ