Date: Tue, 18 Jan 2022 13:53:14 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 261306] Geli rc.d script does not support insertion of USB devices containing a keyfile. Message-ID: <bug-261306-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D261306 Bug ID: 261306 Summary: Geli rc.d script does not support insertion of USB devices containing a keyfile. Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: misc Assignee: bugs@FreeBSD.org Reporter: james@elstone.net Created attachment 231128 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D231128&action= =3Dedit patch for /etc/rc.d/geli to enable waiting and very early mounting of a USB storage device Outline - =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The script /etc/rc.d/geli does not support usb flash devices which either h= ave a hardware pin or are inserted during system boot process. This will allow users to have a removable USB device with keyfiles on to be used by the _user-land_ geli service that is not stored in /boot/ or another fixed disk on the system. This would allow the security of key management t= o be increased. The attached (git) patch provides a: 1) Pause for a defined number of seconds for the user to insert a predefined USB storage device. 2) Early mounting of an inserted USB device that contains a keyfile, but ju= st for geli. This can then be used in the geli_*_flags rcvar as a referenced k= ey file. The device is unmounted after Geli has used it, so not to impact later boot stages. Detail - =3D=3D=3D=3D=3D=3D=3D=3D This is a change to the /etc/rc.d/geli script, see attached diff. Both the EFI loader and kernel boot process resets all USB devices as they = are enumerated, as expected. If you are using a USB storage device that require= s a manual pin to be entered before it is available (i.e. hardware pin entered = on the USB storage device, e.g. iStorage DataShur) it is very difficult to get= a consistent boot without it erroring and entering single user mode. This change would also allow the late (prior to geli being called in the in= it process) insertion of any USB storage device for keyfile storage purposes. = This would allow a practical end-user mechanism that would increase the system security as the keyfile is stored on an external and physically separate de= vice of the users choice. Each time the USB bus is enumerated the USB device is reset and in effect a= pin based storage device is locked by this, as expected, but cannot be used due= to the time it takes to enter a pin on the device.=20 Example Usage - =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D /etc/rc.conf: geli_secdevusb_device=3D"/dev/gpt/security_key" geli_secdevusb_path=3D"/security_key" geli_secdevusb_wait=3D"120" geli_secdevusb_options=3D"" where: - "/dev/gpt/security_key" is a gpart label for a UFS partition on a memory stick, or any other removable device that can be inserted and then mounted using mount(8). - /security_keys is a directory that the USB device should be mounted on, a= nd can be referenced in the geli_*_flags variables in rc.conf. Setup for testing - =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D da0 is a fixed disk being encrypted, and da1 is a removable usb storage dev= ice contianing the keyfile. Warning: These test instructions are destructive to= the example devices, read first and adapt for your system; also make sure you h= ave backed up any critical data encrypted or not for da0 and da1. #create security key mkdir /security_key gpart create -s gpt /dev/da1 gpart add -a 1m -freebsd-ufs -l security_key /dev/da1 newfs /dev/da1p1 mount /dev/gpt/security_key /security_key mkdir /security_key/geli dd if=3D/dev/random of=3D/security_key/geli/DISK-ID0.key bs=3D64 count=3D1 #create encrypted volume with geli gpart create -s gpt /dev/da0 gpart add -a 1m -freebsd-zfs -l DISK-ID0 /dev/da0 geli init -s 4096 -B none -K "/security_keys/DISK-ID0.key" "/dev/gpt/DISK-I= D0" #update rc.conf variables sysrc geli_secdevusb_device=3D"/dev/gpt/security_key" sysrc geli_secdevusb_path=3D"/security_key" sysrc geli_secdevusb_wait=3D"120" sysrc geli_secdevusb_options=3D"" sysrc geli_gpt_DISK_ID0_flags=3D"-k /security_key/geli/DISK-ID0.key" #remove USB device that is da1 and reboot reboot #When prompted inset USB storage device that is da1 and enter the passphrase used with the geli init command above. RC Vars - =3D=3D=3D=3D=3D=3D=3D=3D=3D There are four new RC vars needed: sysrc geli_secdevusb_device=3D"" sysrc geli_secdevusb_path=3D"" sysrc geli_secdevusb_wait=3D"" sysrc geli_secdevusb_options=3D"" The default rcvars should be as follows to prevent the code from operating unless the user requires: geli_secdevusb_device=3D"" geli_secdevusb_path=3D"" geli_secdevusb_wait=3D"0" geli_secdevusb_options=3D"" Reasoning =3D=3D=3D=3D=3D=3D=3D=3D=3D I maybe reinventing the wheel here, but have explored the /boot/loader.conf vars geli_*_name, and geli_*_flags in /etc/rc.conf, but does not cover this= use case. Most of the examples online refer to putting the keys into /boot/ whi= ch is not a strong security practice IMO as you are storing the key and the encrypted data in the same machine. I think this covers a use case not currently supported by FreeBSD, and is an improvement to have removable keyfiles on a usb device, and would like to h= elp=20 other users to reduce their security footprint. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-261306-227>