Hi,
On 03-12-18 23:47, Chris Murphy wrote:
Log:
https://meetbot.fedoraproject.org/fedora-meeting-2/2018-12-03/workstation.2018-12-03-14.05.log.html
* Default disk partitioning layout for Workstation (mcatanzaro,
14:11:08)
* ACTION: otaylor form a subgroup to look at LUKS issue -- WG is not
taking any specific actions until subgroup recommends something
(stickster, 14:41:48)
* LVM and /home partioning issues will depend on subgroup report
recommendation for LUKS (stickster, 14:44:00)
- If only /home is encrypted, it requires a separate filesystem/volume
for /home.
- The main purpose of dropping LVM is to address the small root
running out of space with flatpak installations in
https://pagure.io/fedora-workstation/issue/54
- If separate home, then issue 54 needs a different solution. e.g.
increase root size above 50G. However, some people will have workflows
where they run out of space on root or home, no matter what we pick,
just due to mismatching expectations. The problem will be more common
for the dual boot and small physical device cases (many laptops have
128G SSD drives in their base configuration); and in particular when
both uses cases happen simultaneously.
Alternatives:
a. Combined root and home, encrypt that volume (everything).
b. Combined root and home, do not encrypt. For what it's worth,
Windows 10 and macOS 10.13 do not encrypt anything by default.
c. LVM thin provisioning doesn't really solve anything out of the box,
because right now Anaconda won't permit over provisioning, therefore
we still can run into the problem in issue 54. Only users with
esoteric knowledge will know or be able to explain how to
overprovision root and/or home volumes, to avoid or fix the problem in
issue 54.
d. ext4 encryption by default in only /home
Regarding a.) with LUKS/LUKS2. The convention is to have a single
device encryption passphrase shared among users, and this passphrase
is different than the user login passphrase. I think this is a half
assed UI/UX, having to enter two passphrases. It's archaic, and not
worth any additional effort. People who manually tick the box in
Anacond to encrypt, pretty much know what they're signing up for,
which is this cockamamie UI/UX that doesn't exist on any other
platform. A better approach requires:
- Anaconda needs to know how to use a single passphrase for both LUKS
and user login and how to associate user with LUKS key slot.
- Likely a format change for /etc/passwd or some other file, to
associate user login and LUKS key slot; while a passphrase could be
cached and LUKS cryptsetup will use any offered without reference to a
user, we need to know which slot to wipe when changing passphrases,
therefore it has to be tracked.
- GDM needs to know how to use single passphrases to both login and
unlock volume.
- If full disk encryption, rather than home only encryption, plymouth
or GDM login or something like it needs to become available in early
boot, i.e. part of the initramfs. This should present a user login,
capture credential one time, and both unlock the encrypted volume and
then login the user in one shot.
Regarding d.) both f2fs and ext4 support file level encryption via
fscrypt, and is used by newer Android devices by default. This can be
done on a directory or file specific basis. And the file encryption
passprase can be tied to the user login passprase. Anaconda and GDM
work is implied to support anything related to fscrypt.
Both a.) and d.) have the liability that the passphrase encoding
method needs to somehow be made consistent and reliable no matter what
language or keyboard layout is chosen when setting or changing that
phrase; because as mentioned, nuking people's data by effectively
locking their data behind an unknown or unknowable passphrase
encoding, is bad.
Worst case scenario is to at least inform the user that the selected
language and/or keyboard can't be used to unlock the encrypted data;
and also inform the user which language and/or keyboard they need to
switch to, to make it possible, and to give them the UI necessary to
do that.
14:31:51 <otaylor> ryanlerch: I think it's definitely possible (finicky, but sometimes you have to do finicky things...) to determine whether a password is possible to type at the bootloader password prompt
Literally GRUB2 asking for a passphrase, implies /boot is encrypted.
I'm not sure that's supportable. Anaconda has various limitations
where it will require a separate boot volume. What are the advantages
to encrypting boot?
disadvantages:
- there is presently no GRUB2 GUI, it's really clunky in appearance
- it implies the user will have to do dual passphrase entry, once at
the bootloader and again when logging in, this is also clunky
Maybe a ~5 year view and plan are needed to better understand the
problems, solutions, and what resources are available.
Javier and Peter (added to the Cc) have been working on making
full-disk encryption storing the secret in the tpm work.
This is what Windows with bitlocker does and what most smart phones
do now (more or less).
The idea here is (Javier / Peter please correct me if I'm wrong) that
the firmware send a hash of itself to the tpm and a hash of the bootloader,
and the bootloader sends a hash of the kernel + initrd to the tpm.
The tpm hashes all these hashes together and when the kernel wants to
access the encrypted root filesystem, it asks the tpm for the key,
if all the hashes together match what the tpm expects it will give
the key. This means that even if someone steals the entire laptop
he cannot modify anything, the rootfs is crypted so it cannot be
modified without the key and everything which comes before it is
hashed so it cannot be replaced either. This leaves the attacker
essentially stuck at the gdm login prompt. An advanced adversary
will certainly be able to find a way around this, but it is a good
level of security to start with.
This gives us full disk encryption without the need to ask for a
diskcrypt password from plymouth (in the initrd) or from grub at all.
Thus avoiding all downsides wrt keymaps and the lack of other advanced
input methods like having e.g. a pinyin input method. This also avoids
other internationalization issues like font-rendering of non western
scripts.
On top of this we could do what Ubuntu does and encrypt home directories
at the filesystme level using the password the user uses to login to
protect/unlock the key for this. The downside of this is that all the file
metadata (filename, size) is not encrypted, but the contents is and
this would come *on top of* the full disk encryption using the tpm.
The advantage of using filesystem level per file encryption this way
is that it avoids the diskspace problem entirely.
To me this by far seems the sanest method to deal with this, users who
do not deem this safe enough can always add an old fashioned diskcrypt
password on top as we already support now a days.
Regards,
Hans
p.s.
FWIW I think that putting the entirety of gdm in the initrd is a bad
idea, esp. since we rely on firmware calls to load the initrd and
some firmwares are very stupid doing this sector by sector making
initrd loading quite slow already making the initrd huge will make
this problem much worse.
_______________________________________________
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
