1:53 p.m.
On Fri, Feb 23, 2024 at 12:06 PM John Doe <jdoe53851(a)gmail.com> wrote:
Now I know I can calculate the time for expiration myself by
checking the 'offline_credentials_expiration' value in sssd.conf and
add that to the timestamp for cache entry last update time reported
by 'sudo sssctl user-show $USER'
Are you certain of that?
In my testing, the timestamps shown by "sssctl user-show $USER" would
change if sssd was in an online state and refreshed the user object
from AD; no authentication was required. And while it is probably the
case that if sssd was online for any significant period of time, the
user probably authenticated during that time (e.g., unlocking a screen
saver would count) and thus the cached password expiration was
updated, you cannot necessarily assume that.
My conclusion was that while sssd (obviously) has code paths to look
up the cached password expiration, they are reached only through the
PAM stack. There is no generic way (e.g., via sssctl) to discover
what credentials are cached within sssd, or when those credentials
expire.
Similarly, there appears to be no way to list all Kerberos credentials
stored in KCM. If you suspect a specific user has credentials, you
can setpriv(1) to that user and run klist(1), but there is no generic
way to enumerate all credentials.
I was thinking of 'sss_cache' as that can run as a regular
user but
that can't give me the timestamp :-(
At least for Kerberos credentials, I once threw together a
proof-of-concept script that used the Samba tdbdump utility to dump
/var/lib/sss/secrets/secrets.ldb and rummage through the output,
As great as sssd is, its opacity about its cached information is
frustrating to system administrators. We shouldn’t need to resort to
third-party data dumping tools to get useful information out of sssd.
Thus, I would really love to see the following sssctl commands:
* cred-show Information about cached user credentials
* kcm-show Information about cached KCM credentials
The "sssctl cred-show" command would produce a table of all cached
user credentials, where the first column is the user@DOMAIN who owns
the credentials, and the second column is the expiration time of
credential expressed as time_t (seconds since epoch).
The "sssctl kcm-show" command would product a similar table, with four
columns: the owning user, the credential cache name, the credential,
and the expiration time expressed as time_t.
On Mon, Feb 26, 2024 at 6:40 AM Alexey Tikhonov <atikhono(a)redhat.com> wrote:
*sorry, `CAP_DAC_OVERRIDE`, of course.
CAP_DAC_READ_SEARCH would be better, as unlike CAP_DAC_OVERRIDE,
CAP_DAC_READ_SEARCH does not bypass file *write* permission checks.
But even still, this is arguably a flawed approach, as depending on
how this is implemented, you might wind up exposing the complete
contents of the /var/lib/sss/secrets/secrets.ldb file to ordinary
users. Among other things, that would allow theft of KCM credentials,
and harvesting any/all cached credentials for nefarious purposes
(e.g. offline password cracking).
The best long-term approach would be for sssctl to add commands that
permit enumeration of cached credentials (and cached KCM credentials).
From there, any number of scripting solutions are possible.