Repository navigation
Obtaining user credentials with the KCM backend #130
Description
Activity
can you please state the use case?
generally gssproxy is used for privilege separation, so if a user already have credentials in their cache there is no real privilege separation needed. However there may be some cases where being able to fetch creds from users may be a reasonable idea. So I'd like to understand the use case.
This use case is somewhat convoluted:
- A privileged daemon proxies authorization decisions to a remote server.
- A filesystem layer sends the daemon a request when it needs to determine whether a user action is allowed.
- The filesystem request provides the caller’s local kernel identity (UID/GID/PID), but it does not carry a Kerberos credential or credential-cache context.
- The daemon must therefore locate the credential cache associated with the requesting UID and use it to authenticate the decision request to the remote server.
There are a few ways to handle this:
- change gssproxy so it can fork a helper process as the requested user in order to use sssd-kcm
- change sssd-kcm to allow root to access other users credentials under special conditions
- change your application to fork a helper process as the requested user in order to directly access sssd-kcm
Do you have other reasons to use gssproxy to make (1) a better solution than (3) ?
No, other than avoiding every application with this use case having to implement the same helper. I employ (3) already actually, it works fine.
Originally, I expected gssproxy to centralize all of the credential acquisition. In the end, we only use it for the machine/keytab credentials. User credentials are obtained in the method described in (3).
Ideally, I think (2) could (should?) address this, although I'm not familiar with the conversations that were had that justified changing SSSD KCM's initial design and differing from Heimdal's implementation.
I was involved in the decision and the reason is that credential caches are fully available to gssapi so letting root see all caches can lead to a root process incorrectly: a) use some other user credential, b) inserting credentials into user creds they should not have access to.
A) is more critical as it can lead to unexpected failures due to incorrect access privileges at the server.
B) is unlikely but would be quite bad if a higher privileged credential would end up in some user hand.As for implementing this in gss-proxy, it is something we could contemplate, but I personally do not have the bandwidth right now.
I think at the very least, some documentation saying that gssproxy can't fetch user credentials when the sssd-kcm backend is used would be helpful. I designed a bunch of code around that just to learn that because it doesn't work for one specific backend, it doesn't work anywhere and I had to change the entire design.
I had the very unpleasant revelation that gssproxy cannot fetch user credentials, even when run as root, when using the sssd-kcm as a KCM backend.
SSSD/sssd#9083
I didn't see much documentation on the matter in this repo, I'm wondering if this is a known issue and how most people go about it.