On Mi, 09.10.24 11:12, Simo Sorce (simo@xxxxxxxxxx) wrote: > > 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. I am pretty sure secure systems should lock down everything: the per-system stuff locked to a local TPM, and the per-user stuff locked to a password or FIDO2 token or so owned by the user. I'd suggest to avoid the tpm stuff in clevis/tang btw, the stuff systemd does natively is a ton more advanced, i.e. encrypts TPM communication on the bus, has a sane story around PCR updates and so on. > > 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. Right. homed's model is a lot stricter there, we generally require offline security, i.e. the user records themselves are protected cryptographically, we never rely on some storage hopefully being trusted. (in particular as FDE as typically deployed on linux doesn't even authenticate the data at all, strictly speaking, even though people assume it does) > > > 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). This was again a reference to the fact that IPA folks aren't willing to restrict their allocations to some reasonable UID range, as mentoined elsewhere in this thread. Let me emphasize again, right now, the UID range IPA takes possession of collides on Fedora currently with: 1. classic UNIX users created via /etc/passwd adduser, i.e. shadow-utils and stuff. As mentioned elsewhre, logind.defs says this range goes to 60K, but IPA already starts before that. 2. special Linux UIDs 65535, 65534 2. dynamic service users allocated via DynamicUser=1 in systemd unit files 3. systemd-homed users (and more...) > > > 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? You can just copy out the files/chown them and add a classic UNIX user record if you wish. > > 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. I am pretty sure you want both, as mentioned: encryption of system data to the TPM, and user data to a personal credential. 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
