Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Dec 6, 2019 at 8:28 AM Marius Schwarz <fedoradev@xxxxxxxxxxxx> wrote:
>
> Am 05.12.19 um 23:02 schrieb Chris Murphy:
>
> read "LUKS by default"
>
> https://pagure.io/fedora-workstation/issue/82
>
> If you read the whole thing, you should come to understand why the
> initial agreement to implement full disk encryption was suspended, and
> also that this issue has a history proving it is being taken seriously
> and deliberately.
>
>
> First paragraph:

I suggested reading the entire thread, not pulling it apart. If you
want to do that please start a new thread.


> "Figure out intersection with current work to use the TPM to allow booting to GDM without entering the password."
>
> Means, if someone steals the device, he can boot a system. Even if we assume that the systemcode is safe and there is no way to interrupt the bootprocess, we are now able to attack the login, which will be much easier than the encryption key, which is massive compared to the passwords in use.
>
> So, NO: no booting without someone entering something.
>
> Besides the already spoken out point, that not all users want encryption, because it takes into consideration to manage an additional passcode,
> the entire discussion here was about "encrypt everything, or nothing, because partly does not help at all".

This is not correct. /home only encryption is part of that discussion:
this includes a single home volume mounted at /home with a single LUKS
DEK, one or more KEKs (user passphrase stored in LUKS keyslot), as
well as individual separately encrypted ~/ per user.

Your position as stated is absurd because it assumes a compromised
system is inevitable in one case but not the other. Case 1 is ~/ only
is encrypted, and your assertion is that this does *not help at all*
improve user data confidentiality on the basis that without / and swap
being encrypted that ~/ is vulnerable to a targeted attack via / or
swap being compromised. Case 2 is present day Fedora "full disk
encryption" which does not lock down the bootloader,  /boot volume is
not encrypted, and thus the initramfs is vulnerable to a targeted
attack which could be used to deploy a key logger or whatever you're
worried about in Case 1.

It is not valid to use different goal posts for the different cases
under comparison. Right now Fedora's default is no encryption at all,
and the way you've worded your assertion, you propose user data would
become more susceptible to attack or exfiltration if ~/ alone is
encrypted. That must be hyperbole so I insist that you do a better job
of constraining your assertions to things we can all agree on.

Otherwise you are invited to describe exactly how encrypted ~/ alone
makes the user worse off than today's default, which is encrypting
nothing. Because that is the more valid comparison: what we are doing
now, versus what we should do as a next logical step. The next logical
step is not the final step, it probably will be a baby step. So try
not to get carried away with unrealistic demands for which resources
don't exist. Whatever happens requires a plan.



-- 
Chris Murphy
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux