On Wed, Aug 21, 2019 at 2:22 PM Przemek Klosowski via devel
<devel(a)lists.fedoraproject.org> wrote:
I think Fedora should optimize
for laptops/desktops, so if we had to chose one default I would vote for
sleep, or shutdown if sleep was not available.
The default could be predicated on systemd chassis attribute.
but it's less secure---the decryption password hashes (**) have
to be
present on the media. Bitlocker in TPM mode has the secrets locked in
the TPM, and as an added benefit uses the 'enterprise' authorization
scheme, with revocation, recovery keys, single logon (no separate
decryption and login credentials), etc. You wrote that bitlocker
'configured properly ... simply shows a prompt forever', but I think
that the current best practice is to use TPM, in which case the system
proceeds to the login prompt, and the full decryption is only done after
user authentication. I think that's how FileVault in MacOS works, and
perhaps Linux is also heading this way.
Filevault 1 was disk image based. Filevault 2 is either Core Storage
or APFS based, they didn't change the name. I'm loose on the details,
but my vague understanding with Core Storage is method of unlocking
the encrypted LV (they had something functionally like dmcrypt, but it
was an attribute of the volume, Logical Volume Families, and managed
by the logical volume manager, i.e. Core Storage) was done by the
bootloader. That entire interface for user selection and entering your
passphrase, I'm pretty sure was all before any XNU boot had taken
place; macOS has a kernel extentions cache file but not an initramfs
like thing.
The difficulty on Linux with this approach, as I understand it, really
is getting all the possible input types, hardware and languages,
supported in either the bootloader or in the initramfs. And the trend
has been making pre-boot and initramfs environments less complicated.
Filevault 2 when APFS is used, I haven't investigated how it works
even generally, but I know APFS makes it cheap to create Volumes that
share a file system pool, and volumes can be encrypted or not. So they
could plausibly do a minimalist boot to a login window using files in
an unencrypted volume, and from there unlock the main volume and
switch root. I see on my own mac with APFS that there is an
unencrypted boot volume and an encrypted main volume where the bulk of
the OS, apps, and user data is located; but APFS also supports single
key and multi key encryption, and also per volume and per file
encryption.
Anyway, the Fedora Workstation working group has this as an issue
being explored by a subgroup very soon, and make recommendations back
to the working group. So there will be a lot more discussion about
this in the near future.
https://pagure.io/fedora-workstation/issue/82
https://meetbot.fedoraproject.org/fedora-meeting-2/2019-08-19/workstation...
--
Chris Murphy