Re: Unencrypted boot with encrypted root

[Ellen Papsch]

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