From nobody Tue Jan 18 13:53:14 2022 X-Original-To: bugs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 823CC196B806 for ; Tue, 18 Jan 2022 13:53:14 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JdVbZ133pz3wNm for ; Tue, 18 Jan 2022 13:53:14 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id ED957224AC for ; Tue, 18 Jan 2022 13:53:13 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 20IDrD9A030298 for ; Tue, 18 Jan 2022 13:53:13 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 20IDrDoF030297 for bugs@FreeBSD.org; Tue, 18 Jan 2022 13:53:13 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f 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. Date: Tue, 18 Jan 2022 13:53:14 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: james@elstone.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Bug reports List-Archive: https://lists.freebsd.org/archives/freebsd-bugs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-bugs@freebsd.org MIME-Version: 1.0 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1642513994; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=xOa5/w82hJTnMLF+hupHa5+roggF4Cu0hdjd4TC/Ll4=; b=BGO4cNXPl/74XJfLoMPIGPg2xI0Lg29sc0ZfE/qw/upYR5woIjRUTlIpjgWntzqwMjqmGB rQrlkkuMjuXi9M+ChsOMBs7fVnl6sR2+bjbKreGwRVme8oP8KkUnf8brI8XHb4VNFNBmm4 e9DW0F6vWskjysOjq/p5xXm72P43buihVSPp7pagwnYKOkTktVkp/jCeMkXJkQtNf1MgeH 4VMeMd2fFGpESISHZ0YcLlukhJx+/B+VpfjaycMU6c7NE+NsNPeI06zw/LUviApbeEsPEp KLedH9nynWvg+aSnX+1PJiMKqQngMQRUtuQYZy9/e14ptNAsGCq5L+q4E7eU2A== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1642513994; a=rsa-sha256; cv=none; b=THiEicv0O5/45zr3lEEaMp5eG/EAJdi/e6FWiGN9BXqLM+78r6hbqnfCHBalohwY6W6lZw /Kj96+EON+esO1hKgW02SlVn+XtZUpb74Brn38fvESZxwrhFbdXY9Um/TpoqyHDA40K1rl OkBVVq03N2oj2wp/vLt2UCHV6Fbu9Sn7yzIpi8hu7eVvZTzhy/EZXgddDR2Lwg5ocsvSBV SkohSUrGR/5YjpbcqvPIp/oK+95x1Kt40eCkutHzKDu7SuKgNwPwNcGu/Dm12ISctLbyHM kahX+v/itQZhAqcMmqVcLosabKRIPvyuFstafkknJKpmpW3j1WHLR8L+hihGOQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N 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.=