Message-ID: <20150418170219.GA25265@thunk.org>
Date:	Sat, 18 Apr 2015 13:02:19 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Sandy Harris <sandyinchina@...il.com>
Cc:	LKML <linux-kernel@...r.kernel.org>, greg@...ah.com,
	John Denker <jsd@...n.com>
Subject: Re: Read/write file from random(4) driver

On Sat, Apr 18, 2015 at 11:28:16AM -0400, Sandy Harris wrote:
> What I'd like to add is a small (128 to 512 bits) file that the driver
> tries to read during initialisation and writes periodically later.
> This would not completely solve the problem but by moving the
> read/write into the kernel it avoids the risk that vendors bungling
> the scripts will break the driver.

Where would this file live?  The place where this is an issue is with
embedded devices, which is where we're most likely to see incompetent
product engineers who don't deal with initializing entropy pool.  The
problem is that on those embedded platforms, it's much more likely
that the file system layout is going to be non-stadard, or where the
root file system is mounted read-only.

Worse, if the kernel tries to do this in an uncoordinated way, it
could end up writing the file while the root file system is part of
the initial ram disk, so the state won't get saved.  (Or part of an
overlayfs composed of a tmpfs on top of a read-only file system, etc.)

> This looks secure in all cases except first boot or an enemy who gets
> root and reads the putatively secret data. Use a variant of Denker's
> proposal to create a unique initial version of the file for each
> install and it handles first boot as well.

... except the first boot problem is actually the harder problem, and
generally, the more critical one, since so many userspace applications
generate permanent long-term public keys within hudreds of
milliseconds of the first boot.  In addition, Denker's proposal
assumes a competently implemented userspace --- while your proposal
assumes incompetent product engineers.

I don't believe we can solve the problem in the kernel, because as the
saying goes, "fools are so ingenious".  We can't make random pool
initialization foolproof.  On laptops and desktops, this problem is
already effectively solved, since in practice, the entropy pool is
initialized before the root file system is remounted read/write,
at least if you use sysvinit.  Unfortunately, this is not always
true if you use systemd, because it's __too__ fast --- and because
systemd reads from /dev/urandom very early in the boot cycle, well
before the root file system is mounted and before the entropy pool has
a chance to be initialized.  Grep for "random" the following line in
dmesg shortly after the system is booted, and weep:

Apr 16 13:24:01 closure kernel: [    1.135749] random: systemd-udevd urandom read with 19 bits of entropy available
Apr 16 13:24:01 closure kernel: [    3.329190] random: nonblocking pool is initialized

Fortunately, I don't *think* systemd is doing anything
cryptographically sensitive yet, but that's only because it hasn't
subsumed openssh yet.  :-)    And hopefully, with the exception of
openssh generating host ssh keys the first time the system is booted,
in most cases by the time most user-initiated security sensitive
applications are started, the entropy pool will be initialized.

Getting back to the point, I firmly believe the right answer is to try
to fix systemd, Intel's Yacto distribution, etc, to do the right
thing.  Keep in mind that even if we fix in the kernel right now,
thanks to out-of-tree device driver, I am aware of brand-new products
that are just getting started in the design phase a few months ago,
which are using a 3.2 kernel.  (This is an improvement, BTW, the
previous version of that particuarly product was using 2.6.32.  The
engineers wanted to use a newer kernel, but they were constrained by
device driver availability.)  So if we can fix userspace, it's more
likely that these crappy embedded products will more likely be secure.

(Assuming you can get the embedded developers to use the latest
version of the userspace distributions / frameworks, granted, which is
not at all guaranteed, but they are more likely to use newer userspace
than they are the latest kernels, due to the device driver issue.)

Regards,

					- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists