I just posted a thread on discussion.fedoraproject.org:
https://discussion.fedoraproject.org/t/future-of-encryption-in-fedora/80397
to invite discussion of a requirements document and draft plan about what we might do for encrypting Fedora Workstation systems in the future. Please follow up there, but for convenience, the message is reproduced below:
For quite a while, the Workstation Working Group has had open tickets to improve the state of encryption in Fedora - and in particular get to the point where we can make the installer encrypt systems by default.
In order to move that forward, I’ve been working on a requirements document and draft plan. In very brief summary, the plan is:
This plan is dependent on the on-going Unified Kernel Image support, since currently Fedora uses unsigned initrds, and substituting the initrd would allow an attacker to bypass all encryption. It represents a big change where we go from having secure boot be something we spend a lot of effort on, but actually doesn’t do much, to something we’re depending on in a big way to provide an extra layer of security to the user.
I’d be interested in hearing, among other things:
* Are there requirements that the document doesn’t capture?
* Are there other threats that we should be trying to address?
* Is the focus on integrity a good idea?
* Do we actually need to separately encrypt home directories?
* Do we need to support a model where we bind the encryption key to the current kernel and initrd without having the combination signed by Fedora?
* Should we be more seriously considering systemd-homed? What advantages would we get by doing that?
Thanks for any feedback!
– Owen
https://discussion.fedoraproject.org/t/future-of-encryption-in-fedora/80397
to invite discussion of a requirements document and draft plan about what we might do for encrypting Fedora Workstation systems in the future. Please follow up there, but for convenience, the message is reproduced below:
====
In order to move that forward, I’ve been working on a requirements document and draft plan. In very brief summary, the plan is:
Use the upcoming btrfs fscrypt support to encrypt both the system
and home directories. The system by default will be encrypted with
an encryption key stored in the TPM and bound to the signatures
used to sign the bootloader/kernel/initrd, providing protection against
tampering, while home directories will be encrypted using the user’s login
password.
This plan is dependent on the on-going Unified Kernel Image support, since currently Fedora uses unsigned initrds, and substituting the initrd would allow an attacker to bypass all encryption. It represents a big change where we go from having secure boot be something we spend a lot of effort on, but actually doesn’t do much, to something we’re depending on in a big way to provide an extra layer of security to the user.
I’d be interested in hearing, among other things:
* Are there requirements that the document doesn’t capture?
* Are there other threats that we should be trying to address?
* Is the focus on integrity a good idea?
* Do we actually need to separately encrypt home directories?
* Do we need to support a model where we bind the encryption key to the current kernel and initrd without having the combination signed by Fedora?
* Should we be more seriously considering systemd-homed? What advantages would we get by doing that?
Thanks for any feedback!
– Owen
_______________________________________________ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
