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