GuixSD encrypted root?

GuixSD encrypted root?

[Danny Milosavljevic]

Hi,

with the latest luks-related commits in guix I figured it's time to try disk encryption again (after updating guix from git).

I added a mapped-devices section to my config and then did guix reconfigure ... which made it hang at

  making '/gnu/store/5df8pzbsbk2pn2s99hj8r6kb45smy3dv-system' the current system...

The problem is reproducible every time. If I use cryptsetup manually it works (I created a btrfs filesystem on it and mounted it - worked fine).

I tried to patch gnu/system/mapped-devices.scm to pass additional arguments but that didn't do anything either (I can see guix's cryptsetup running when I do "ps -ef", and it didn't receive the new arguments). 

And I have a conceptual question: there are many different ways for cryptsetup to get the key and/or passphrase. How do I configure this? What does it do when I said nothing of the key location or type or passphrase input method?

Also, I think the best way to have encrypted home is to have the login manager / pam module unlock your personal encrypted home since these have your password in transit and it doesn't need to be stored anywhere on disk - also it will only be asked once the user actually tries to log in. (Ubuntu also does it like that and it seems to work fine for them)

The global mapped-devices config is useful for whole-disk encryption - where the boot process then has to ask for the passphrase on the console early every time you boot or communicate with some security dongle or the BIOS or whatever - from the initrd.

I know that Jookia et al did a lot of work on this already - but what's the status of full disk encryption (on libreboot)?

Re: GuixSD encrypted root?

[Danny Milosavljevic]

> I tried to patch gnu/system/mapped-devices.scm to pass additional arguments but that didn't do anything either (I can see guix's cryptsetup running when I do "ps -ef", and it didn't receive the new arguments). 

After a reboot it did add them and it "system reconfigure"d fine now.

The arguments I added were
  "--key-file=etcetc" "--keyfile-size=etcetcsz"

