On Tue, 2024-10-08 at 17:57 +0200, Lennart Poettering wrote: > 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. Here I was talking specifically about the case of a multi-boot system. In general it is not practical for large deployments to manually carry around all user data and allow mounting of the home on multiple systems. So it is by definition a "single user system", even though you can have multiple user drives, sorry for the confusion. > > > I see a few issues with security that needs to be addressed. > > Like what? Please be explicit, otherwise smells like FUD. Keep in mind my perspective is one of large deployments, not single system cared for by their own admin, so do not take my comment to the simple single-user case. > 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. You can lock a laptop disk via TPM and similar with clevis/tang as well, w/o tying it to a single user, how you do it depends on what your constraints are. > 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. > > 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? SSSD/IPA only accept users from the domain they are bound to via the keytab on the disk, all the data is authenticated that way, then stored locally. The assumption is that the disk where the cache is stored is encrypted of course. > > 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). I do not understand what you mean with this comment, in a domain all UIDs are consistent, that said you can also do local assignment in theory, it just is rarely a good idea (NFS doe snot support that, it is the externalities of network protocols assuming consistent IDs that force our hand in default configurations). > > > 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. Ok, so this already means that Fedora would need 2 different behaviors in the single user vs laptop in a domain configuration. That is an important thing to point out. > > 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. So that is another use case that you need to know in advance before installation, how hard it is to "convert" the system if you made the incorrect choice? > 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. It is not from a different time, it is from a different use case. In general you expect full disk encryption on corporate/centrally managed machines, not per-user encryption, unless you can escrow per- user encryption credentials, which I do not think systemd-homed is well positioned to do currently. > 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.) Thanks, this conversation confirms that we need a more broad security analysis and requirement discussion before any change in default can be considered, and buy in from the installer people if multiple different options end up needing to be provided. Simo. -- Simo Sorce Distinguished Engineer RHEL Crypto Team Red Hat, Inc -- _______________________________________________ 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
