On Fri, Sep 24, 2010 at 08:16:11PM +0100, Chris Ridd wrote: > On 24 Sep 2010, at 19:04, Nicolas Williams wrote: > > Why do you need to keep calling gss_acquire_cred()? Have you tried > > re-using that one credential handle acquired before dropping privileges? > > The problem generally is that we end up calling gss_acquire_cred() > some unknown time after startup, and only on demand to a (perhaps just > the first?) SASL GSSAPI connection. We also support enabling SASL > mechs on the fly, so we could suddenly find ourselves needing to do a > gss_acquire_cred() *way* after dropping any startup privileges.
Newer versions of Cyrus SASL allow the application to pass in a gss_cred_id_t. We really should add that exteion to Solaris' libsasl. That would allow you to acquire the credential handle early on and then pass it down the stack. However, you should know that the keys will be available to an attacker who compromises your daemon, which in turn may be sufficient to compromise the entire system (e.g., if the principal you're using is one for the "host" service). You should consider an alternative where you use separate processes to do the SASL work. I.e., you should consider having a separate process that retains privileges that just does the SASL stepping and your daemon, with least privilege, would proxy SASL authentication messages through it. Are you using SASL security layers, or are you relying on TLS? Maybe something along the lines of stunnel, but for SASL, should do the trick. > Also AIUI the credentials might expire and thus need to be re-acquired > at some point. I'm rather hazy on whether GSSAPI/Kerberos does that or > not. If you were to re-key the relevant host principals you'd have to restart the service, yes. But krb5 acceptor credentials don't have expiration times. Nico -- _______________________________________________ security-discuss mailing list [email protected]
