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.
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
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.
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.
They cannot access those files unless they can login into the booted
system which requires your password. If they start the system from external
media to avoid needing your password then
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.
macOS on hardware with T2 securing the encryption
key likewise still requires a user to authenticate themselves with a
passphrase.
I don't know about macOS, but AFAIK Android does something similar to Windows
where your data will be encrypted even if you don't set a user pin.
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.
True, but it still leaks the size and some other metadata.
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 ?
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.
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.
We really should be able to do better here, even without hibernation
like tricks, but this would require someone to sit down, analyze
the bottlenecks and then try to address them. I would love to spend
some time on this, but unfortunately I do not have time for this.
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?)
Except for mail and printer spool their is not a lot of leaks
in /var AFAIK. mail-spool is not used on a Workstation install, printer
spool is an interesting problem.
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).
We could swap to a file in the users homedir, there really is no need for
swap before login, unless the system has so little RAM it is not going
to be useful anyways.
###
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.
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.
Regards,
Hans
_______________________________________________
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
