On Mon, Dec 3, 2018 at 5:48 PM Chris Murphy lists@colorremedies.com wrote:

...

...

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?

I just miswrote there and said "bootloader password prompt" when I meant "initrd password prompt". I don't think anybody is interested in encrypting /boot (ensuring the integrity of the early boot sequence using PCR measurement, etc, is a different question.)

Thanks for all your other feedback, Chris. There are a certainly a lot of aspects to work through! - I don't think it's going to take us 5 years to get something useful, but any plan will certainly have short-term and long-term parts to it.

Regards, Owen

On Tue, Dec 4, 2018 at 2:19 PM, Ray Strode rstrode@redhat.com wrote:

Right now if you have autologin enabled, then GDM will use the password you typed at the luks screen to unlock the gnome-keyring in the user's session.

Well this requires 3.30.2 and rawhide and F29 are both on 3.30.1 still. But it should work soon, yes.

??? my error GDM is still on 3.30.1, gdm-3.30.1-2.fc29.x86_64.

On Tue, 2018-12-04 at 15:30 -0600, mcatanzaro@gnome.org wrote:

On Tue, Dec 4, 2018 at 2:19 PM, Ray Strode rstrode@redhat.com wrote:

...

Right now if you have autologin enabled, then GDM will use the password you typed at the luks screen to unlock the gnome-keyring in the user's session.

Well this requires 3.30.2 and rawhide and F29 are both on 3.30.1 still. But it should work soon, yes. _______________________________________________ desktop mailing list -- desktop@lists.fedoraproject.org To unsubscribe send an email to desktop-leave@lists.fedoraproject.org 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@lists.fedoraproject.or...

Hi,

On 03-12-18 23:47, Chris Murphy wrote:

...

Log: https://meetbot.fedoraproject.org/fedora-meeting-2/2018-12-03/workstation.20...

...

• 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.

Hi, On Wed, Dec 5, 2018 at 3:21 PM Hans de Goede hdegoede@redhat.com wrote:

FWIW I think that putting the entirety of gdm in the initrd is a bad idea,

I don't think anyone proposed that (unless I'm missing something).

If this is reference to the autologin thing I mentioned above, that doesn't require GDM being in the initrd.

systemd puts the disk password in the kernel keyring and gdm just grabs it during login time.

--Ray

On Wed, Dec 5, 2018 at 1:20 PM Hans de Goede hdegoede@redhat.com wrote:

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).

Is this broadly supportable? a. Macs don't have TPMs b. Windows laptops have TPM 2.0 which I can't get to work on Linux (works fine on Windows 10). https://bugzilla.kernel.org/show_bug.cgi?id=185631 c. Can a TMP be reliably shared by both Windows and Fedora in a dual boot configuration?

Whatever we're going to do by default needs to be broadly supported. And also we need to define broadly supported. Is leaving 20% behind acceptable? What's the fallback for them, and then why is that fallback not good enough for everybody else by default?

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.

I don't understand. If merely booting unlocks the encrypted volume, the main point of FDE is obviated, which is securing data at rest. They can't modify any of the binaries in the measured boot chain, but they can read/copy, modify, and delete files I care about. I must be missing something. Even Bitlocker requires a user PIN at least to unlock the volume. macOS on hardware with T2 securing the encryption key likewise still requires a user to authenticate themselves with a passphrase.

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.

fscrypt does encrypt filenames.

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.

I can't imagine it has to be that big. macOS has base "chooser" window UI, with smooth rendering and animations, used in three contexts: as the boot manager built into the firmware, as the login window built into the bootloader when FileVault 2 is enabled, and the login window when FileVault 2 is not enabled.

Meanwhile, on my 2016 HP laptop, Windows 10 cold boots to a login window in 5 seconds flat. Fedora on that same laptop takes 17 seconds to get to a login window. Startup finished in 1.346s (kernel) + 2.484s (initrd) + 10.928s (userspace) = 14.759s

That's about 9MB/s reads from an NVMe drive that does file system scrubs at 1400MB/s. So why is the kernel/initrd load so much slower? Firmware? Why is Windows so fast? Are they not depending on the firmware to load their image and instead use better code in their bootloader? I know they're not processing a boot like we are, they're in effect restoring a hibernation image based on system state at the login window, so they just read in a memory dump. Fedora gets hammered by an inherently disk and cpu intensive boot process because it's interpretive, hence 11s userspace.

I don't know how much user data leaks in /var and what can be done about that (is it a bug, and the application should use ~/.var instead?) But I'm willing to bet there's some leakage in swap, so whatever plan should decide to either drop swap entire or configure it to be encrypted with a random key during startup (which of course makes it incompatible with suspend-to-disk).

On Thu, Dec 6, 2018 at 1:32 AM Hans de Goede hdegoede@redhat.com wrote:

Hi,

On 05-12-18 23:58, Chris Murphy wrote:

...

On Wed, Dec 5, 2018 at 1:20 PM Hans de Goede hdegoede@redhat.com wrote:

...

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).

