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