On Friday, December 6, 2019 8:27:32 AM MST Marius Schwarz wrote: > Am 05.12.19 um 23:02 schrieb Chris Murphy: > > read "LUKS by default" > > https://pagure.io/fedora-workstation/issue/82 > > > > If you read the whole thing, you should come to understand why the > > initial agreement to implement full disk encryption was suspended, and > > also that this issue has a history proving it is being taken seriously > > and deliberately. > > First paragraph: > > "Figure out the scope - presumably workstation only since servers and > cloud VMs need to boot unattended. But perhaps not desktop VMs?" > > VM's in the masses are not installed via anaconda. > One VM is installed via anaconda, and the rest is a clone of the image > produced by the install and later setup. > Thats how cloudservers are born ;) That's how some people do it, but most "cloudservers" are built automatically from a kickstart. > If the vm is paravirtualized ( i.e. Xen ) you can't even enter a > plymouth password to unlock a drive. Well, you can. Why wouldn't you be able to? > Even if the VM would be encrypted and running in QEMU, which would use up > a lot of cpu power, it's still not safe. Yeah, shared resources throw security out the window. > Same as with the partly encryption of homedirs in homed is > insecure, only encrypting the vm is insecure too, due to the > mastersystem being able to intercept anything send to the vm. If someome > tampered the host, the guest encryption is null and void. If the host is > encrypted, there is no longer a need to encrypt the vm. Well, VMs are not generally stored on the drive of the host OS, except in one- offs and on consumer desktops/laptops. > "Figure out intersection with current work to use the TPM to allow > booting to GDM without entering the password." > > Means, if someone steals the device, he can boot a system. Even if we > assume that the systemcode is safe and there is no way to interrupt the > bootprocess, we are now able to attack the login, which will be much > easier than the encryption key, which is massive compared to the > passwords in use. Yeah, there are a contingent here that believe that it's not necessary to ensure the person booting the device is actually authorized to access the content of the laptop.. And, because it makes things "easy" for the user, I get the feeling something like this will wind up getting implemented. Oh well. > So, NO: no booting without someone entering something. > > Besides the already spoken out point, that not all users want > encryption, because it takes into consideration to manage an additional > passcode, > the entire discussion here was about "encrypt everything, or nothing, > because partly does not help at all". > > BTW: > > "catanzaro commented a year ago Also: tablets need an OSK to be able to > decrypt the disk." > > Add: grub needs an OSK too, or how do you select the matching kernel? Adding an on-screen keyboard to GRUB would be even more difficult than adding it to the initramfs environment. GRUB simply cannot support that. It'd have to be rewritten from the ground up to support that sort of thing. > Skipping the rest of it, the simple solution to the problem discussed > would be to ask for encryption more prominent, with a tiny bit of > background for the user. > > Before i forget, there can be multiply passwords for a luks key, so > there is no need to wipe a disk, just have a good OSK with all installed > and or system selected languages at hand. Are you suggesting "translating", for lack of a better term, the passphrase between all available keyboard layouts? That would decrease the effective security of your system considerably.. -- John M. Harris, Jr. Splentity _______________________________________________ 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
