My approach is simpler: * A kerberized service where the user registers that they want to be able to do cron jobs on a given machine. * A kerberized pam module that calls the same service and gets back credentials, locked to the IP address, and at least by default not forwardable.
The pam module authenticates using the system keytable. This may not be quite as good as a TPM, because it depends upon the integrity of the system key table. But the service checks the IP address, so my host credential is host/FOO, a lookup of FOO has to produce the IP address the request came from. That seems pretty close. I’ll look into TPM, to see if that could somehow be used. > On Jul 21, 2017, at 3:42 PM, Russ Allbery <ea...@eyrie.org> wrote: > > Charles Hedrick <hedr...@rutgers.edu> writes: > >> The argument makes sense. > >> However I am disturbed by the fact that a keytab can be used >> anywhere. If someone manages to become root on one machine, I’d like >> them not to be able to do things on other machines. I’m in an >> environment where we have systems administered by users, and unattended >> public workstations. > >> That makes me unwilling to tell users to create key tables for cron >> jobs. > > Yeah, if you're worried about portable keys, that's when you probably want > to do something with a system TPM. If you go down that path, I'd probably > try to figure out some way to do PKINIT using a TLS certificate stored in > the TPM. I'm not aware of anyone who has already done that work, but it > would be a pretty interesting project. > > -- > Russ Allbery (ea...@eyrie.org) > <https://na01.safelinks.protection.outlook.com/?url=http:%2F%2Fwww.eyrie.org%2F~eagle%2F&data=02%7C01%7Chedrick%40rutgers.edu%7C90d749cea9134410e85408d4d070b68e%7Cb92d2b234d35447093ff69aca6632ffe%7C1%7C0%7C636362629909705292&sdata=iWSMAyut%2BMLlSdzzPQnhZLbT4%2FCEYt5a%2BnBhbvnucCw%3D&reserved=0> ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
