* Typing LUKS passphrase only once and a possible solution
@ 2021-07-07 16:05 Thomas Albers
2021-07-07 16:42 ` Tobias Geerinckx-Rice
2021-07-07 18:12 ` Joshua Branson
0 siblings, 2 replies; 6+ messages in thread
From: Thomas Albers @ 2021-07-07 16:05 UTC (permalink / raw)
To: help-guix
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Typing LUKS passphrase only once and a possible solution
2021-07-07 16:05 Typing LUKS passphrase only once and a possible solution Thomas Albers
@ 2021-07-07 16:42 ` Tobias Geerinckx-Rice
2021-07-07 18:29 ` Thomas Albers
2021-07-07 18:12 ` Joshua Branson
1 sibling, 1 reply; 6+ messages in thread
From: Tobias Geerinckx-Rice @ 2021-07-07 16:42 UTC (permalink / raw)
To: Thomas Albers; +Cc: help-guix
[-- 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 --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Typing LUKS passphrase only once and a possible solution
2021-07-07 16:42 ` Tobias Geerinckx-Rice
@ 2021-07-07 18:29 ` Thomas Albers
2021-07-08 17:29 ` Vagrant Cascadian
0 siblings, 1 reply; 6+ messages in thread
From: Thomas Albers @ 2021-07-07 18:29 UTC (permalink / raw)
To: Tobias Geerinckx-Rice; +Cc: help-guix
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Typing LUKS passphrase only once and a possible solution
2021-07-07 18:29 ` Thomas Albers
@ 2021-07-08 17:29 ` Vagrant Cascadian
0 siblings, 0 replies; 6+ messages in thread
From: Vagrant Cascadian @ 2021-07-08 17:29 UTC (permalink / raw)
To: Thomas Albers, Tobias Geerinckx-Rice; +Cc: help-guix
[-- 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 --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Typing LUKS passphrase only once and a possible solution
2021-07-07 16:05 Typing LUKS passphrase only once and a possible solution Thomas Albers
2021-07-07 16:42 ` Tobias Geerinckx-Rice
@ 2021-07-07 18:12 ` Joshua Branson
2021-07-07 18:30 ` Wiktor Żelazny
1 sibling, 1 reply; 6+ messages in thread
From: Joshua Branson @ 2021-07-07 18:12 UTC (permalink / raw)
To: Thomas Albers; +Cc: help-guix
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-07-08 17:32 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-07-07 16:05 Typing LUKS passphrase only once and a possible solution Thomas Albers
2021-07-07 16:42 ` Tobias Geerinckx-Rice
2021-07-07 18:29 ` Thomas Albers
2021-07-08 17:29 ` Vagrant Cascadian
2021-07-07 18:12 ` Joshua Branson
2021-07-07 18:30 ` Wiktor Żelazny
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).