Best practice is to *NOT* use the system default keytab file. Use a service-specific one. Most services should support configuring the location of that keytab file.
If there's nothing specific to the app, then the SASL libraries have a config item you can put in the app's SASL config file: keytab: <</path/to/keytab>> (Of course you'll still need to find where its SASL config file is, which may require resorting to dtrace.) Failing that, you still have an option in GSSAPI and the Kerberos libraries to set the environment variable KRB5_KTNAME. Set it to the path to the keytab file. Since this is a Sun list, I can point you at http://docs.sun.com/app/docs/doc/816-4557/sasl-1?a=view for more detail on SASL. On Sep 24, 2010, at 1:44 AM, Chris Ridd wrote: > Hi, > > We've got some long-lived server processes (ldap, smtp, imap, xmpp) that > support clients authenticating using SASL and GSS-API. AIUI, the servers call > (through a maze of twisty libraries and plugins and callbacks) > gss_acquire_cred() on demand when they start to talk to a client, and that > call tends to involve opening /etc/krb5/krb5.keytab to retrieve some secret > info for the process/host. > > That works OK as long as the server stays running as root, because the keytab > file is only readable by root:root. > > But we don't *want* to stay running as root. Normally what we try to do is > drop to a less privileged uid after listening on privileged ports etc, but > that will simply cause the next call to gss_acquire_cred() to fail with > permissions problems. > > What's the best practice here? Are there any well-defined process privileges > that we can use which only allow access to the keytab, or do we have to just > rely on filesystem permissions/ACLs? Or something else I haven't thought of? > :-) > > Cheers, > > Chris > _______________________________________________ > security-discuss mailing list > [email protected] ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [email protected], or [email protected] _______________________________________________ security-discuss mailing list [email protected]
