> > The second part is the key management. Clevis currently expects that the key > > hierarchies are not password protected. This is because asking the user for a > > password would defeat the purpose of automatically unlocking the LUKS volume. > > Why bother encrypting anything if it's going to be automatically > unlocked just by booting? If the login window is a sufficient barrier > to exfiltrating and modifying user files on an unlocked volume, then > it's a sufficient barrier for an unencrypted volume because it is in > effect a plaintext volume, automatically without a passphrase, merely > when powered on. The encryption is tied to the device, if the storage is removed from the device it fails to be useful. It could also be tied into a network service like tang [1]. For a end user laptop I agree this doesn't always make much sense but for something like IoT where the device is often not directly interacted with by users but have data encrypted at rest is critical it provides a means of doing it without requiring user interaction, like most security components there's always trade offs. [1] https://github.com/latchset/tang _______________________________________________ desktop mailing list -- desktop@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to desktop-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/desktop@xxxxxxxxxxxxxxxxxxxxxxx
