I realise that in general reading files from kernel space is a bad
idea, and understand at least some of the reasons. I have read Greg
K-H's article on the topic (http://www.linuxjournal.com/article/8110)
and some other discussion. However, I think I see a specific exception
and am looking for opinions here before I create a patch that may be
rejected out-of-hand.
The random device really needs secure initialisation and a number of
mechanisms have been proposed or are in use for that.
The default is a saved entropy file read & written by shellscripts
called by init. Details are in the comments in the random driver. This
works well in many cases but not on first boot or on a device such as
a router with little writable storage. Or if a router vendor or distro
builder omits the scripts. There have been well-publicised failures in
the field based on such problems; we clearly need something better.
John Denker suggests that every install needs a unique key provisioned; see
http://www.av8n.com/computer/htm/secure-random.htm#sec-boot-image
This would indeed solve the problem if implemented correctly, but it
complicates install scripts some and getting this right relies on the
same people who conspicuously got the existing mechanism wrong.
It is straightforward to initialise arrays in the driver at compile
time from /dev/urandom on the development machine. I have an
implementation of this idea and another is at https://grsecurity.net/
This is almost useless for a kernel that is compiled once then used in
many installs, but quite effective for machines that just compile
their own kernels.
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.
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.
Comment? Criticism?
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
On Sat, Apr 18, 2015 at 01:02:19PM -0400, Theodore Ts'o wrote:
> (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.)
What "device driver issue" is keeping anyone on such old and obsolete
kernel versions? BSPs that never submitted their code upstream? Or
something else that is broken and no one has told us about?
thanks,
greg k-h