(the "--keyfile-size" has no dash between "key" and "file" - it's supposed to be like that)

Re: GuixSD encrypted root?

[Danny Milosavljevic]

And when I add a file-system like this

(define dayas-sys (mapped-device
                         (source (uuid "blahblahblah"))
                         (target "dayas-sys")
                         (type luks-device-mapping)))


...
  (mapped-devices (list dayas-sys))
  (file-systems (cons* (file-system
                        (device "/dev/sda1")
                        (title 'dayas:/)
                        (mount-point "/")
                        (type "ext4")
                        (needed-for-boot? #t))
                       (file-system
                        (device "/dev/mapper/dayas-sys")
                        (mount-point "/x")
                        (type "btrfs")
                        (needed-for-boot? #f)
                        (dependencies (list dayas-sys)))
                       %base-file-systems))

system reconfigure hangs at

  guix system: shepherd: Removing service 'file-system-/x'...
  guix system: shepherd: Done.
  guix system: loading new services: file-system-/x...
  guix system: shepherd: Evaluating user expression (register-services (primitive-load "/gnu/s...")).

.

Unfortunately because of the abbreviation in the output of the command above                  ^^^ I have no idea what it's trying to do.

The device has already been mapped at /dev/mapper/dayas-sys , however it has not yet mounted the filesystem as /x .

Re: GuixSD encrypted root?

[Danny Milosavljevic]

And now it stored a configuration that didn't boot (the one who hanged on reconfiguration, I suppose). [most of the services didn't start up and I couldn't log in]

Thanks for the retained old versions in the grub menu, I just booted one of those!

Re: GuixSD encrypted root?

[Danny Milosavljevic]

guix reconfigure works and doesn't hang if I add (mount? #f) and reboot and mount it manually, like:

>                        (file-system
>                         (device "/dev/mapper/dayas-sys")
>                         (mount-point "/x")
>                         (type "btrfs")
>                         (needed-for-boot? #f)
 (mount? #f)
>                         (dependencies (list dayas-sys)))
>                        %base-file-systems))

Re: GuixSD encrypted root?

[Ludovic Courtès]

Hi!

Encrypted root file systems are not supported yet (some people managed
to work around the lack of support, but that’s somewhat fragile.)

Good news is we’re getting there!  You can track progress at
<http://bugs.gnu.org/21843>.

Thanks,
Ludo’.

Re: GuixSD encrypted root?

[Danny Milosavljevic]

On Sun, 24 Apr 2016 16:22:16 +0200
ludo@gnu.org (Ludovic Courtès) wrote:

> Encrypted root file systems are not supported yet (some people managed
> to work around the lack of support, but that’s somewhat fragile.)
> 
> Good news is we’re getting there!  You can track progress at
> <http://bugs.gnu.org/21843>.

Thanks!

Yeah, but even using a non-required-for-boot encrypted filesystem (i.e. not an encrypted root, just encrypted home) doesn't work. As soon as I add "mount? #t" it hangs.

I'm now using a workaround where it's specified using "mount? #f" and I mount it using a autorun script in my homedir (using "mount /x"). That works fine.

You're using an encrypted home, right? Does it work for you?

It's always very broken when I try - both guix reconfigure and sometimes the next boot process (!) hang.

Re: GuixSD encrypted root?

[Leo Famulari]

On Sun, Apr 24, 2016 at 06:04:25PM +0200, Danny Milosavljevic wrote:
> On Sun, 24 Apr 2016 16:22:16 +0200
> ludo@gnu.org (Ludovic Courtès) wrote:
> 
> > Encrypted root file systems are not supported yet (some people managed
> > to work around the lack of support, but that’s somewhat fragile.)
> > 
> > Good news is we’re getting there!  You can track progress at
> > <http://bugs.gnu.org/21843>.
> 
> Thanks!
> 
> Yeah, but even using a non-required-for-boot encrypted filesystem (i.e. not an encrypted root, just encrypted home) doesn't work. As soon as I add "mount? #t" it hangs.
> 
> I'm now using a workaround where it's specified using "mount? #f" and I mount it using a autorun script in my homedir (using "mount /x"). That works fine.
> 
> You're using an encrypted home, right? Does it work for you?

This works for me, with an encrypted /home on ext4. The boot process
stops and waits for me to decrypt /home, but otherwise there are no
complications.

> 
> It's always very broken when I try - both guix reconfigure and sometimes the next boot process (!) hang.
> 

Re: GuixSD encrypted root?

[Ludovic Courtès]

Hey,

Danny Milosavljevic <dannym@scratchpost.org> skribis:

> Yeah, but even using a non-required-for-boot encrypted filesystem (i.e. not an encrypted root, just encrypted home) doesn't work. As soon as I add "mount? #t" it hangs.
>
> I'm now using a workaround where it's specified using "mount? #f" and I mount it using a autorun script in my homedir (using "mount /x"). That works fine.
>
> You're using an encrypted home, right? Does it work for you?

Yes.  My configuration looks like this:

  (operating-system
    ;; …
    (mapped-devices (list (mapped-device
                           (source (uuid "cb67fc72-0d54-4c88-9d4b-b225f30b0f44"))
                           (target "home")
                           (type luks-device-mapping))))

    (file-systems (cons* (file-system
                           (device "root")
                           (title 'label)
                           (mount-point "/")
                           (type "ext3"))
                         (file-system
                           (device "/dev/mapper/home")
                           (mount-point "/home")
                           (type "ext3"))
                         %base-file-systems)))

What about yours?

> It's always very broken when I try - both guix reconfigure and sometimes the next boot process (!) hang.

Earlier you wrote:

> system reconfigure hangs at
>
>   guix system: shepherd: Removing service 'file-system-/x'...
>   guix system: shepherd: Done.
>   guix system: loading new services: file-system-/x...
>   guix system: shepherd: Evaluating user expression (register-services (primitive-load "/gnu/s...")).

At this point, shepherd loads and starts the service for file system /x,
which does what appears in ‘file-system-shepherd-service’ in (gnu
services base).  Roughly, it runs fsck and then proceeds to mount /x.

If you’re out of luck, fsck could take ages.  Could it be what happened
here?

At any rate, the upgrade is complete before the Shepherd has loaded the
new services.  That is, on the next reboot, you end up in the new
configuration.

HTH!

Ludo’.

Re: GuixSD encrypted root?

[Ludovic Courtès]

ludo@gnu.org (Ludovic Courtès) skribis:

> Hey,
>
> Danny Milosavljevic <dannym@scratchpost.org> skribis:
>
>> Yeah, but even using a non-required-for-boot encrypted filesystem (i.e. not an encrypted root, just encrypted home) doesn't work. As soon as I add "mount? #t" it hangs.
>>
>> I'm now using a workaround where it's specified using "mount? #f" and I mount it using a autorun script in my homedir (using "mount /x"). That works fine.
>>
>> You're using an encrypted home, right? Does it work for you?
>
> Yes.  My configuration looks like this:
>
>   (operating-system
>     ;; …
>     (mapped-devices (list (mapped-device
>                            (source (uuid "cb67fc72-0d54-4c88-9d4b-b225f30b0f44"))
>                            (target "home")
>                            (type luks-device-mapping))))
>
>     (file-systems (cons* (file-system
>                            (device "root")
>                            (title 'label)
>                            (mount-point "/")
>                            (type "ext3"))
>                          (file-system
>                            (device "/dev/mapper/home")
>                            (mount-point "/home")
>                            (type "ext3"))
>                          %base-file-systems)))
>
> What about yours?
>
>> It's always very broken when I try - both guix reconfigure and sometimes the next boot process (!) hang.
>
> Earlier you wrote:
>
>> system reconfigure hangs at
>>
>>   guix system: shepherd: Removing service 'file-system-/x'...
>>   guix system: shepherd: Done.
>>   guix system: loading new services: file-system-/x...
>>   guix system: shepherd: Evaluating user expression (register-services (primitive-load "/gnu/s...")).
>
> At this point, shepherd loads and starts the service for file system /x,
> which does what appears in ‘file-system-shepherd-service’ in (gnu
> services base).  Roughly, it runs fsck and then proceeds to mount /x.
>
> If you’re out of luck, fsck could take ages.  Could it be what happened
> here?

Or, as Leo suggests, it could be that shepherd starts the device-mapping
service, which runs “cryptsetup luksOpen”, which never completes because
you don’t know it’s waiting for you to enter a passphrase.

Ludo’.

Re: GuixSD encrypted root?

[Danny Milosavljevic]

Hi,

> Or, as Leo suggests, it could be that shepherd starts the device-mapping
> service, which runs “cryptsetup luksOpen”, which never completes because
> you don’t know it’s waiting for you to enter a passphrase.

I doubt that it's that. The only change I have to do for it to work just fine is to add "(mount? #f)". So I suspect that the cryptsetup works. (The only thing I have to type manually is "mount /x" later - and that works, too)

But I didn't know that Guix would run fsck on guix reconfigure. Maybe I just have to wait longer as it's a huge partition (with almost nothing on it, though). Also, I've checked gnu/services/base.scm and it seems to hard-code e2fsprogs. I use btrfs, though.

My config (which is working fine because of the "(mount #f)") is:

(define dayas-sys (mapped-device
                         (source (uuid "cedd378f-329c-44c4-ab40-f74f0c1701a2"))
                         (target "dayas-sys")
                         (type luks-device-mapping)))

(operating-system
  ;; ...
  (mapped-devices (list dayas-sys))
  (file-systems (cons* (file-system
                        (device "/dev/sda1")
                        (title 'dayas:/)
                        (mount-point "/")
                        (type "ext4")
                        (needed-for-boot? #t))
                       (file-system
                        (device "/dev/mapper/dayas-sys")
                        (mount-point "/x")
                        (type "btrfs")
                        (needed-for-boot? #f)
                        (mount? #f) ; otherwise does not work.
                        (dependencies (list dayas-sys)))
                       %base-file-systems))
  ;...
)

How come yours doesn't have a "dependencies" entry? Is it somehow computed by examining the "device" (/dev/mapper/...) entry?

Re: GuixSD encrypted root?

[Ludovic Courtès]

Danny Milosavljevic <dannym@scratchpost.org> skribis:

> Hi,
>
>> Or, as Leo suggests, it could be that shepherd starts the device-mapping
>> service, which runs “cryptsetup luksOpen”, which never completes because
>> you don’t know it’s waiting for you to enter a passphrase.
>
> I doubt that it's that. The only change I have to do for it to work just fine is to add "(mount? #f)". So I suspect that the cryptsetup works. (The only thing I have to type manually is "mount /x" later - and that works, too)
>
> But I didn't know that Guix would run fsck on guix reconfigure.

‘guix system reconfigure’ starts new services, and that is part of a
service.

> Maybe I just have to wait longer as it's a huge partition (with almost
> nothing on it, though). Also, I've checked gnu/services/base.scm and
> it seems to hard-code e2fsprogs. I use btrfs, though.

Only ext[234] are supported currently, indeed.  There’s
<https://debbugs.gnu.org/cgi/bugreport.cgi?bug=19280> and it’s been
discussed on the mailing list recently (I think Tobias made progress in
that direction).

> My config (which is working fine because of the "(mount #f)") is:
>
> (define dayas-sys (mapped-device
>                          (source (uuid "cedd378f-329c-44c4-ab40-f74f0c1701a2"))
>                          (target "dayas-sys")
>                          (type luks-device-mapping)))
>
> (operating-system
>   ;; ...
>   (mapped-devices (list dayas-sys))
>   (file-systems (cons* (file-system
>                         (device "/dev/sda1")
>                         (title 'dayas:/)
>                         (mount-point "/")
>                         (type "ext4")
>                         (needed-for-boot? #t))
>                        (file-system
>                         (device "/dev/mapper/dayas-sys")
>                         (mount-point "/x")
>                         (type "btrfs")
>                         (needed-for-boot? #f)
>                         (mount? #f) ; otherwise does not work.
>                         (dependencies (list dayas-sys)))
>                        %base-file-systems))
>   ;...
> )
>
> How come yours doesn't have a "dependencies" entry? Is it somehow computed by examining the "device" (/dev/mapper/...) entry?

The ‘dependencies’ field can be omitted if you change the ’title’ field
of the /x entry to 'device (info "(guix) File Systems"):

          However, when the source of a file system is a mapped device
          (*note Mapped Devices::), its ‘device’ field _must_ refer to
          the mapped device name—e.g., ‘/dev/mapper/root-partition’—and
          consequently ‘title’ must be set to ‘'device’.  This is
          required so that the system knows that mounting the file
          system depends on having the corresponding device mapping
          established.

I admit this is not ideal.  I’d rather allow the ‘device’ field of
<file-system> to contain directly the <mapped-device>.

HTH,
Ludo’.