Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753857AbbDRP2S (ORCPT ); Sat, 18 Apr 2015 11:28:18 -0400 Received: from mail-ig0-f176.google.com ([209.85.213.176]:37820 "EHLO mail-ig0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753397AbbDRP2Q (ORCPT ); Sat, 18 Apr 2015 11:28:16 -0400 MIME-Version: 1.0 Date: Sat, 18 Apr 2015 11:28:16 -0400 Message-ID: Subject: Read/write file from random(4) driver From: Sandy Harris To: LKML , "Theodore Ts'o" , greg@kroah.com, John Denker Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2431 Lines: 47 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/