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
@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
@erincandescent @dazo @r3pek urks. Redoing PAM with modern tech is one hell of a can of worms.
=> More informations about this toot | More toots from pid_eins@mastodon.social
@pid_eins @dazo @r3pek Indeed. I'm probably not going to end up with something that replicates every feature, just the ones the authentication/account management system needs
=> More informations about this toot | More toots from erincandescent@erincandescent.net
@pid_eins @dazo @r3pek (the basic idea is to extend my existing PAM module to connect directly to the service specified in the user record and forward on the PAM call outs, and to do so in a sufficiently generic way it could become a common library. Also, to port this logic to sd_varlink. If I can make something generic enough, it would be nice to have something that can be reusable infrastructure)
=> More informations about this toot | More toots from erincandescent@erincandescent.net
@erincandescent @dazo @r3pek I think we can consider just adding this logic to pam_systemd itself, but in some op-in fashion so that we can enable it for some userdb providers only.
=> More informations about this toot | More toots from pid_eins@mastodon.social
@pid_eins @dazo @r3pek once i’ve settled on an API I would certainly be interested in upstreaming things, especially if I can do so in a way generic which allows eliminating all of the systemd-homed specific logic inside of pam_systemd.
In terms of making it opt-in, what would you suggest? I was thinking of just connecting to the provider and attempting a call on a new interface, and if that fails remembering that & just doing the default/record-driven behaviour
=> More informations about this toot | More toots from erincandescent@erincandescent.net
@erincandescent @dazo @r3pek pam_systemd has nothing homed specific in it, it's entirely generic.
pam_systemd_home contains the homed specific stuff. But frankly I don't think you can move that into generic code, it implements a non-trivial protocol to request PINs, security token touching and so on. i.e. all that stuff necessary for fido2, pkcs11 and so on.
=> More informations about this toot | More toots from pid_eins@mastodon.social
@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
@pid_eins @erincandescent @r3pek
That's kinda the same wormhole Proton Mail went into when providing multi-user accounts, with an admin account overseeing more sub-accounts.
They ended up doing two modes for the sub-accounts, indicated by a "private" flag. Default is false, where a organisation key (accessible to all the admin accounts) would have access to decrypt account information (including e-mail content). All data is then encrypted by two public keys, essentially (the sub-account user's key + the organisation key).
In "private mode", only the sub-account user's key is used to encrypt the account data - making it impossible for the admin account to access any data in the sub-account it manages.
A similar model might be a reasonable middle-ground for ipa/sssd (or a replacement) with systemd-homed.
=> More informations about this toot | More toots from dazo@infosec.exchange
@r3pek integrate homed with freeipa/sssd? i don't think this makes much sense: homed owns its user records, and freeipa owns their user records. It doesn't really make sense to have multiple subsystems own them.
The way I always envisioned integration of freeipa/sssd to work is that they integrate with systemd-userdbd but not systemd-homed. Or in other words: sssd/freeipa would provide rich user records natively, and thus allow systemd to consume them, but it wouldn't be systemd…
=> More informations about this toot | More toots from pid_eins@mastodon.social
@r3pek … that provides them on sssd's behalf.
But freeipa/sssd folks have no interest/other priorities, apparently.
Personally I think a more distributed rather than centralized approach to user management is a good idea, which is why systemd-homed exists: it doesn't force you into a mode where a system is a member of a single organization, but instead allows logins from a set of organizations or to individual, independent accounts only.
=> More informations about this toot | More toots from pid_eins@mastodon.social
@pid_eins well... that's a management headache 😆
Can't think of a way to manage 100s (or even 1000s) of users on a distributed way and keeping things sane.
Works for a small use case, but when you get big, it doesn't...
=> More informations about this toot | More toots from r3pek@r3pek.org
@r3pek there's conceptually no reason why the homed approach would be more limited than the centralized approach, it's a superset if you so will. i.e. you can certainly have a centralized org that signs your user records and then just distribute the json files of the records as simple drop-in files to target system.
That said, tooling is shit for this ATM, it's not really the focus of our work.
=> More informations about this toot | More toots from pid_eins@mastodon.social
@pid_eins yeah.... conceptually it would work but nothing exists yet for the integration to work.
don't think i saw you (systemd team) ever touch sssd's code that's why i asked if there were plans to do it...
But I get your point 😉
=> More informations about this toot | More toots from r3pek@r3pek.org
@pid_eins well, yes. that makes sense. wouldn't actually be homed... 👍
=> More informations about this toot | More toots from r3pek@r3pek.org
@pid_eins I still fail to understand how these accounts are portable if they can only be used on the system that signed them.
=> More informations about this toot | More toots from nik@toot.teckids.org
@nik There are three options:
a mixture between 1 + 2 is also possible.
(tooling of all this is a bit manual currently, though)
=> More informations about this toot | More toots from pid_eins@mastodon.social
@pid_eins I'd like 3. most, but couldn't find out how to sign an existing homedir.
=> More informations about this toot | More toots from nik@toot.teckids.org
@nik tooling around doing that is shit, as mentioned. But basically you do "homectl create --identity=" and pass the already signed JSON user record from some system in. Which will then sign it with the local key after admin auth.
=> More informations about this toot | More toots from pid_eins@mastodon.social
@pid_eins Ah, I always thought that'd create a local copy of the record, so I then have two copies on two systems that will get out of sync if one system makes changes.
Are local records updated from the data in the user home when it becomes available, e.g. as a USB drive?
=> More informations about this toot | More toots from nik@toot.teckids.org
@nik yes.
=> More informations about this toot | More toots from pid_eins@mastodon.social
@pid_eins thanks for the homed. IMHO, one of the best and most useful feature to get a really portable user's home.
=> More informations about this toot | More toots from JigenDaisukeJr@mastodon.social This content has been proxied by September (ba2dc).Proxy Information
text/gemini