On Tue, Apr 28, 2020 at 1:52 PM Simo Sorce <simo@xxxxxxxxxx> wrote: > > On Tue, 2020-04-28 at 13:18 -0600, Chris Murphy wrote: > > 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. Upstream dmcrypt folks don't seem to like this. https://www.saout.de/pipermail/dm-crypt/2019-December/006290.html https://www.saout.de/pipermail/dm-crypt/2019-December/006295.html In that thread, there is a rejection of the very idea that (disk) encryption by default is a good or necessary thing. It unquestionably does add complexity, and therefore risk to user data. I suspect Anaconda folks won't want to support something upstream argues against, and doesn't officially support. There could be good reasons to go in a different direction than upstream advise, but there's probably a reasonably higher burden on advocates proposing such a plan. > > > 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 default status isn't part of the suitability assessment. I assert it must be suitable to be a default, which does show my bias: defaults are often perceived by most users as either recommended or safe, and I try to assess defaults from that perspective. > > 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. Probably true. > > 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. Right. And even if the long term goal is to account for Evil Maid, doesn't disqualify an implementation that only protects the stolen/lost laptop case. Building on prior advancements is acceptable, no different than with UEFI Secure Boot. > > 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. Trust is a continuum and it can be misplaced. So whether I trust a thing or not reflects more on me than the actual trustworthiness of the thing under discussion. That's maybe the best concise definition I can muster without verbose examples... Insofar as /usr: If it is encrypted (cryptsetup LUKS default) I trust that the confidentiality provided essentially makes it impossible for an attacker to inject malware - this loss of precision needed for such an attack by encryption gives it an illusory sense of integrity that it really doesn't have. Therefore I do not trust that it's free from either incidental corruption or a malicious attack on the ciphertext that could e.g. cause something to crash or result in weird behavior. If in addition to LUKS encryption, I were to add minimal integrity checking via dm-integrity or Btrfs CRC-32C for everything, I trust there's no incidental corruption; I'm not totally certain whether I can really trust there's been no malicious attack. I can't assess it, but suspect it depends on the particular attack (skill of the attacker) and versions of many things. Whereas if it were not encrypted, but employed either dm-verity, dm-integrity or Btrfs using hmac:sha256, I would trust the contents against either incidental or malicious attack - so long as I trust the HMAC hasn't escaped my control. As for /var and /etc, were they to be encrypted using fscrypt+ext4, I can trust only that detailed user usage data (that which exists in file extents) isn't being leaked. But the metadata isn't encrypted, so could some skilled attacker look at the unencrypted /etc /var metadata and infer that I use a VPN even if they can't acquire keys? I don't know, I can't assess it. I also can't assess the demarcation line of acceptable exposure, what should Fedora strive to mitigate by default in particular considering that the default now is not to encrypt. Is it sane to consider an incremental approach? I think it's in part necessary to consider and assess. And also I wonder whether it's possible, and if we're better off putting more effort into not leaking such things into /etc /var in the first place. Could they reliably be put somewhere in ~/ instead, and then default to LUKS encryption for ~/ ? > > 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. I respect that there can be use cases where it's not acceptable to expose what operating system is being used. But it's not a case being considered. > > 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. This is consistent with what the working group has learned so far. > > 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. Yep. It's a good idea. -- 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
