From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ellen Papsch Subject: Re: Unencrypted boot with encrypted root Date: Wed, 08 Apr 2020 14:25:44 +0200 Message-ID: <6fc66a2a3f3cd71febb16bab2a0aeb65b6fdd147.camel@wine-logistix.de> References: <87ftdmi7pp.fsf@ambrevar.xyz> <17c316adc8485d1f09f70d291cfaad50258c6c1f.camel@wine-logistix.de> <20200403194423.m3pvz654qslug7g3@pelzflorian.localdomain> <20200404101832.cmegsybfyrseazjq@pelzflorian.localdomain> <4610a9147fa041ebb47f184a2d3f7878a8a2539c.camel@wine-logistix.de> <87d08jbpcc.fsf@gnu.org> <135d8491-53e8-46b6-b77a-fe6a4539b15d@www.fastmail.com> <878sj7i6p4.fsf@ponder> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:35709) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jM9mF-0004ir-9j for guix-devel@gnu.org; Wed, 08 Apr 2020 08:25:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jM9mD-00021G-1u for guix-devel@gnu.org; Wed, 08 Apr 2020 08:25:54 -0400 Received: from dedi718.your-server.de ([78.46.1.118]:39886) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1jM9mC-00020F-P0 for guix-devel@gnu.org; Wed, 08 Apr 2020 08:25:53 -0400 In-Reply-To: <878sj7i6p4.fsf@ponder> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane-mx.org@gnu.org Sender: "Guix-devel" To: Vagrant Cascadian , Alex Griffin , guix-devel@gnu.org Hi, Am Dienstag, den 07.04.2020, 09:47 -0700 schrieb Vagrant Cascadian: > On 2020-04-07, Alex Griffin wrote: > > So we can put the key in its own initrd (outside of the store) > > > > I believe it's also possible for grub to provide the key > derived/decrypted from the passphrase entered at run-time > These may be dangerous waters. The key file in initrd is like a house key under the mattress. A malicious process could look in the well defined place and exfiltrate the key. Think state trojan horses. A random name would not suffice, because other characteristics may help identifying the file (i.e. size). Regarding passing on the key, you mean the master key? I don't know if it's possible. If it's documented and recommended, I'd say go for it. But keep in mind this is crypto we are talking about. If it's something hacky we're straying from the path and may be inadvertently opening up security holes. A security guru analysis would help. I think* Guix would burden itself too much with secrets. It's something for the user and the installer should just make it more convenient, with a nudge to a more secure setup. The key file should be stored in a user specified location, preferably a pen drive (which is otherwise not used). It can be removed, so no read can occur by arbitrary processes. A passphrase should be added as backup. (*) as non-guru With or without key on a drive, passing on the master key would help avoiding waiting a second time for decryption. It would certainly be nice if it's feasible. Best regards