On Wed, Oct 9, 2024 at 2:19 PM Kilian Hanich via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
Am 09.10.24 um 17:12 schrieb Simo Sorce:
>> Hence I am very curious where you think the security issues are?
> Sorry, I did not mean in any way to imply there are open security issue
> with systemd-homed, I meant only that we need to analyze the security
> assumptions in the context of making this a default and ensure we
> protect what we mean to protect, and address the risk profile we
> define.
I want to add something here. FDE has two main purposes for mobile
devices (e.g. a Laptop):
1. prevent a thief of getting the data after the device is stolen
2. prevent an attacker installing or exchanging installed software with
a version of their own (e.g. installing a keylogger) while the owner
isn't looking
Number 1 is also taken care of by homed (if it does the encryption), if
you only have your data in your home directory (my father for example
does not, he has an extra disk with his most important data mounted to
~/data, yes, mounted INTO his home directory).
FDE alone obviously can't take care of number 2 alone, but needs at
least something like SecureBoot and a protected BIOS (or similar). But
if that's a given, it's pretty darn hard for attacker to do so (although
obviously not impossible, but I don't think there's a system where you
can say that).
There's a caveat here - SecureBoot as currently implemented in Fedora does not give any protection against this type of attack, because the initrd - that prompts for your password - is not protected by SecureBoot.
The rough plan that we came up a couple of years ago (https://discussion.fedoraproject.org/t/future-of-encryption-in-fedora-desktop-variants/80397/19) was:
- Encrypt everything but home directories using a TPM-sealed encryption key - and *no password*
- Encrypt the home directories with user credentials (I wasn't sure at that point whether homed made sense, but there's been progress in GNOME integration, so it's more attractive these days)
One of the things that has kept us from making progress here is that progress on Unified Kernel Images has been slow, and there's no firm plan about how to extend it to handle desktop/laptop installations.
With homed on the other hand, I don't think that would work. As far as I
understand it, things like SecureBoot only work up until including the
kernel, but not for e.g. the init system, or homed itself. So an
attacker could take the disk, mount it on one of his devices, exchange
some system software with their own version (after all, it's not checked
that this is an ok binary) and then put the disk back into the device.
Yes, but that's true of FDE as well, unless the initrd is protected by secure boot. (*)
- Owen
(*) Direct protection of the initrd would be refusing to run the initrd unless it was signed by an enrolled key. This is very hard to achieve - it requires the user to have a BIOS password, etc. This is why the plan was indirect protection - any initrd could run, but unless it was signed correctly, it would be unable to load the system partition encryption key from the TPM.
-- _______________________________________________ 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
