linux-kernel - Read/write file from random(4) driver

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACXcFm=nnojHPRrE8m3GGAsj2GTN6O0saz9q2iAa10TCVW8_Vw@mail.gmail.com>
Date:	Sat, 18 Apr 2015 11:28:16 -0400
From:	Sandy Harris <sandyinchina@...il.com>
To:	LKML <linux-kernel@...r.kernel.org>,
	"Theodore Ts'o" <tytso@....edu>, greg@...ah.com,
	John Denker <jsd@...n.com>
Subject: Read/write file from random(4) driver

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?
--
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/