LUKS-encrypted root and unencrypted /boot ?

LUKS-encrypted root and unencrypted /boot ?

[Benjamin Slade]

Doing a full LUKS-encryption on root, including /boot results in very
slow unlocking at boot (about 30 secs even with --iter set to 1000). Is
there any way to do an unencrypted /boot with an encrypted root?

I found that at least in GuixSD 0.12 it didn't seem to be possible:
https://lists.gnu.org/archive/html/help-guix/2016-12/msg00096.html . Has
this changed?

Re: LUKS-encrypted root and unencrypted /boot ?

[Clément Lassieur]

Hi Benjamin,

Do you use Libreboot?

Benjamin Slade <beoram@gmail.com> writes:

> Doing a full LUKS-encryption on root, including /boot results in very
> slow unlocking at boot (about 30 secs even with --iter set to 1000). Is
> there any way to do an unencrypted /boot with an encrypted root?

I'm unsure that would help, because GRUB would still have to unencrypt /
to access the kernel (the kernel is in /gnu/store).

Clément

Re: LUKS-encrypted root and unencrypted /boot ?

[Chris Marusich]

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

Benjamin Slade <beoram@gmail.com> writes:

> Doing a full LUKS-encryption on root, including /boot results in very
> slow unlocking at boot (about 30 secs even with --iter set to 1000). Is
> there any way to do an unencrypted /boot with an encrypted root?

At that stage, is it GRUB that is unlocking the encrypted volume?  If
so, I think this is normal.

I don't know much about the details, but it seems GRUB's implementation
of the LUKS-related cryptographic algorithms is significantly slower
than the one used by Linux later in the boot process.  Because you (I
presume) created the LUKS key using cryptsetup from within a running
GNU/Linux system, it probably ran the PBKDF2 algorithm for a short
period of time using the more performant algorithms, and in order for
GRUB to perform the same number of iterations, it takes longer.

For what it's worth, GRUB is slow in unlocking my encrypted volumes,
too.  It takes about 30 seconds for me, too.  If you're concerned, you
can try using cryptsetup's --iter-time option to lower the number of
iterations, but keep in mind that will also make it easier to crack your
passphrase.

Hope that helps!

-- 
Chris

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

Re: LUKS-encrypted root and unencrypted /boot ?

[Benjamin Slade]

 > Do you use Libreboot?

Yes, I'm using Libreboot. Does this make a great difference over the
manufacturer firmware in this case?

 > I'm unsure [using an unencrypted /boot] would help, because GRUB
 > would still have to unencrypt / to access the kernel (the kernel is
 > in /gnu/store).

Ah, I see. Is this an immutable design decision?  It would seem good to
be able to keep the kernel in a separate space in order to avoid the
issue of extremely long unlocking times when booting.

