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 @dazo @pid_eins I've been working on something not entirely unlike SSDD/IPA for a while now, using userdbd. The experience of working with systemd-userdbd via varlink has been pretty good, all said.
There's a few things missing though (I've been thinking about a PAM-over-Varlink protocol, for example)
=> More informations about this toot | More toots from erincandescent@erincandescent.net
@r3pek @dazo @pid_eins one thing that's a little unfortunate (though it hasn't come up in my needs yet) is that there's no way for me to reuse the home directory mounting/decryption logic from homed. But I'm not even sure if that's something that could even practically be reused
=> More informations about this toot | More toots from erincandescent@erincandescent.net
@erincandescent @dazo @r3pek my understanding is that sssd/ipa folks really don't think user data should be encrypted by user credential, but instead should be owned by the entreprise they are in, i.e. the don't buy homed's idea that users own their data, not organizations.
=> More informations about this toot | More toots from pid_eins@mastodon.social
@pid_eins they do support plugins, or at least i remember reading something about it (isn't that how cockpit works when integrated into freeipa?)
could that be a possibility for expansion?
user-data is another can of worms this days.... GDPR and stuff 🤷♂️
@erincandescent @dazo
=> More informations about this toot | More toots from r3pek@r3pek.org
@r3pek @pid_eins @erincandescent
I have my doubts. IPA has a solid fundament in the enterprise policy management mindset. In this scope, where a host is enrolled into IPA, the enterprise owns all the data, including all your personal data.
I fear this will require a large refactoring of the IPA architecture - to account for not having access to all account data in clear text at any time.
=> More informations about this toot | More toots from dazo@infosec.exchange
text/geminiThis content has been proxied by September (3851b).