Geli password over network strategies

Paul Florence perso at florencepaul.com
Wed Jun 17 08:39:14 UTC 2020


It has been a few month now since this message, however I have been able 
to successfully use your script with minor modifications.

To sum it up :

1) Boot on a FreeBSD USB stick running the same kernel as the one 
installed on the server drive

2) Fetch encryption.key through sftp (or mount your bootpool)

3) Use your script to mount everything plus the bootpool which is needed 
because the file "/boot/zfs/zpool.cache" seems to be needed to mount 
everything correctly at boot time.

3) Reboot

Since the live system is on a USB key, I set the usb zfs pool 
(zroot_usb) to be read-only to avoid unwanted modifications (which could 
lock me out of my box in case of reboot) and extra wear on the flash cells.

However I have a strange behavior that I do not understand. It seems 
that the (zroot_usb zfs pool persists after the reboot and I can't find 
a way to disable it. Moreover, it is extra-confusing because it looks 
like I have two pools mounted at the same mountpoints. The system works 
mostly fine, but "pkg update" fails because /tmp is too small.

I tried to unmount zroot_usb using "zpool export", however since the 
file system is in use, the pool is busy.

Here is the output of "zfs get mounted" :


NAME                    PROPERTY  VALUE    SOURCE
bootpool                mounted   yes      -
zroot                   mounted   yes      -
zroot/ROOT              mounted   no       -
zroot/ROOT/default        mounted   yes      -
zroot/ROOT/default at bk1  mounted   -        -
zroot/tmp               mounted   yes      -
zroot/usr               mounted   no       -
zroot/usr/home          mounted   yes      -
zroot/usr/ports         mounted   yes      -
zroot/usr/src           mounted   yes      -
zroot/var               mounted   no       -
zroot/var/audit         mounted   yes      -
zroot/var/crash         mounted   yes      -
zroot/var/log           mounted   yes      -
zroot/var/mail          mounted   yes      -
zroot/var/tmp           mounted   yes      -
zroot_usb               mounted   no       -
zroot_usb/ROOT          mounted   no       -
zroot_usb/ROOT/default    mounted   no       -
zroot_usb/tmp            mounted   yes      -
zroot_usb/usr            mounted   no       -
zroot_usb/usr/home       mounted   yes      -
zroot_usb/usr/ports       mounted   yes      -
zroot_usb/usr/src         mounted   yes      -
zroot_usb/var            mounted   no       -
zroot_usb/var/audit       mounted   yes      -
zroot_usb/var/crash       mounted   yes      -
zroot_usb/var/log         mounted   yes      -
zroot_usb/var/mail        mounted   yes      -
zroot_usb/var/tmp        mounted   yes      -

Do you have any idea how to prevent the system to auto-import this pool 
on startup ? I still need the pool to be auto-imported when booting from 
the USB disk kernel.


Apart from this issue, I am quite satisfied with this setup : if someone 
were to steal my box they would not be able to decrypt the drive. Yet, 
it is still possible to replace the USB key with a malicious one 
recording the password, but this is not really part of my threat model. 
Secure boot might be able to mitigate this attack but from what I 
understand it is not yet production ready for FreeBSD.

Please note that I am no FreeBSD expert, and everything written are 
assumptions based from what I understand of the documentation, feel free 
to correct me if I misunderstood something.

On 25/11/2019 16:18, Evilham wrote:
> On dl., nov. 25 2019, Paul Florence via freebsd-questions wrote:
>
>> Hello everyone,
>>
>> I am currently running a home-made server with 12.0-RELEASE-p10 using
>> full disk geli encryption. When I boot the server, I first have to type
>> a password to decrypt the whole system.
>>
>> However, my ISP is having some power issues and in the last few weeks I
>> had to go there quite a few times to type a passphrase.
>>
>> I would like now to be able to enter my passphrase over the network.
>>
>> Would the following boot process be possible ?
>>
>> 1. First boot from an unencrypted kernel from a USB stick.
>>
>> 2. Then start an SSH server.
>>
>> 3. Input my passphrase over an ssh terminal.
>>
>> 4. Use the provided passphrase as the geli secret to boot the OS from
>> the disk
>>
>> If no, has anyone had to deal with this kind of problem ? If so, what
>> kind of strategy did you decide to use ?
>>
>> Thanks,
>
>
> Hi Paul,
>
> I'm don't think what you mention works as it is, but is close enough 
> to what I've done and does work:
>
> I hope you are aware of the security downsides of doing this, I think 
> it does look like the kind of trade-off you need.
>
> - There is an unencrypted FreeBSD (caveat: kernel must match that  of 
> the encrypted system, care when upgrading)
> - System boots into that unencrypted FreeBSD
> - I access that unencrypted system over SSH
> - Encrypted system is unlocked
> - reboot -r is used to boot into that system (man reboot explains 
>  that quite well)
>
> I use ZFS and a simple unlock script that is at the end of this 
> message (the unencrypted pool is called "init" as opposed to "zroot"), 
> but you should be able to do sth similar with e.g. UFS (man reboot has 
> a very basic example).
>
> Also: I do think this use-case could be made easier but haven't tried 
> to hack into the installer (yet). Apparently I am not alone, see the 
> feedback bits towards the end of the episode: https://www.bsdnow.tv/319
>
> Hope this helps, cheers.
> -- Evilham
>
>
> #!/bin/sh
>
> # Setup variables
> partition="ada0p4"
> zfs_pool="zroot"
>
> # Unlock encrypted system
> geli attach ${partition} || exit
>
> # Import pool without mounting only if needed.
> # If pool is already imported, this does nothing.
> zpool status ${zfs_pool} > /dev/null 2>&1 || zpool import -Nf -R /mnt 
> ${zfs_pool}
>
> # Get bootfs
> bootfs=$(zpool get -H -o value bootfs ${zfs_pool})
>
> # See FreeBSD bug 210721
> zpool export ${zfs_pool}
>
> # Setup root file system
> echo
> kenv "vfs.root.mountfrom=zfs:${bootfs}"
> echo
>
> # Reboot into decrypted system
> reboot -r


More information about the freebsd-questions mailing list