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 withsd-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 intoinitramfs
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)
- Fair points, but I'm not sure it's clear tho that having a
- 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. Therd.luks
andluks
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.
initramfs
is generated./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.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)
s/hostname/localhost/g ?
Does hostname necessary? Looks like it can be replaced with localhost Avi9526 (talk) 16:39, 20 August 2024 (UTC)