From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ellen Papsch Subject: Re: Unencrypted boot with encrypted root Date: Fri, 03 Apr 2020 17:44:13 +0200 Message-ID: <17c316adc8485d1f09f70d291cfaad50258c6c1f.camel@wine-logistix.de> References: <87ftdmi7pp.fsf@ambrevar.xyz> 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]:57917) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jKOUb-00085v-VH for guix-devel@gnu.org; Fri, 03 Apr 2020 11:44:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jKOUX-0001Ht-Nf for guix-devel@gnu.org; Fri, 03 Apr 2020 11:44:24 -0400 Received: from dedi718.your-server.de ([78.46.1.118]:44248) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1jKOUV-0001CS-Sx for guix-devel@gnu.org; Fri, 03 Apr 2020 11:44:20 -0400 In-Reply-To: <87ftdmi7pp.fsf@ambrevar.xyz> 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: Pierre Neidhardt , guix-devel@gnu.org Hi, Am Donnerstag, den 02.04.2020, 10:59 +0200 schrieb Pierre Neidhardt: > Hi! > > I've followed the doc / template to set up an encrypted system on my > laptop: > > --8<---------------cut here---------------start------------->8--- > (mapped-devices > (list (mapped-device > (source (uuid "12345678-1234-1234-1234-123456789abc")) > (target "my-root") > (type luks-device-mapping)))) > > (file-systems (append > (list (file-system > (device (file-system-label "my-root")) > (mount-point "/") > (type "ext4") > (dependencies mapped-devices)) > (file-system > (device (uuid "1234-ABCD" 'fat)) > (mount-point "/boot/efi") > (type "vfat"))) > %base-file-systems)) > --8<---------------cut here---------------end--------------->8--- > > Problem is, I get prompted for the LUKS password twice: once before > GRUB > starts and once when booting an OS entry. > > This is rather annoying (and quite slow by the way, it takes some 10- > 20 > seconds) and probably not too useful. > > Is it possible to prompt for the password only once? > > I suppose that one way to do this is to make /boot a separate file > system beside /boot/efi. > All in all, the configuration would look like this: > > --8<---------------cut here---------------start------------->8--- > (mapped-devices > (list (mapped-device > (source (uuid "12345678-1234-1234-1234-123456789abc")) > (target "my-root") > (type luks-device-mapping)))) > > (file-systems (append > (list (file-system > (device (file-system-label "my-root")) > (mount-point "/") > (type "ext4") > (dependencies mapped-devices)) > (file-system > (device (file-system-lavel "boot") > (mount-point "/boot") > (type "ext4")) > (file-system > (device (uuid "1234-ABCD" 'fat)) > (mount-point "/boot/efi") > (type "vfat"))) > %base-file-systems)) > --8<---------------cut here---------------end--------------->8--- > > We should probably update the doc and templates to explain this > subtlety, since mistakes in the partition design are hard to recover > after the fact :) > > Insights? > leaving /boot unencrypted allows attackers to plant malware relatively easy. They can mount the partition without ado and replace the kernel with a malicious one. A nefarious law enforcement agency may seize your computer and give it back, seemingly without modifications. Boom, you are owned! To make it harder, we leave /boot encrypted. Now the attacker plants their malware further down the stack: they replace the BIOS. Boom, you are owned! :-) To make it harder, we ensure to have UEFI BIOS and enable Secure Boot. Now the attacker exploits the Intel Management Engine (ME) flaws[0]. AMD is flawed as well[1]. Boom, you are owned! To make it harder, we exploit the flaws ourselves and replace most of ME with an (of course) most secure BIOS. Now the attacker goes even further down the stack and implants their malware in the PCB[2]. Boom, you are owned! No matter what you do, you are owned. That doesn't even touch another great attack surface that an internet connected computer is. For maximum security, you should dig a hole, plant a metal cage that can hold the computer and completely autonomous power source (think plutonium), then have a tor-like connection of your monitor, mouse and keyboard to that machine (and a big red button that lets you destroy the hops). On a more serious note and to answer your question, unencrypted /boot is an option. Another is to have a key file on an external medium. This doesn't avoid the second wait. The long wait may be due to --iter-time option to cryptsetup luksFormat. I haven't looked what the default is in Guix. The Grub decryption code is also purported to be slow [no source]. For a long time I personally used root encrypted systems and found the hassle not worth it. Encrypting /home and external hard drives should cut it. If you suspect the machine has been tampered with, don't boot don't touch it. Even the hard disk firmware may have been modified. Don't think you are in danger of being targeted? Well, you already are! Your mail often gets into my spam folder because of "suspicious TLD .xyz". That should be very telling ;-)) Best regards Ellen [0] https://media.ccc.de/v/36c3-10694-intel_management_engine_deep_dive [1] https://media.ccc.de/v/thms-38-dissecting-the-amd-platform-security-processor [2] https://media.ccc.de/v/36c3-10690-open_source_is_insufficient_to_solve_trust_problems_in_hardware