Re: State of encrypted-almost-everything on ZFS in 2020
Le lun. 18 mai 20 à 22:52:22 +0200, Thomas Zander via freebsd-stable écrivait : > Hi, Hello, > > Yes, this has been supported in a few varieties for a few major versions now > > ... and it's a cool feature, no doubt! Unfortunately, it requires me > to supply a password via keyboard, as you explain below, so it does > not match my use case. And entering a password via keyboard is still affected by the problem of kbdmap (See PR 242349) ! -- Th. Thomas. signature.asc Description: PGP signature
Re: State of encrypted-almost-everything on ZFS in 2020
16.05.2020 16:51, Thomas Zander via freebsd-stable wrote:
> Hi,
>
> can the following be done these days?
> - Encrypted ZFS root pool on RAID-Z
> - Supply the key for the encrypted root pool during boot via USB thumb drive
> - No keyboard is attached to the machine
> - No /boot on the thumb drive, just the key
> - I don't mind if /boot is encrypted or not (the use case is not to
> protect against nation state attackers)
> - Bonus points if I can use bectl
>
> Every single posting regarding this topic I can find always comes down to
> either
> a) One needs /boot on the thumb drive, or
> b) One uses a keyboard and supplies a passphrase instead of a keyfile.
Note that root pool does not need to be original boot pool.
It is possible to share your disks between two different ZFS pools:
small first unencrypted boot pool that boots normally and starts plain shell
script
that reads the key from any storage you prefer to decrypt and attach
second encrypted pool. Then set vfs.root.mountfrom to second pool with kenv(1)
and use re-rooting (reboot -r) to re-start booting from now-available encrypted
pool.
This is how to share disks with GEOM_RAID:
1. Cut first N megabytes of each disk to form N-way mirror using "Promise"
on-disk volume label format:
graid label -S ${N}M Promise r0 RAID1 /dev/da0 /dev/da1 /dev/da2 ...
This gives you /dev/raid/r0 device, use it to create unencrypted non-redundant
ZFS boot pool,
as GEOM_RAID provides (mirrored) redundancy.
2. Allocate tail of each drive to set of SINGLE graid volumes:
graid label Promise r1 SINGLE /dev/da0
graid label Promise r2 SINGLE /dev/da1
graid label Promise r3 SINGLE /dev/da2
...
This gives you devices /dev/raid/r1, /dev/raid/r2 etc. Use them as vdevs to
create your encrypted RAID-Z.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: State of encrypted-almost-everything on ZFS in 2020
Hi, thank you for the quick response. I think I have a good overview of the state of affairs now, thanks! On Sat, 16 May 2020 at 18:46, Allan Jude wrote: > > - Encrypted ZFS root pool on RAID-Z > > Yes, this has been supported in a few varieties for a few major versions now ... and it's a cool feature, no doubt! Unfortunately, it requires me to supply a password via keyboard, as you explain below, so it does not match my use case. > > - Supply the key for the encrypted root pool during boot via USB thumb drive > > - No keyboard is attached to the machine > > - No /boot on the thumb drive, just the key > > This feature was never implemented for GELIBoot. Currently the bootstrap > code only supports a manually entered passphrase. Thanks for clarifying this! > > - I don't mind if /boot is encrypted or not (the use case is not to > > protect against nation state attackers) > > If you use an unencrypted /boot (as opposed to GELIBoot), then I think > you might be able to use the thumb drive approach to hold the key. You > would need to set the correct loader.conf variables to read the key from > the thumbdrive. It might be easier if the key is written raw into a > partition than if it is on a filesystem since it won't be mounted at > that point. Okay, that sounds like not all hope is lost :-) So, something like this might work IIUC: - Have a small (e.g. 16kB) GPT partition on the USB thumb drive, using geom_label, accessible as /dev/label/foo - dd the key onto /dev/label/foo - Have this in loader.conf: geli_label_crypted_keyfile0_load="YES" geli_label_crypted_keyfile0_type="label/crypted:geli_keyfile0" geli_label_crypted_keyfile0_name="/dev/label/foo" > > - Bonus points if I can use bectl > > However, if you use an unencrypted /boot, then you lose bectl and boot > environments, since the kernel is not part of the root filesystem. That's okay, having. bectl would be nice, but secondary. > > I'd like to have a setup where essentially nothing is stored on the > > USB drive except the keyfile. > > I proposed some ideas on how to do this at BSDCan a few years ago, but > have never had the time or financial backing to develop the feature. I am sorry to hear that. One would expect this was not an unconventional use case. Thanks so much for the response, I'll play with the raw partition idea over the next few days and will report back how it went. Best regards Riggs ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
State of encrypted-almost-everything on ZFS in 2020
Hi, can the following be done these days? - Encrypted ZFS root pool on RAID-Z - Supply the key for the encrypted root pool during boot via USB thumb drive - No keyboard is attached to the machine - No /boot on the thumb drive, just the key - I don't mind if /boot is encrypted or not (the use case is not to protect against nation state attackers) - Bonus points if I can use bectl Every single posting regarding this topic I can find always comes down to either a) One needs /boot on the thumb drive, or b) One uses a keyboard and supplies a passphrase instead of a keyfile. I'd like to have a setup where essentially nothing is stored on the USB drive except the keyfile. Thank you and best regards Riggs ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
