From 7f3d732ea67307d07586ad955ca5e38bad726d23 Mon Sep 17 00:00:00 2001 From: Konrad Bucheli Date: Fri, 7 Oct 2022 17:48:15 +0200 Subject: [PATCH] document latest experiments --- rhel8/kerberos.md | 27 +++++++++++++++++++-------- 1 file changed, 19 insertions(+), 8 deletions(-) diff --git a/rhel8/kerberos.md b/rhel8/kerberos.md index c3c8fe1e..5199965b 100644 --- a/rhel8/kerberos.md +++ b/rhel8/kerberos.md @@ -217,6 +217,21 @@ Using a random, non-existing cache name resulted in a failure, not in the creati So that self made PAM module would need to be extended to also create the cache. I assumed that the "End of PAM" solution would be easier to implement, so I opted for that. +#### Copy Credentials from Automatic Generated Cache to Self-Made Cache Both "Start of PAM" or "End of PAM" +In my latest version of my self-made PAM module can be used both at auth (early) and at session (late) part of the PAM stack. It either sets `KRB5CCNAME` to a randomly generated cache ( e.g. `KCM:44951:bzfandqspm`) or to a given value, e.g. `suffix=desktop` would create `KCM:44951:desktop`. + +To make ticket delegation work, it copies the credentials from the default cache to the new cache. + +First experiments with with ssh are successful. For the desktop I use a fixed cache `KCM:44951:desktop`. This makes`KRB5CCNAME` is correctly set, but the credentials are in the current version not yet available. + +TODOs: +- better selection of the source cache as the default cache is not always ideal (I have code for that already in the "End of PAM"-only version. +- do not delete credentials in target cache +- the "random" might not be nessesary, at least for ssh it it would be sufficient to fix it to the automatic generated cache +- or destroy source cache? +- might be the early part (auth, "Start of PAM") is not needed. + +There are still some more experiments required. ### Only One Cache The `sssd-kcm` limits the number of caches by default to 64, but that can be changed to 1 with the `max_uid_ccaches`. @@ -234,8 +249,8 @@ So this causes a denial of service problem, we need to deal with somehow, e.g. b ## Options for Next Steps -### Try out Start of PAM -For the "End of PAM" experiments I got more into PAM and Kerberos programming with C than I wanted and I think I would get "Start of PAM" working in reasonable time. +### Continue Experiments with Own PAM Module Setting KRB5CCNAME +I think we can get here a solution where we get the KCM out of the business of selecting the best cache while still using the rest of its advantages. But that needs a bit more work and experimentation on that. ### Try out KEYRING Maybe we can try to create a solution with `KEYRING` which isolates the interactive sessions and still allows the AFS token renewal to access all caches. This then also needs `renew-afstoken` to care about Kerberos ticket renewal. @@ -245,13 +260,9 @@ For the listed use cases above the caches and tickets do not need to survive reb ### How to deal with Systemd --user ? The `systemd --user` process is started at the beginning of the first session and ends at the end of the last session. And some desktop environments depend heavily on it. -It might be that "Start of PAM" is good enough, but I expect follwoing problem: -If `systemd --user` is started with ssh or a previous desktop session, the password entry at the desktop login might not update the TGT as PAM is operating on a different cache. -The following might create a solution which might isolate the ssh sessions with individual caches and have one cache for `systemd --user` and all desktop sessions: -The PAM configuration for ssh use a random fixed "Start of PAM" cache, where as for `systemd --user` and the display managers (`gdm` and `lightdm`) the PAM configuration is different as the "Start of PAM" cache is always the same and well known, e.g. `KCM:$UID:systemd--user`. +So the ideal solution might be to have just one known "desktop" cache (e.g. `KCM:44951:desktop`) which is shared by `systemd --user` and all desktop sessions. -### Go on with End of PAM experiment -I figured out that it is possble to inject environment variables into `systemd --user` with `systemctl --user import-environment` or `systemctl --user set-environment`, but that then affects only newly started software. +Additinally I figured out that it is possble to inject environment variables into `systemd --user` with `systemctl --user import-environment` or `systemctl --user set-environment`, but that then affects only newly started software. Only experiments would show if this is good enought or if some important processes live longer than the desktop session. ### Red Hat Ticket