feat: added Fido2/Yubi Key Setup with ujust

[thedragonkeeper]

This addition creates a ujust script that allows easy config of a fido/yubi key on to an encrypted disk.
it provides options to:

• enrol a new key
• manually assign device and luks volume if you have multiple encrypted disks
• set the key has the default method. This allows the key to be the only auth method needed and password as fallback. Great for steamdeck use if fido key doesnt need a passphrase as it doesnt yet have a onscreen keyboard for this
• rebuilds initramfs with fido module - its an option incase you want to do thjis for multiple volumes, it doesnt need rebuilding again.
  and it updates /etc/crypttab with fido option for selected volume if needed

[HikariKnight]

some problems here

• We use Semantic PR so commit messages should follow: https://www.conventionalcommits.org/en/v1.0.0/
• Recipe should be named configure-fido2 following the current naming convention used throughout ujust
• Your current implementation uses rpm-ostree initramfs and you will wipe out any initramfs arguments that has previously been set on the system (be it nvidia modules or other hwe related initramfs stuff), you should really consider putting it into a dracut.conf file inside /etc/dracut.conf.d

[HikariKnight]

just syntax checker fails here due to whitespace at the end of the comment

[HikariKnight]

unsure if this is needed if dracut modules are already enabled, but will have to double check if main images have dracut modules enabled by default and test it myself. (will be able to check that tomorrow)

if they are not enabled or if you need to issue a rebuild then what you will have to do (thanks to how rpm-ostree initramfs functions) get the current initramfs arguments (with quotes in the right places for each --arg=) from rpm-ostree status -b | grep Initramfs | sed -E 's/\s+Initramfs: ('"'"'|)(.+)("'"'"'|")/\2"/' and rebuild the previously used rpm-ostree initramfs command to avoid wiping out the current args.

[thedragonkeeper]

it seems that running this at this point makes it rebuild anyway, but if you have a better method im happy to change it. from my testing (on a bazzite build) a rebuild was needed for this module to work as intended.

and it seems that, according to rpm-ostree, --arg appends the line to the dracut arguments and --enable Enable regenerating initramfs locally using dracut

it shouldnt be wiping anything out when doing a rebuild afaik each deployment seems to retain the initramfs args from the last

[m2Giles]

Only Bazzite enables initramfs by default.

Additionally unsure if the force_drivers is necessary for fido. The dracutmodule should suffice for pulling it in. At least it does that for tpm2.

Should we have these security devices just specified in a file in /usr/lib/dracut.conf.d. if they are already present, we would only have to enable initramfs generation, do the key enrollment, and specify the fido device as a karg.

Key enrollment would be the only item that needs elevated privileges.

[HikariKnight]

it seems that running this at this point makes it rebuild anyway, but if you have a better method im happy to change it. from my testing (on a bazzite build) a rebuild was needed for this module to work as intended.

and it seems that, according to rpm-ostree, --arg appends the line to the dracut arguments and --enable Enable regenerating initramfs locally using dracut

it shouldnt be wiping anything out when doing a rebuild afaik each deployment seems to retain the initramfs args from the last

from experience if you happen to lets say have --arg="-I /etc/crypttab /etc/modprobe.d/nvidia.conf" as the initramfs arguments and you run rpm-ostree initramfs --enable, rpm-ostree initramfs in its infinite wisdom will remove --arg="-I /etc/crypttab /etc/modprobe.d/nvidia.conf" as it was never supplied and the nvidia.conf modprobe never gets added and the nvidia driver does not get loaded. we had to work around this problem in bazzite which is why we have our own rebuilder script that gets triggered by sudo touch /etc/bazzite/initramfs/rebuild however it is currently not compatible with other images.

[HikariKnight]

Only Bazzite enables initramfs by default.

Additionally unsure if the force_drivers is necessary for fido. The dracutmodule should suffice for pulling it in. At least it does that for tpm2.

Should we have these security devices just specified in a file in /usr/lib/dracut.conf.d. if they are already present, we would only have to enable initramfs generation, do the key enrollment, and specify the fido device as a karg.

Key enrollment would be the only item that needs elevated privileges.

i like the sound of this idea, i should also just look into the idea of a initramfs-rebuild that issues a rebuild, nothing else specifically for situations like this. However ideally everything would use initramfs-etc but that would require us to get the other bits sorted out first.

[m2Giles]

Since this has been written, Bazzite and Bluefin/Aurora have started shipping an initramfs built as part of the build pipeline.

This reduces the need for the initramfs components, but is still needed on our main images.

[HikariKnight]

With the new initramfs changes done, i think this looks good enough now, sorry for the delay @thedragonkeeper

[storopoli]

This can be rebased and use the new tips that were merged in #266.

[storopoli]

• set the key has the default method. This allows the key to be the only auth method needed and password as fallback.

Does this means that even if I set a PIN in my FIDO key, it will bypass it and unlock LUKS without the need to insert the PIN? (dangerous 😱)

[thedragonkeeper]

• set the key has the default method. This allows the key to be the only auth method needed and password as fallback.

Does this means that even if I set a PIN in my FIDO key, it will bypass it and unlock LUKS without the need to insert the PIN? (dangerous 😱)

this means that the password for LUKS doesnt need to be used.
as you can set the priortiy or even disable it.
this isnt anything to do with the pin for the fido.

i dont use a pin on my fido, the reason being that i only use this on a steam deck and that currently doesnt have a good way to input text, it would need an onscreen keyboard added, so if it asked me for a pin id need to plug in a keyboard, which isnt practical.