From: Josselin Poiret via Guix-patches via <guix-patches@gnu.org>
To: chayleaf <chayleaf@pavluk.org>, 52882@debbugs.gnu.org
Subject: [bug#52882] [PATCH] gnu: system: Add crypt-key field for mapped filesystems
Date: Fri, 31 Dec 2021 18:58:28 +0100 [thread overview]
Message-ID: <87bl0wfygr.fsf@jpoiret.xyz> (raw)
In-Reply-To: <0fcf6e432f009e05cb69143bee6009a92a13cad4.camel@pavluk.org>
Hello,
chayleaf <chayleaf@pavluk.org> writes:
> Wouldn't it be fine if the key is stored on an external device and the
> user supplies a G-Expression that loads it? Or is the G-Expression
> executed at reconfigure as opposed to at boot?
It would indeed be fine. The open-luks-device g-exp is executed at
boot, in early userspace (ie no root mounted yet, still in the
initramfs), by `build-system` in (gnu build linux-boot) as a member of
`pre-mount`.
> Storing the key itself is indeed insecure. However, I think the
> ability to load the key from something other than user input could
> become a building block for hardcoding the key in more secure ways.
> For example, as far as I can tell, Grub supports multiple initrd
> images [1], if the user puts their key on the boot partition in the
> cpio format and tells Grub to use it as a secondary initrd, perhaps it
> could be done.
Yes, this is what I was suggesting, although I don't really know how
Linux handles multiple initrds. Is the resulting initramfs a union of
the different initrds?
> I do agree that at the very least the potential security issues
> hardcoding the key can cause need to be documented.
Agreed.
> The biggest problem is there need to be multiple generations available
> at the same time. While you could create a separate "private" only-
> read-by-root initrd store for this purpose, that would be too much work
> for just a single feature. A possible compromise is maintaining a
> single out-of-store initrd at a given time, or, combined with the
> above, the "secret" initrd parts could be stored in a separate archive,
> similar to how grub resides in its own directory outside of the store.
Out-of-store that's specified by the user seems like a good idea. Do
you think you could handle adding additional initrd support to GRUB? I
don't think it should be that hard.
Apart from that, the patch would be ok to merge for me if there was some
accompanying documentation that describes the security risks in a way
that would be understable for a layperson.
Best,
Josselin Poiret
next prev parent reply other threads:[~2021-12-31 17:59 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-29 21:57 [bug#52882] [PATCH] gnu: system: Add crypt-key field for mapped filesystems chayleaf
2021-12-30 10:57 ` Josselin Poiret via Guix-patches via
2021-12-30 18:25 ` chayleaf
2021-12-31 17:58 ` Josselin Poiret via Guix-patches via [this message]
2022-01-03 19:12 ` chayleaf
2022-01-05 21:20 ` Ludovic Courtès
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=87bl0wfygr.fsf@jpoiret.xyz \
--to=guix-patches@gnu.org \
--cc=52882@debbugs.gnu.org \
--cc=chayleaf@pavluk.org \
--cc=dev@jpoiret.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).