Typing LUKS passphrase only once and a possible solution

Typing LUKS passphrase only once and a possible solution

[Thomas Albers]

Hello everyone,

I recently installed guix on my X200T and through the process I found
some challenges I was not not solve by myself. Its nothing strictly
necessary but I would like to solve them nonetheless.

My current setup consists of libreboot, my main luks partition and a
lvm group inside.

The problem I mentioned is the necessity of typing the passphrase for
the luks device twice. Once for the bootloader and again for the
kernel itself.

In other distributions this is avoided by copying a key file into the
initramfs and passing the kernel parameter "cryptkey" to linux. So
naturally the first I tried after not finding any documentation on
this topic was this, albeit without success.

Reading the relevant files (gnu system linux-initrd) and
(gnu system mapped-devices) I noticed that the kernel parameter is not
really needed, because the one decrypting the luks device is actually
the init script inside the initramfs.

So the question would be: Is it possible to add arguments to the call
to cryptsetup inside the init script without having to redefine the
"luks-device-mapping" variable and without rewriting the definition of
the "open-luks-device" function? - both defined locally inside the
(gnu system mapped-devices) module.

My suggestion would be to add a "extra-options" field to
<mapped-device> structure. This field would be appended to the command
line arguments to the cryptsetup call.

One could also add a "keyfile" parameter but this would be too
specific to the luks device mapper and it would also cause other
problems as well. For example, not everyone would like to store the
keyfile inside the store.

Also, is it possible to modify existing code for such small changes,
without needing to rewrite complete functions? Many of the functions
used are not exposed by the modules and one needs to rewrite the
function one wants to use and also its dependencies.

My last question would be: Why is the file called initrd, when in
reality a initramfs scheme is used?

Thanks for taking the time to read this and for any help you can
provide.

Thomas Albers Raviola

Re: Typing LUKS passphrase only once and a possible solution

[Tobias Geerinckx-Rice]

[-- Attachment #1: Type: text/plain, Size: 1822 bytes --]

Hi Thomas,

Quick answer; apologies if I miss some subtleties.

Thomas Albers 写道：
> My suggestion would be to add a "extra-options" field to
> <mapped-device> structure. This field would be appended to the 
> command
> line arguments to the cryptsetup call.
>
> One could also add a "keyfile" parameter but this would be too
> specific to the luks device mapper

Well, so is a field to add crypsetup-specific command-line 
arguments.

Abstracting this into meaningful field names like key-file is 
better from a readability point of view and allows implementation 
details like ‘we simply invoke cryptsetup’ to remain properly 
hidden from view.

Because naturally, one day cryptsetup will be rewritten in Guile.

> For example, not everyone would like to store the keyfile inside 
> the
> store.

I think it could still be a plain string passed straight to 
cryptsetup, with the user responsible for its existence.

> Also, is it possible to modify existing code for such small 
> changes,
> without needing to rewrite complete functions? Many of the 
> functions
> used are not exposed by the modules and one needs to rewrite the
> function one wants to use and also its dependencies.

You can force access to unexported symbols using (@@ (name of 
module) symbol).  It's as recommended as it sounds.  Nor can you 
rewrite parts of compiled procedures AFAIK.

> My last question would be: Why is the file called initrd, when 
> in
> reality a initramfs scheme is used?

Saves space :-)

Conceptually, they are the same thing.  Nobody who knows what 
‘initrd’ means will read the word in 2021 and think the 
distribution literally only supports pre-2005 ramdisks.

It also keeps us consistent with GRUB, which uses ‘initrd’.

Kind regards,

T G-R

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

Re: Typing LUKS passphrase only once and a possible solution

[Joshua Branson]

Thomas Albers <tgalbers2000@gmail.com> writes:

> Hello everyone,
>
> I recently installed guix on my X200T and through the process I found
> some challenges I was not not solve by myself. Its nothing strictly
> necessary but I would like to solve them nonetheless.
>
> My current setup consists of libreboot, my main luks partition and a
> lvm group inside.

I'm a little jealous.  I haven't figured out how to set up an encrypted
/.  Did you encrypt your /boot as well!?  I've got a osboot-ed T400.

> The problem I mentioned is the necessity of typing the passphrase for
> the luks device twice. Once for the bootloader and again for the
> kernel itself.

