On 12/7/21 10:39, Zbigniew Jędrzejewski-Szmek wrote:
If available, use the TPM2 to additionally tie the password to local hardware. If the user is removed, also remove that password from that storage. During boot, if it is necessary to authenticate before the root file system has been mounted, allow admin users to log in using the credentials that were stored previously.Is this being worked on? Do you have any references?Latest systemd versions have been getting some support for the low-level parts, i.e. the low-level encrypted-secret storage. But we're missing the upper parts, i.e. how to actually use and update the passwords. I didn't even mention this, because we don't have a comprehensive story yet.
A scenario that wasn't mentioned here yet is using a disk from a
failed system: either moving it to another system, or even simply
accessing the data. If the credentials (including the LUKS
encryption key/password) are protected by TPM2, it may effectively
prevent any further access. It would be useful if any such new
scheme avoided that.
In enterprise system, there usually is a backup decryption key,
accessible to the enterprise admins. I am not sure what would be
appropriate for single-user systems: some sort of install-time
rescue passphrase [1] perhaps, that the user would write down and
safely store [2]?
[2] conveniently stored next to the rubber hose so that the
attackers could forgo its use and type the rescue passphrase
themselves. https://xkcd.com/538/
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
