Some thoughts inline:
On 11/22/2016 02:51 AM, Jakub Hrozek wrote:
...
=== Implementation details ===
A new SSSD responder will be added. Since accessing the Kerberos credentials
is quite an infrequent operation, the responder will be socket-activated.
This responder would implement the same subset of the KCM protocol the MIT
client libraries implement. Contrary to Heimdal's KCM server that just
stores the credential caches in memory, the SSSD KCM server would store
the ccaches in the secrets database through the sssd-secret's responder
[
https://jhrozek.fedorapeople.org/sssd/1.14.2/man/sssd-secrets.5.html public REST API].
For user credentials the KCM Server would use a secrets responder URI
like `/kcm/users/1234/X` where 1234 is the user ID and X is the residual.
The client then gets assigned a KRB5CCNAME of KCM:1234:X. Internally in the
secrets responder we will store the credential caches under a new base DN
`cn=kcm`.
The secret responder's quota on secrets must be made modular to allow
different number of secrets per base DN (so, different number of secrets
and credentials pretty much). What to do in case the quota is reached is
debatable - we should probably first remove service (non-TGT) tickets first
for valid TGTs and if that's not possible, just fail. A failure in this
case would be no different than a failure if a disk is full when trying
to store a FILE-based ccache.
The KCM responder would renew the user credentials by starting a tevent
timer which would then contact the SSSD Data Provider for the given UID
and principal, asking for the credentials to be renewed. Another tevent
timer would reap and remove a ccache that reaches its lifetime.
OK, so the service is only semi-socket-activated? If we're keeping tevent timers
around for renewals and reaping, the service won't be exiting unless all tickets
have expired and been reaped.
Would it be possible to look into setting non-persistent systemd timer units
instead that would "wake up" the sssd_kcm service at appropriate times to do
renewal and expiration?
systemd provides the CreateTransientUnit() method on its public API that we
could use for this purpose. If we did it this way, then the service would only
need to be activated whenever a ticket was actually being retrieved from the
collection.
In the future, SSSD-specific operations such as writing out a
FILE-based
ccache might be added. The SSSD D-Bus interface would also be extended to
publish information about credentials activity (such as - a ticket being
acquired, a ticket was renewed etc)
This should be a high priority, since it will benefit tools such as GNOME Online
Accounts greatly (right now, they have to poll the kernel keyring and are not
happy about it; with FILE and DIR caches, they at least could get notifications
via inotify)
=== Configuration changes ===
No KCM-specific configuration options will be added. The SSSD KCM responder
would use the same common options like other SSSD services such as idle
timeout.
We can add a configurable KCM socket location later, if needed, but for
the start it's fine to default to `/var/run/.heim_org.h5l.kcm-socket`
mostly because that's what MIT defaults to as well.
'''Q''': Should we add an option to explicitly enable ccache
renewals and
default to no renewals? I don't think this would any any security though,
the attacker can just run 'kinit -R' on behalf of the user anyway.
If the user asked for a renewable ticket in the first place (and the server
permitted it), then I don't see any reason not to just go ahead and renew it by
default.
=== How To Test ===
In order for the admin to start using the KCM service, the sssd-kcm
responder's systemd service must be enabled. Then, libkrb5 must also be
configured to use KCM as its default ccache type in `/etc/krb5.conf`
{{{
[libdefaults]
default_ccache_name = KCM
}}}
After that, all common operations like kinit, kdestroy or login through
pam_sss should just work and store their credentials in the KCM server.
The KCM server must implement access control correctly, so even
trying to access other user's KCM credentials by setting KRB5CCNAME to
`KCM:1234:RESIDUAL` would not work (except for root).
Restarting the KCM server or rebooting the machine must persist the tickets.
As far as automatic unit and integration testing is required, we need to make
sure that MIT's testsuite passes with Kerberos ccache defaulting to KCM
and SSSD KCM deamon running. In the SSSD upstream, we should write
integration tests that run a MIT KDC under socket_wrapper to exercise the
KCM server.
How do containers access the KCM? Would they have to run their own copy internal
to the container? Would we bind-mount the /var/run/.heim_org.h5l.kcm-socket and
then work some namespacing magic in the host?
You call out in the introduction that this will help address container
use-cases, but then don't describe that implementation. This seems like an
important piece of the puzzle that should be added to the page (or made more
clear, since if it's in there, I can't spot it).