[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/
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [bug #59520] Dynamically append luks key to initramfs to avoid having it stored on system,
Tyson Whitehead <=