bug-grub
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #59520] Dynamically append luks key to initramfs to avoid having it


From: Tyson Whitehead
Subject: [bug #59520] Dynamically append luks key to initramfs to avoid having it stored on system
Date: Mon, 23 Nov 2020 11:13:12 -0500 (EST)
User-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.111 Safari/537.36

URL:
  <https://savannah.gnu.org/bugs/?59520>

                 Summary: Dynamically append luks key to initramfs to avoid
having it stored on system
                 Project: GNU GRUB
            Submitted by: twhitehead
            Submitted on: Mon 23 Nov 2020 04:13:10 PM UTC
                Category: Security
                Severity: Major
                Priority: 5 - Normal
              Item Group: None
                  Status: None
                 Privacy: Public
             Assigned to: None
         Originator Name: 
        Originator Email: 
             Open/Closed: Open
                 Release: 
                 Release: Git master
         Discussion Lock: Any
         Reproducibility: None
         Planned Release: None

    _______________________________________________________

Details:

This is a security enhancement request.

If you are booting linux from a fully encrypted disk, you have to type your
password twice. Once for grub to get to the kernel and initramfs, and then
once again for the initramfs to be able to mount the filesystem. To avoid
this, people are storing a permanent copy of the key in the initramfs as
/crypto_keyfile.bin or the likes. For example

https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system#Create_keyfile
https://www.pavelkogan.com/2014/05/23/luks-full-disk-encryption/
etc.

While technically this is a you-have-to-have-the-key-to-get-the-key situation,
it still seems unfavorable. For example, an incorrect permissions issue or an
exploit that lets local users or remote individuals read the local filesystem
with escalated privileges would expose this key to an attacker.

Given that the initramfs is just concatenated cpio archives that are unpacked
into a ramfs sequentially, it would seem (hopefully) it might not be too much
work to extend grub to avoid this. Grub could dynamically pass the key by
creating a minimal in memory /crypto_keyfile.bin cpio archive and then
appending it to the loaded initramfs before booting.

The sensitive key information would then no longer have to be physically part
of the loaded initramfs that is stored on disk.




    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?59520>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]