On Thu, Dec 6, 2018 at 1:32 AM Hans de Goede <hdegoede@xxxxxxxxxx> wrote: > > Hi, > > On 05-12-18 23:58, Chris Murphy wrote: > > On Wed, Dec 5, 2018 at 1:20 PM Hans de Goede <hdegoede@xxxxxxxxxx> 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. -- Chris Murphy _______________________________________________ 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
