On Tue, 2020-04-28 at 13:18 -0600, Chris Murphy wrote: > On Tue, Apr 28, 2020 at 10:37 AM Simo Sorce <simo@xxxxxxxxxx> wrote: > > I have a hard time commenting over the next 2 becuse it seem like the > > probelm is not just technical, but there is no clear vision of whether > > there is one and only one solution or if multiple solutions need to be > > considered. > > The short term is necessarily limited to the existing functionality of > the installer. Shall "encrypt my data" be enabled by default or not? > Seems like a good idea, but there are knock on effects that have > various deleterious effects. Is it worth enabling only in the short > term? Or should it be left as is, and focus on the long term design > and planning? > > There are few examples of encryption enabled by default in the desktop > world. Presently, that seems to be only Pop!_OS. > > On mobile devices this is more common. But even more common than > encryption is trustworthiness (integrity and authenticity of the > image; and statelessness, with the option to do a reset). > > Long term, many solutions need to be considered. And not only > technical, but their impact on release engineering. What is the goal ? If the goal is just making it easy later, you could encrypt with a null default passphrase that the system uses automatically and do not ask the user. > > I personally prefer to encrypt the whole disk, because the machine I > > care for encrypting is a laptop that can potentially be > > stolen/displaced easily. However I do not care at all that there are > > two different step (encryption password and separate account password), > > and in fact I prefer to keep them separate because I join the laptop to > > a separate IDM system so the account password is not managed by the > > laptop. > > Custom ways of account management aren't going away. The scope of this > topic is: Fedora Workstation defaults. It just informs that the default depends on the environment, there is a big difference on what the reasonable defaults are depending on use: shared workstation vs personal desktop vs personal laptop vs corporate laptop, etc... > Today's full disk encryption (except /boot) paradigm is long term > untenable. The negatives are the sole reason why they're not used by > default, even in a short term context. The fact something is not the default does not mean it is untenable. > The working group's evaluation so far, shows that alternatives are > only available in the long term. Hence the (re) evaluation of whether > encryption by default is such a good thing, that it should be enabled > by default for Fedora 33, despite the limitations of the current > design. I do not see how you can enable full disk encryption by default unless you accept that you are forcing user to use 2 passwords. If that is unacceptable (and it probably is) then it can't be a default. > > I would love to have TPM integration, but just using TPM is useless for > > my use case, because if they steal my laptop they also get my TPM > > chip. TPM is cool only as an additional component but alone it is > > somewhat useless. If clevis is used then you can compose the TPM *and* > > a passphrase (or other item like a tang server or a phone/bluetooth > > beacon). > > TPM is in the long term category. Support for it in dmcrypt/cryptsetup > doesn't have an ETA. There's other integration work needed too. And I > don't think it's seriously considered for protecting user data, for > the reason you mention. Rather, it's considered for encrypting system > data. > > It's not decided whether system data should be encrypted by default, > or made only opt in, and if so how to encrypt them. The working group > is (perhaps painfully) aware that there are many options. Again it really depends on the threat model, if the evil made is the issue, then, unless you have a signed integrity model you have to encrypt the system as well. If the threat model is just stolen/lost laptop/disk then encrypting the user data only would be sufficient. > The bootloader, kernel, initramfs, /usr definitely need to be trusted > (implies a need for integrity and authenticity). You cannot trust /usr w/o integrity checks. > It's likely that /etc > /var and ~/ need to be trusted. I guess you need to define what you mean with trust on second thought, as I do not think I share the same definition with you. > The bootloader, kernel, initramfs, and > /usr definitely do not need to be private, though it doesn't hurt to > do so, there's nothing secret about them. Whereas ~/ definitely needs > an option to be encrypted, possibly by default. Whether something is confidential or not is a matter of threat model again. But I do agree that in the common case you might consider "distribution provided"-binaries as non-confidential and be left only integrity but not confidentiality protected. > Depending on whether and how /home or each ~/ are encrypted, there are > considerations like user flatpaks and possible duplication and > excessive space consumption. If they are LUKS-on-loop files as > systemd-homed proposes, there are file system resize considerations > when additional users are added, or when users later added actually > have more space requirements. This is substantially more secure than > fscrypt+ext4, but is fscrypt adequate for Workstation users by > default? fscrypt is probably never a good default. it is a very weak model to be used as a last resort if you failed to use a proper encryption layer at install time. > The performance impact of LUKS-on-loop files is negligible. I'm not > certain about fscrypt's impact. But these are also further > considerations. I really think you should make some use cases and see what fits best, then you can select those you want to consider default. It will make reasoning about what works best as default easier. > > So in the end I do not believe you can come up with a single schema for > > "workstation" unless you narrow down the scope of workstation to a > > smaller set of use cases to the exclusion of the others. > > This is the dilemma. It necessarily needs a single schema, there is > only one default. Customizations aren't going away. Then chose what you think is the common user for Fedora workstation and use that as the persona to target and see what they would think best suite their needs? Sounds to me I'll keep changing defaults for the forseable future :-) Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc _______________________________________________ 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
