Controls/gitea-pages
0
2
Fork 0
Code Pull Requests Actions Activity

document latest experiments

Browse Source
This commit is contained in:
buchel_k
2022-10-07 17:48:15 +02:00
parent 259c1e6065
commit 7f3d732ea6
1 changed files with 19 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files
rhel8/kerberos.md
+19 -8
View File
@@ -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