--
Benjamin Slade - https://babbagefiles.xyz
  `(pgp_fp: ,(21BA 2AE1 28F6 DF36 110A 0E9C A320 BBE8 2B52 EE19))
    '(sent by mu4e on Emacs running under GNU/Linux . https://gnu.org )
       `(Choose Linux ,(Choose Freedom) . https://linux.com )

Re: LUKS-encrypted root and unencrypted /boot ?

[Benjamin Slade]

On 2018-08-02T02:24:31-0600, Chris Marusich <cmmarusich@gmail.com> wrote:

 > > Doing a full LUKS-encryption on root, including /boot results in
 > > very slow unlocking at boot (about 30 secs even with --iter set to
 > > 1000). Is there any way to do an unencrypted /boot with an
 > > encrypted root?

 > At that stage, is it GRUB that is unlocking the encrypted volume?  If
 > so, I think this is normal.


 > For what it's worth, GRUB is slow in unlocking my encrypted volumes,
 > too.  It takes about 30 seconds for me, too.  If you're concerned,
 > you can try using cryptsetup's --iter-time option to lower the number
 > of iterations, but keep in mind that will also make it easier to
 > crack your passphrase.

Originally I had --iter set to '5000' and it took about 4 minutes to
unlock!  I've shifted to using an unencrypted root and an encrypted
/home as a compromise that boots faster (and only requests the password once).

--
Benjamin Slade - https://babbagefiles.xyz
  `(pgp_fp: ,(21BA 2AE1 28F6 DF36 110A 0E9C A320 BBE8 2B52 EE19))
    '(sent by mu4e on Emacs running under GNU/Linux . https://gnu.org )
       `(Choose Linux ,(Choose Freedom) . https://linux.com )

Re: LUKS-encrypted root and unencrypted /boot ?

[Clément Lassieur]

Benjamin Slade <beoram@gmail.com> writes:

>  > Do you use Libreboot?
>
> Yes, I'm using Libreboot. Does this make a great difference over the
> manufacturer firmware in this case?

It might, because the GRUB used is the one shipped with Libreboot.  So
it has nothing to do with Guix.  I think talking to the libreboot people
would help you more.  (Disclaimer: I have the same issue, I find that
pressing 'c' and typing 'cryptomount ahci0,gpt3' makes the process
faster.)

>  > I'm unsure [using an unencrypted /boot] would help, because GRUB
>  > would still have to unencrypt / to access the kernel (the kernel is
>  > in /gnu/store).
>
> Ah, I see. Is this an immutable design decision?  It would seem good to
> be able to keep the kernel in a separate space in order to avoid the
> issue of extremely long unlocking times when booting.

Nothing is immutable, but it's a strong design decision that all
packages data are put in /gnu/store.  Linux is just one of them.  Plus,
a characteristic of GuixSD is that you can revert to previous
configurations.  Those configurations appear as GRUB lines.  Each
configuration could have a different kernel and kernels take space, so
it wouldn't scale well.  Plus, I think some other stuff is needed as
well, like the initrd, which is large too, etc.

There are probably reasons I don't know about too :-)

Good luck!
Clément

Re: LUKS-encrypted root and unencrypted /boot ?

[Benjamin Slade]

Thanks, Clément.

 > >  > Do you use Libreboot?
 > >
 > > Yes, I'm using Libreboot. Does this make a great difference over the
 > > manufacturer firmware in this case?

 > It might, because the GRUB used is the one shipped with Libreboot.
 > So it has nothing to do with Guix.  I think talking to the libreboot
 > people would help you more.  (Disclaimer: I have the same issue, I
 > find that pressing 'c' and typing 'cryptomount ahci0,gpt3' makes the
 > process faster.)

Thanks, I'll look into that. For the moment I've just switched to having
an unencrypted root and encrypted /home partition (where the swapfile
also lives), which seems to me better from a security standpoint (I can
use --iter 500, sha512, &c. without an issue).

 > >  > I'm unsure [using an unencrypted /boot] would help, because GRUB
 > >  > would still have to unencrypt / to access the kernel (the kernel
 > >  > is in /gnu/store).
 > >
 > > Ah, I see. Is this an immutable design decision?  It would seem
 > > good to be able to keep the kernel in a separate space in order to
 > > avoid the issue of extremely long unlocking times when booting.

 > Nothing is immutable, but it's a strong design decision that all
 > packages data are put in /gnu/store.  Linux is just one of them.
 > Plus, a characteristic of GuixSD is that you can revert to previous
 > configurations.  Those configurations appear as GRUB lines.  Each
 > configuration could have a different kernel and kernels take space,
 > so it wouldn't scale well.  Plus, I think some other stuff is needed
 > as well, like the initrd, which is large too, etc.

I mused briefly about mirroring of the relevant things (kernels, initrd)
from /gnu/store to /boot, but that's probably pretty hack-y.

--
Benjamin Slade - https://babbagefiles.xyz
  `(pgp_fp: ,(21BA 2AE1 28F6 DF36 110A 0E9C A320 BBE8 2B52 EE19))
    '(sent by mu4e on Emacs running under GNU/Linux . https://gnu.org )
       `(Choose Linux ,(Choose Freedom) . https://linux.com )

Re: LUKS-encrypted root and unencrypted /boot ?

[Clément Lassieur]

Benjamin Slade <beoram@gmail.com> writes:

> Thanks, Clément.

You're welcome!

>  > >  > Do you use Libreboot?
>  > >
>  > > Yes, I'm using Libreboot. Does this make a great difference over the
>  > > manufacturer firmware in this case?
>
>  > It might, because the GRUB used is the one shipped with Libreboot.
>  > So it has nothing to do with Guix.  I think talking to the libreboot
>  > people would help you more.  (Disclaimer: I have the same issue, I
>  > find that pressing 'c' and typing 'cryptomount ahci0,gpt3' makes the
>  > process faster.)
>
> Thanks, I'll look into that. For the moment I've just switched to having
> an unencrypted root and encrypted /home partition (where the swapfile
> also lives),

> ...which seems to me better from a security standpoint (I can
> use --iter 500, sha512, &c. without an issue).

But it's easier put a malware in an unencrypted root ;)

Re: LUKS-encrypted root and unencrypted /boot ?

[Benjamin Slade]

 > > Thanks, I'll look into that. For the moment I've just switched to
 > > having an unencrypted root and encrypted /home partition (where the
 > > swapfile also lives),

 > > ...which seems to me better from a security standpoint (I can
 > > use --iter 500, sha512, &c. without an issue).

 > But it's easier put a malware in an unencrypted root ;)

That's true, but if someone has the time/access to be putting malware in
the unencrypted root of an GuixSD install (will they know to put things
in /gnu/store ?) they could also install physical keyloggers and so on
(perhaps more efficiently). So while I'd prefer to have the whole thing
encrypted, realistically I'm mainly protecting my personal data if it's
stolen/taken from me (as long it's off, that is).

--
Benjamin Slade - https://babbagefiles.xyz
  `(pgp_fp: ,(21BA 2AE1 28F6 DF36 110A 0E9C A320 BBE8 2B52 EE19))
    '(sent by mu4e on Emacs running under GNU/Linux . https://gnu.org )
       `(Choose Linux ,(Choose Freedom) . https://linux.com )

Re: LUKS-encrypted root and unencrypted /boot ?

[Chris Marusich]

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

Benjamin Slade <beoram@gmail.com> writes:

> I mused briefly about mirroring of the relevant things (kernels, initrd)
> from /gnu/store to /boot, but that's probably pretty hack-y.

The parts of GuixSD which require maintaining state outside of the store
tend to be a little complicated (in my opinion) because they don't fit
neatly into the "functional software deployment model" bubble that the
rest of Guix lives in.

We currently do this for the GRUB config: we copy it out of the store
into the /boot directory, instead of symlinking it.  I believe this was
done in order to support the use case of putting /gnu/store and /boot on
different partitions.  Technically, I think we could do the same sort of
thing for Linux kernel images and initrds, but what's the goal?  If the
goal is just to make it so GRUB doesn't have to open the LUKS volume in
order to boot, then your solution already meets the goal.

However, since your solution puts all of /gnu/store in an unencrypted
partition, you should keep in mind that anything you put in the store
will also be unencrypted.  Therefore, if you add anything from your home
directory to the store (e.g., by using local-file [see: (guix)
G-Expressions]), it may be exposed in the store.  That said, since the
store is generally readable by everybody on the system (and remotely, if
you are using "guix publish"), one probably shouldn't be putting
sensitive information in the store to begin with.

Hope that helps!

-- 
Chris

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