Is this broadly supportable? a. Macs don't have TPMs

I'm not sure if that is true for older macs, and getting Linux to run on a Mac has been getting harder and harder for newer models anyways.

I have a Macbook Pro from 2011, it does not have a TPM. The TPM macs predate that, there may have only been a couple of models that had it, and I'm not even sure they were TPM 1.2. Apple never used the TPM, so I don't know if they're discoverable by Linux.

...

b. Windows laptops have TPM 2.0 which I can't get to work on Linux (works fine on Windows 10). https://bugzilla.kernel.org/show_bug.cgi?id=185631

The work by Javier and Peter is targetting TPM2.0

That's roughly anything 3 years old or newer. Is this half the Fedora user base?

Also, there are no TPM bindings in LUKS1, so is this work using LUKS2?

...

c. Can a TMP be reliably shared by both Windows and Fedora in a dual boot configuration?

Javier, Peter, can you answer this please ?

...

Whatever we're going to do by default needs to be broadly supported. And also we need to define broadly supported. Is leaving 20% behind acceptable? What's the fallback for them, and then why is that fallback not good enough for everybody else by default?

The fallback would be to allow then to set a diskcrypt password which will get asked for by plymouth from the initrd just as we have today.

What we do today, if the user opts into FDE, is ask for two passphrases: plymouth and gdm. And when that user changes their passphrase through GNOME UI, is only the latter passphrase is changed. That is not acceptable UI/UX as a default in 2010 let alone 2019.

...

I must be missing something. Even Bitlocker requires a user PIN at least to unlock the volume.

That is not true I've a Windows 10 tablet lying next to me which has an encrypted bitlocker volume which automatically unlocks at boot (it boots directly to the Windows desktop) but as soon as I turn of secure boot, it will no longer boot asking for the bitlocker recovery password and also Linux cannot read it.

Cute. Seems utterly pointless to encrypt. Sure, if it's a 40 pound desktop or a pile of server drives, and the only attack you care to thwart is drive theft, you're protected. But a laptop or tablet? Useless. Perhaps worse than useless because the user thinks they're somehow protected.

For me on Windows 10 Pro, it wants a PIN, but then Windows has myriad policies for authenticating that result in very different UI/UX (local authentication vs outlook vs AD) and those also differ depending on branding: Home vs Pro vs Enterprise.

Also, Bitlocker, in quite a few configurations, actually uses eDrive (Microsoft branding of TCG Opal self-encrypting drives). I have no idea whether or how we can support those configurations, but I expect they're going to become more prevalent despite recent discoveries about SED vulnerabilities.

...

...

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.

I can't imagine it has to be that big. macOS has base "chooser" window UI, with smooth rendering and animations, used in three contexts: as the boot manager built into the firmware, as the login window built into the bootloader when FileVault 2 is enabled, and the login window when FileVault 2 is not enabled.

At least the bootmanager only shows Icons for the OS, so no internationalization problems, also no input method issues.

I do not know about the other parts, does FileVault2 do fully internationalized passwords ?

I don't know. It's a difficult problem so I rather doubt it. I expect it only works reliably with a fixed language, key map, and keyboard; as soon as you change any of those three things, probably all bets are off. BUT, macOS does always out of the box create a personal recovery key with a fixed encoding (looks like it's ASCII), optionally displayed and optionally backed up to the cloud, and an optional institutional recovery key based on X.509 cert is also possible. So if you end up in a situation where you're locked out of your data by passphrase, and have no idea what combination of hardware and software settings were used at the time of passphrase creation, you can still get to your data and reset the passphrase.

Anyways this is really comparing apples to oranges, Apple has full vertical integration and has a R&D budget in the 100s millions with more developers working on a single part of a piece of the stack then we have working on the entire stack. If you give us such a budget and/or such an amount of manpower I'm sure we can come up with something really nice too.

The point of bringing up macOS as an example, is that a login dialog cannot be that big if it's being baked into a 2MiB bootloader, and a subset of it is baked into firmware. I'm pushing back on the idea an early login dialog necessarily makes the initrd unacceptably large, there are examples of minuscule login dialogs.

One important thing to keep in mind here which people seem to be forgetting is that security is always about striking a balance between usability and security an absolute secure system will also be absolutely unusable. With Fedora we add a third dimenstion of having a clearly limited amount of manpower to implement whatever we come up with.

Yep, which is why I think the plan as stated is already too complicated. Double encryption? Both FDE and fscrypt? What are the performance implications?

Every layer adds a ton more complexity to implementation, testing, documentation, expert user understanding so they can troubleshoot and explain it, maintaining it down the road, accounting for it when doing upgrades, and so on.

IMHO doing full disk encryption with the key managed by the TPM2, combined with ecryptfs encryption for the homedir strikes the best balance in all 3 dimensions. Note that even then there still is quite a bit of work to do before we get there.

Which is why I think the WG needs a 5 year plan. i.e. not that it will take 5 years. But to understand the sequence of getting there, the end goal needs to clear articulation.