I've heard that this is the "most" secure way of booting.  Though I'm no
security expert.  :)

> In other distributions this is avoided by copying a key file into the
> initramfs and passing the kernel parameter "cryptkey" to linux. So
> naturally the first I tried after not finding any documentation on
> this topic was this, albeit without success.

I don't think that we have a guix-y way of doing this yet.  Though I
would love it if we did!

Your other questions have moved past my expertise.  I wish I could be
more help.  :)

>
> Thomas Albers Raviola
>

--
Joshua Branson (jab in #guix)
Sent from Emacs and Gnus
  https://gnucode.me
  https://video.hardlimit.com/accounts/joshua_branson/video-channels
  https://propernaming.org
  "You can have whatever you want, as long as you help
enough other people get what they want." - Zig Ziglar

Re: Typing LUKS passphrase only once and a possible solution

[Thomas Albers]

Hello Tobias,

Thank you for your answer.

>
> Well, so is a field to add crypsetup-specific command-line arguments.
>
> Abstracting this into meaningful field names like key-file is better
> from a readability point of view and allows implementation details
> like ‘we simply invoke cryptsetup’ to remain properly hidden from
> view.
>
> Because naturally, one day cryptsetup will be rewritten in Guile.
>
My idea was for this parameter to be also used for other mapping
devices. This assumes there is always an underlying program being used,
but if the final goal is to replace cryptsetup with scheme code, then
there isn't really a point to it.

>
> I think it could still be a plain string passed straight to
> cryptsetup, with the user responsible for its existence.
>
I am not really sure if a string would be the best solution though. The
key-file is a binary one. But you are right, there doesn't seem to be
much point in hiding the key-file. If someone has a program capable of
reading the file and getting it out of your computer, then there is
nothing stopping this person from accesing all of your files regardless
of encryption.

>
> You can force access to unexported symbols using (@@ (name of module)
> symbol).  It's as recommended as it sounds.  Nor can you rewrite parts
> of compiled procedures AFAIK.
>
This will come in handy while experimenting but it sounds like something
to be avoided, as it would be too dependant on the underlying code.

Regards,
Thomas Albers Raviola

Re: Typing LUKS passphrase only once and a possible solution

[Wiktor Żelazny]

[-- Attachment #1: Type: text/plain, Size: 483 bytes --]

On Wed, Jul 07, 2021 at 02:12:26PM -0400, Joshua Branson wrote:

> I haven't figured out how to set up an encrypted /.  Did you encrypt
> your /boot as well!?  I've got a osboot-ed T400.

Hi,

For full encryption, you might be interested in taking a look at the
Guix System and Libreboot guide by Raghav "RG" Gururajan [1]. I’m not
sure if the solution is going to work without libreboot, though.

WŻ

[1]: https://flossmanuals.net/pub/guix-system-and-libreboot.pdf

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: Typing LUKS passphrase only once and a possible solution

[Vagrant Cascadian]

[-- Attachment #1: Type: text/plain, Size: 1575 bytes --]

On 2021-07-07, Thomas Albers wrote:
> But you are right, there doesn't seem to be
> much point in hiding the key-file. If someone has a program capable of
> reading the file and getting it out of your computer, then there is
> nothing stopping this person from accesing all of your files regardless
> of encryption.

Depends on if you're on a multi-user system where only some people have
root access or a single-user system where the only user has root access.

If the key is stored in /gnu/store, it's world-readable, whereas with
traditional unix permissions or other access controls you can at least
make the initrd and key-file read-only.

I envision a workflow where you generate the initrd in the store
(world-readable) without the key-file, and then concatenate the initrd
and a cpio archive containing the key-file to a root-only-readable file
that grub is configured to load as the initrd. (or maybe grub can load
two cpio archives and concatenate them together?)

This would allow everything except the key-file to be world-readable,
while still keeping (within the constraints of unix file permissions and
or some other access control) the key-file private.

This presumes that you still enter the passphrase manually for grub or
some other bootloader to be able to load the "private" initrd+key-file
from an encrypted partition. It does solve the problem of entering the
passphrase twice.

Another option would be to keep the keyfile on removable media, and have
the initrd read the keyfile from that...


live well,
  vagrant

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]