3️⃣5️⃣ Here's the 35th post highlighting key new features of the current v257 release of systemd. #systemd257
systemd-homed is the user/home area managed service of systemd. It's designed to provide very secure home directory management on Linux OSes. One fundamental idea is that the user's provided unlock credential (password, FIDO token, PKCS11 token) are actually what the encryption key for the home directory is derived of. This is of course fundamentally different from traditional UNIX, …
=> More informations about this toot | More toots from pid_eins@mastodon.social
…where user data is at best encrypted with a per-system/admin encryption key, and access control to user accounts is just something that protects the ability to log in, but not the user's data.
In continuation of this security focused theme, user records managed by systemd-homed are cryptographically signed: only accounts properly signed by a system-owned key pair can actually log into a specific system.
That means two things: first of all the user's data is protected by the user's…
=> More informations about this toot | More toots from pid_eins@mastodon.social
…security credentials, but the user's account is protected by the system's security credentials: only the system can make changes to the user's account, i.e. change passwords, change resource settings, change real names and so on, because only the system can then sign the resulting new user record correctly.
Effectively this so far meant: to make any changes like this required admin consent: simply changing your account's password would require providing the admin's password too.
=> More informations about this toot | More toots from pid_eins@mastodon.social
With v257 this logic is relaxed: there's now a an allowlist of user record fields that the user may modify without admin consent, or in other words: any fields on that allowlist may be changed in a user record, and then passed to systemd-homed which will update the record and sign it properly – without requiring root privs. (Any fields outside of that allowlist may not be modified however).
Now, which fields shall be changeable without admin consent should itself be subject to admin's consent.
=> More informations about this toot | More toots from pid_eins@mastodon.social
To make sure that user records are truly portable between systems we opted for encoding the allowlist as part of the user record itself: when preparing a new user record the admin can precisely encode in it which of the fields a user is allowed to modify on their own.
Allowing unpriv modification of user records is not a new concept of course, classic UNIX allows this via "passwd" after all. But I think the flexibility of including the allowlist in the user record itself is particularly nice.
=> More informations about this toot | More toots from pid_eins@mastodon.social
@pid_eins is there some plan to integrate this with freeipa/sssd or will this remain system-local?
=> More informations about this toot | More toots from r3pek@r3pek.org
@r3pek @pid_eins
Maybe it's time to consider alternatives to sssd/ipa for centralised authentication and policy management?
Don't get me wrong! IPA is great and sssd does a decent job integration with a central management. But in many aspects it feels like an "add-on" on top of the ststem-local instead of being fully integrated on the system. Sure, IPA/sssd works today, but it has limitations and could be better integrated on many levels.
=> More informations about this toot | More toots from dazo@infosec.exchange
@dazo not saying it doesn't have it's problems, but it does it's job well (and there aren't really alternatives?).
I mean.... users are identified and authenticated at a central place. everything on the system that uses pam knows about the users. Nothing fails on my use case here... 🤷♂️
@pid_eins
=> More informations about this toot | More toots from r3pek@r3pek.org
@r3pek @pid_eins
Have you tried digging up and configuring how to do 2FA with anything more advanced than TOTP/HOTP? .... It feels very fragile and certainly does little integration with the systemd stack. So if enrolling IPA with FIDO and systemd-homed with encrypted $HOME .... I fear for my data.
Plus this needs to be carefully rolled out based on target distributions for the hosts users need to access. Plus some kind of policies to handle various security capabilities of each host.
=> More informations about this toot | More toots from dazo@infosec.exchange
@dazo not really. It's on the TODO list 😉
but IPA+FIDO+EncryptedHome is a really corner case IMHO. I'd much rather have the $home somewhere on the network and be automounted after login (of on a subfolder of $home).
@pid_eins
=> More informations about this toot | More toots from r3pek@r3pek.org
text/geminiThis content has been proxied by September (ba2dc).