bugGNU GRUB - Bugs: bug #59520, Dynamically append luks key to...


You are not allowed to post comments on this tracker with your current authentication level.

bug #59520: Dynamically append luks key to initramfs to avoid having it stored on system

Submitted by:  Tyson Whitehead <twhitehead>
Submitted on:  Mon 23 Nov 2020 04:13:10 PM UTC  
Votes:  20  
Category:  Security Severity:  Major
Priority:  5 - Normal Item Group:  None
Status:  Fixed Privacy:  Public
Assigned to:  None Originator Name: 
Open/Closed:  Open Release: 
Release:  Git master Reproducibility:  None
Planned Release:  None

Sun 19 Sep 2021 08:02:31 PM UTC, comment #4: 

@phcoder - can you please enlighten us how this works in your opinion? Please provide specific instructions, as apparently not a single distribution knows how to do this. Everyone is defaulting to storing the keyfile in /the/ initrd/initramfs.

Stefan BrĂ¼ns <stefanbruens>
Sat 19 Dec 2020 01:53:52 AM UTC, comment #3: 

What does (proc)/ have to do with it? I presume you're referring to (proc)/luks_script. While this does show the master key for the luks volume, how is that a solution to passing the key to the initrd environment? I do not believe that this issue is fixed, but I'd be grateful to be proven wrong.

Fri 18 Dec 2020 09:47:55 AM UTC, comment #2: 

Already implemented since several years. See files in (proc)/

Vladimir Serbinenko <phcoder>
Project Administrator
Thu 17 Dec 2020 09:43:48 PM UTC, comment #1: 

Seems like this might be an idea who time has come. I recently realized this earlier this year and implemented it in my setup.
Actually, no changes to grub are required. Just create your initrd with the key, and then when booting add the new initrd to the "initrd" command along with the already existing initrd. The key here is that grub already has had for a long while now the capability to specify multiple initrds as arguments to the "initrd" command and it will concatenate all arguments.

For key security and to provide one-password boot, I store the new initrd inside a luks volume. On boot I provide the password to the luks volume containing the initrd, and then append the initrd with the key to the main initrd when booting.

If I understand you correctly, you're suggesting that the password be the contents of a path in a created initrd. That would cut out a lot of the extra hoops I need to jump through in my setup. I don't think grub should add any behavior to specifically pass LUKS keys though. There should be a more general mechanism that is not on by default.

Perhaps part of that general mechanism would be a grub command to create a in-memory initrd from a list of paths, which can then be added as an argument to the "initrd" command.

This may take a while before it gets implemented. In the mean time, I suggest my current work around.

Mon 23 Nov 2020 04:13:10 PM UTC, original submission:  

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


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.

Tyson Whitehead <twhitehead>


No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by stefanbruens (Posted a comment)
  • -email is unavailable- added by stefanbruens
  • -email is unavailable- added by phcoder (Posted a comment)
  • -email is unavailable- added by g10 (Posted a comment)
  • -email is unavailable- added by twhitehead (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 20 encouragements so far.

    Only logged-in users can vote.




    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-09-19 stefanbruens Carbon-Copy- => Added stefanbruens
    2020-12-18 phcoder StatusNone => Fixed

    Back to the top

    Powered by Savane 3.7