unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Ellen Papsch <ellen.papsch@wine-logistix.de>
To: Pierre Neidhardt <mail@ambrevar.xyz>, guix-devel@gnu.org
Subject: Re: Unencrypted boot with encrypted root
Date: Fri, 03 Apr 2020 17:44:13 +0200	[thread overview]
Message-ID: <17c316adc8485d1f09f70d291cfaad50258c6c1f.camel@wine-logistix.de> (raw)
In-Reply-To: <87ftdmi7pp.fsf@ambrevar.xyz>

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

  parent reply	other threads:[~2020-04-03 15:44 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-02  8:59 Unencrypted boot with encrypted root Pierre Neidhardt
2020-04-03 15:32 ` pelzflorian (Florian Pelz)
2020-04-03 15:44 ` Ellen Papsch [this message]
2020-04-03 16:13   ` Pierre Neidhardt
2020-04-03 17:16     ` Ellen Papsch
2020-04-03 19:56       ` Guillaume Le Vaillant
2020-04-04  9:02         ` Pierre Neidhardt
2020-05-17 15:39         ` Pierre Neidhardt
2020-05-20  8:49           ` Guillaume Le Vaillant
2020-05-20  9:42             ` Pierre Neidhardt
2020-04-03 19:44   ` pelzflorian (Florian Pelz)
2020-04-04  8:12     ` Ellen Papsch
2020-04-04 10:18       ` pelzflorian (Florian Pelz)
2020-04-06 12:00         ` Ellen Papsch
2020-04-07  9:46           ` Ludovic Courtès
2020-04-07 11:34             ` Ellen Papsch
2020-04-07 20:19               ` Ludovic Courtès
2020-04-08 12:37                 ` Ellen Papsch
2020-04-07 15:05             ` Alex Griffin
2020-04-07 16:47               ` Vagrant Cascadian
2020-04-08 12:25                 ` Ellen Papsch
2020-04-08 15:07                   ` Alex Griffin
2020-04-08 16:22                   ` Vagrant Cascadian
2020-04-08  7:57               ` Pierre Neidhardt
2020-04-08 12:19                 ` Alex Griffin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=17c316adc8485d1f09f70d291cfaad50258c6c1f.camel@wine-logistix.de \
    --to=ellen.papsch@wine-logistix.de \
    --cc=guix-devel@gnu.org \
    --cc=mail@ambrevar.xyz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).