Hi,
On 06-12-18 19:32, Chris Murphy wrote:
On Thu, Dec 6, 2018 at 3:13 AM Javier Martinez Canillas
<javierm@xxxxxxxxxx> wrote:
<snip>
This is a two part question I think. First is the measurements and since the
BitLocker seals against a PCR state when booting with the Windows bootloader
this means that we can't chain-load Windows from grub2 since the measurements
would be different and prevent BitLocker to unlock the encrypted disk.
So for this case Windows has to be booted using the EFI firmware and having a
separate boot entry. This is my understanding at least, I don't have a Windows
installation to test.
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.
This is not the same as an unencrypted volume at all, the disk will only
unlock *when booted from the disk*. So you cannot simply mount the disk in
another machine, or boot from external media and still access the disk.
I'm not saying this is 100% safe, but it certainly is a lot safer then
unencrypted data and makes all kind of simple attacks impossible.
Regards,
Hans
_______________________________________________
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
