On Tue, 2016-11-22 at 09:23 -0500, Stephen Gallagher wrote:
> 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.
I am trying to think if this would gain us anything.
What would you use as a reasonable timeout to decide to exit ?
There are other events we may want to detect in future. for example we
may want to decide to destroy all of a user ccaches if all his sessions
go away, this requires active probing though, but I guess it could also
be a timer or maybe systemd has a way to notify and start a process when
this happens too ?
> > 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)
That's the main target, but they will still need to keep the old code
for now, until we make sssd-kcm mandatory for gnome sessions.
> >
> > === 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.
You might be surprised at what regulations may require in this area, but
I tend to agree that it is ok as a 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?
Deployment specific, I can see either way as an option depending on what
you are doing.
> 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).
What would you want to call out exactly ?
Simo.
--
Simo Sorce * Red Hat, Inc * New York
_______________________________________________
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
