Re: strawman proposal: homed directories for users

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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).
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.

So, if you have a mobile device (like e.g. a Laptop), I don't think that
using JUST homed (even with SecureBoot) would be enough anyway.


Regards

Kilian Hanich
--
_______________________________________________
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux