On Mo, 07.10.24 12:59, Simo Sorce (simo@xxxxxxxxxx) wrote: > > The homed approach would make other things possible too. For example, > > sharing of /home in dual-boot scenarios. Right now a manual setup > > needs to be done, and login details need to be propagated each time, > > but with homed, dual-boot and reinstall are very similar scenarios, > > so if we get one to work, we get the other one for free. > > > > Zbyszek > > The homed approach can work only in cases where you basically have only > one user and all the OSs use the same approach. Hmm, what? No, homed works fine with multiple users. I have multiple users right now on my local system. > I see a few issues with security that needs to be addressed. Like what? Please be explicit, otherwise smells like FUD. I am pretty sure the security model is a lot cleaner than anything the sssd/IPA world would do, because we lock disk encryption to user provided credentials, FIDO2/PKCS#11 and such, and can suspend the home dir's encryption key on suspend. It should be a massive step up in security. Hence I am very curious where you think the security issues are? > What happens if I plug a disk into a laptop that sports a "homed" > directory, will the laptop suddenly allow a stranger to just login into > the machine? No. systemd-homed user records are signed. User records not signed by a recognized key are not accepted. I am not sure if sssd/IPA stuff has something similar? is there any cryptographic integration protection part of its user database? > What happens if there are conflicts of uid or gid ? In the systemd-homed world uid/gid are assigned when the home dir is first activated on a host. A free UID/GID is allocated then, and idmapping is used to ensure that the home dir appears owned by the right user (or in other words: on disk all files are owned by user/group "nobody", only the idmapping makes them appear owned by the user locally). This UID/GID binding is persisted on the local system, but can differ between systems. > Will it now allow this other user to access files and directories that > should be reserved to other users? No. At moment the binding of the home dir to the local host is established a free UID/GID is taken from a very specific range. This should make collisions unlikely. (though not impossible, because this system of course relies on everyone being equally careful before taking possession of a UID/GID, and as I understand the IPA world is systematically opposed to that, which is sad, but nothing I can change). > What happen if you want to change the user to be a corporate directory > provided one? Enterprisey IPA/SSSD/AD/LDAP style stuff really is not in focus for systemd-homed, as mentioned many times. > Can you configure autologin for those uses cases (like kiosks or a home > entertainment system) where that makes sense to do ? No you cannot, the security model relies on unlock keys to be provided before the home directory is accessible. It's a strength of the model, not a weakness, that user data is actually protected by the provided user authentication credentials. As I understand the IPA/sssd model is a lot more traditional there, and does not consider the user's data as something to protect? I'd call that highly problematic, but I guess it's from a different time. Note that systemd-homed is *one* provider of user accounts, but it's not to be the only one. The way I see it there are always multiple in play: 1. static system users configured via /etc/passwd, /etc/shadow & co. 2. dynamic system users allocated via systemd's DynamicUser=1 3. systemd-homed ones for high-security, local users 4. traditional unix users configured via /etc/passwd, /etc/shadow & co. 5. sssd provided ones for networked enterprise accounts Of course, item 1 and 4 are the same pretty much, just differ in UID range. In your kiosk usecase always opt for option 4 I think. > Is this tied to a specific file system type? homed has various backends. If you use the LUKS backend you really want to use btrfs, because it allows both online grow & shrink. Other file systems are a lot more limited, but also supported for the LUKS backend. But there's also a plain directory backend where we make almost any restrictions (at weaker security of course). And there's an fscrypt backend (which only requires an fs that supports fscrypt), at mid-level security (because fscrypt protectes file contents, not metadata, unlike the LUKS/dm-crypt backend which protects everything.) Lennart -- Lennart Poettering, Berlin -- _______________________________________________ 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
