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. > 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. 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 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 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. The bootloader, kernel, initramfs, /usr definitely need to be trusted (implies a need for integrity and authenticity). It's likely that /etc /var and ~/ need to be trusted. 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. 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? The performance impact of LUKS-on-loop files is negligible. I'm not certain about fscrypt's impact. But these are also further considerations. > > 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. -- 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
