From b5bb0e05ea4de98a6710e44fa8e3abcb7dfbf337 Mon Sep 17 00:00:00 2001 From: Konrad Bucheli Date: Tue, 4 Oct 2022 17:28:30 +0200 Subject: [PATCH] document Kerberos issues --- rhel8/kerberos.md | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/rhel8/kerberos.md b/rhel8/kerberos.md index 4ea58997..e095c559 100644 --- a/rhel8/kerberos.md +++ b/rhel8/kerberos.md @@ -2,8 +2,8 @@ This document describes the Kerberos issues we encountered during RHEL 8 introduction. -In RHEL we are using the `KEYRING` (kernel keyring) cache, -whereas for RHEL8 there came early the wish to use `KCM` (Kerberos Cache Manager) instead. +In RHEL 7 we are using the `KEYRING` (kernel keyring) cache, +whereas for RHEL 8 there came early the wish to use `KCM` (Kerberos Cache Manager) instead. The Kerberos documentation contains a [reference for all available cache types]( https://web.mit.edu/kerberos/www/krb5-latest/doc/basic/ccache_def.html). @@ -13,10 +13,11 @@ The Kerberos documentation contains a [reference for all available cache types]( - ssh ticket delegation (with `GSSAPIDelegateCredentials yes`) - AFS authentication (`aklog`) - AFS administrative operations where the user switches to a separate admin principal (e.g. `buchel_k-adm`) -- Website authentication (`SPNEGO` with Firefox, Chrome) +- local desktop: get new TGT on login - local desktop: ticket renewal after reauthentication on lock screen +- remote desktop with NoMachine NX: get new TGT on login - remote desktop with NoMachine NX: ticket renewal after reconnection - +- Website authentication (`SPNEGO` with Firefox, Chrome) ## KCM @@ -25,7 +26,7 @@ The `KCM` cache is provided by a dedicated daemon, for RHEL8 this is `sssd_kcm` ### Advantages of KCM The advantage of `KCM` is that the caches are permanent and survive daemon restarts and system reboots without the need to fiddle around with files and file permission. This simplifies daemon and container use cases. -It also does automatically renew tickets which is handy for every use case. +It also automatically renews tickets which is handy for every use case. ### User Based vs Session Based @@ -37,7 +38,7 @@ Problems I see with this are - user may change his principal, eg. for admin operations (`kinit buchel_k-adm`) which is then used by all sessions - user may destroy the cache (it is good security practice to have a `kdestroy` in `.bash_logout` to ensure nobody on the machine can use your tokens after logging out) - software may put tokens into the cache which suddenly are not there any more -- the magic/heuristic used to select might not work optimally for all use cases (as we see below `sshd-kcm` fails horribly..) +- the magic/heuristic used to select might not work optimally for all use cases (as we see below `sshd-kcm` fails horribly...) So if we have more than one session on a machine (e.g. people connecting via remote desktop and ssh at the same time), the cross-session side-effects can cause unexpected behaviour. @@ -49,9 +50,9 @@ A way to get `KCM` of of the business of selecting the "optimal" cache is to sel ### Problems of sssd_kcm -The most obvious and well [known problem](https://github.com/SSSD/sssd/issues/3593) of `sshd-kcm` is that does not remove expired tokens and credential caches. I agree that it should not have an impact as this is mostly cosmetic. But that is only the case when everything can cope with that... +The most obvious and [well known problem](https://github.com/SSSD/sssd/issues/3593) of `sshd-kcm` is that it does not remove expired tokens and credential caches. I agree that it should not have an impact as this is mostly cosmetic. But that is only the case when everything can cope with that... -To check the Kerberos credential cache, you can use `klist` to look a the current default cache and `klist -l` to look at all available caches. Note that there the first listed cache is the default cache. Of course that is only valid when there is no `KRB5CCNAME` environment variable set or it is `KCM:`. +To check the Kerberos credential cache, you can use `klist` to look a the current default cache and `klist -l` to look at all available caches. Note that the first listed cache is the default cache. Of course that is only valid when there is no `KRB5CCNAME` environment variable set or it is `KCM:`. #### Use of Expired Credential Caches In below example you see that on the ssh login, I got a new default cache. But after a few minutes (there was a Desktop login from my side and maybe an automatic AFS token renewal in between), I get an expired cache as default cache. @@ -157,7 +158,7 @@ Principal name Cache name [buchel_k@mpc2959 ~]$ ``` -After I login via NoMachine NX and get an cache expired since more than two month: +After I logged in via NoMachine NX I got a cache expired since more than two month: ``` [buchel_k@mpc2959 ~]$ klist -l @@ -178,7 +179,7 @@ Do Sep 22 08:37:41 CEST 2022 ``` Note that a non-expired cache is available, but NoMachine NX explicitely sets `KRB5CCNAME` to a specific KCM cache. And it contains a ticket/cache which is supposed to the gone. -So there is a security bug in `sssd-kcm`: it does not fully destroy tickets when being told so. And there is another security issue in the NoMachine NX -> `sssd-kcm` interaction. I assume that it talks with the `KCM` as root and gets somehow (or has saved somewhere) old caches and moves them over into user context. But the cache may not originally belong to the user... +So there is a security bug in `sssd-kcm`: it does not fully destroy tickets when being told so. And there is another security issue in the NoMachine NX -> `sssd-kcm` interaction. I assume that it talks with the `KCM` as root and gets somehow (or has saved somewhere) old caches and moves them over into user context. But the cache may originally not have belonged to the user... I have not found a lot concerning Kerberos on the NoMachine website. @@ -187,7 +188,7 @@ I have not found a lot concerning Kerberos on the NoMachine website. Ideally we would get to a solution which can do the following: - interactive user sessions are isolated do not interfer with each other -- AFS can get hold of new tickets and inject them into the PAGs as long as the user somehow regular authenticates +- AFS can get hold of new tickets and inject them into the PAGs as long as the user somehow regularly authenticates - `systemd --user` which is residing outside of the interactive user sessions is happy as well - `goa-daemon` sees only one cache @@ -210,7 +211,7 @@ I had a very short look at the `systemd` source code, but could not yet find the #### At the Start of PAM At some point I also made a test by setting `KRB5CCNAME` at the start of PAM to a fixed name of an existing cache, so that the TGT, etc. end up in a well known place. -That worked well, I also tested sucessfully that autheticating on the screen lock updates the TGT. +That worked well, I also tested sucessfully that authenticating on the screen lock updates the TGT. Using a random, non-existing cache name resulted in a failure, not in the creation of that cache as it would happen if you do that with `kinit`. So that self made PAM module would need to be extended to also create the cache. @@ -239,6 +240,8 @@ How to proceed here? Post this document and ask how to proceed? ### Other Options +- another selfmade daemon to monitor/clean up `sssd-kcm` + Fill in your ideas. ## PS