Talk:Universal 2nd Factor

Data-at-rest encryption with LUKS

I propose the following change to the Data-at-rest encryption with LUKS section. Torxed (talk) 08:59, 18 May 2022 (UTC)

I don't see a point to the warning. It is not possible to unlock the root volume from /etc/crypttab on real root. Also the (rd.)luks. vs crypttab issue is out of scope and duplicates dm-crypt/System configuration#Using sd-encrypt hook. -- nl6720 (talk) 10:37, 18 May 2022 (UTC)

Fair points, but I'm not sure it's clear tho that having a /etc/crypttab entry would cause issues. At least that is news to me, since with sd-encrypt from my understanding systemd is used to load all the encrypted volumes. To quote dm-crypt/System configuration#crypttab "crypttab processing at boot time is made by the systemd-cryptsetup-generator automatically.", this eludes that any filesystem can be mounted. Also /etc/crypttab.initramfs is mentioned to be baked into initramfs which indicates that perhaps instructions on how to unlock root can be made. /etc/crypttab.initramfs is mentioned frequently and I think it would make it more clear and remove potential issues if there was some mention of these behaviors. The place and wording might be wrong, but it would be a benefit to mention it. I spent a couple of days on this issue and this is something I felt would have cleared up some of the issue. But if that's not the general consensus so be it. But in such a case I would like to argue strongly that the mention of libfido2 stays, because that was highly unclear. Torxed (talk) 11:21, 18 May 2022 (UTC)

There's no issue with having libfido2 installation instructions, but those do not warrant a note. Simply instruct to install the package, see Help:Style#Package management instructions.

/etc/crypttab is parsed after switch root, but the root volume (and also the swap volume when using hibernation) must be unlocked and mounted before that, i.e. in the initramfs phase. The rd.luks and luks kernel parameters are an alternative to crypttab, that's why they conflict in certain configurations.

IMHO it would be best to leave only the systemd-cryptenroll commands here and place all crypttab and rd.luks stuff in dm-crypt/System configuration. The same applies to Trusted Platform Module#systemd-cryptenroll.

-- nl6720 (talk) 12:04, 18 May 2022 (UTC)

Draft

Since version 248, systemd can be use to unlock a LUKS partition using a FIDO2 key.

First, you will need to setup your /etc/crypttab file, or customize your initramfs if you wish to unlock your root partition. The full procedure is similar to the use of a TPM chip for unlocking. See Trusted Platform Module#systemd-cryptenroll.

Note: libfido2 is required before a new initramfs is generated.

Warning: If you intend to unlock the root partition, /etc/crypttab might cause systemd-cryptsetup@.service to fail. In which case setting rd.luks.* or luks.* kernel options and omitting /etc/crypttab is required.

Note: tpm2-device kernel option will override fido2-device kernel option. Use one or the other.

To register the key, you will need to use the systemd-cryptenroll utility. First, run the following command to list your detected keys:

$ systemd-cryptenroll --fido2-device=list

Then you can register the key in a LUKS slot, specifying the path to the FIDO2 device, or using the auto value :

$ systemd-cryptenroll --fido2-device=/path/to/fido2_device /dev/sdX

Then proceed to generate a new initramfs with libfido2 support unless already done.

Passwordless sudo

If used as sudo authentication if feel that storing the u2f credentials in the home directory this weakens security. If a malicious actor gains access to your account but for some reason don't know the password he can't change the user password but change files in you home directory.

Therefore I would recommend to store the credentials in a secure authfile.

$ sudo pamu2fcfg -o pam://hostname -i pam://hostname > /etc/u2f_mappings
$ sudo chmod 600 /etc/u2f_mappings

/etc/pam.d/sudo

auth            required      pam_u2f.so pam_u2f.so authfile=/etc/u2f_mappings login=pam://hostname appid=pam://hostname 

see: https://developers.yubico.com/pam-u2f/ Central Authorization Mapping

The mapping file will be opened and parsed as root therefore you can restrict all access to root.

Also I would strongly recommend to configure userpresence, userverification and pinverification in /etc/pam.d/sudo. The yubico documentation just mentions that if omitted it falls back to the authenticator’s default behaviour which could be none of those. At least adding userpresence will need to touch the yubikey for confirmation. Otherwise any script could execute sudo as if with no sudo password set. Malaclypse (talk) 00:46, 15 December 2023 (UTC)