This is a discussion on gss_cred_id_t from keytab after fork without exposing keytab? - Kerberos ; Can someone recommend a method for providing an unpriviledged child process with a gss_cred_id_t derived from a keytab but without exposing the key to the child? Specifically, I have a service that starts out as root and forks a child. ...
Can someone recommend a method for providing an unpriviledged child
process with a gss_cred_id_t derived from a keytab but without exposing
the key to the child?
Specifically, I have a service that starts out as root and forks a
child. The child then changes it's uid/gid to an unpriviledged user,
does gss_init_sec_context, and then performs user defined work until
the service is stopped (meaning it could be running indefinitely).
As it is, if I simply putenv("KRB5_KTNAME=/var/lib/test/test.keytab")
the keytab file must be readable by the unpriviledged user. I don't
think I care if they have a ticket but with the raw key they could
decrypt network traffic and do generally evil things.
Any ideas?
Thanks,
Mike
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos