On May 4, 2012, at 11:34 AM, Russ Allbery wrote: > Benjamin Coddington <[email protected]> writes: > >> We're interested in using linux session keyrings to hold krb5 >> credentials acquired through webauth. I'd like to propose one approach. > >> If acceptable, I'd be happy to submit the required changes to include >> documentation and config requirements. > >> This approach reuses the existing WebAuthCredCacheDir directive by >> passing it along unchanged if it begins with "KEYRING:" to >> webauth_krb5_init_via_cred -> krb5_cc_resolve. > > Looks like a great idea to me. The only change that I'd recommend is > that, rather than special-case KEYRING, instead preserve the current > behavior only if the argument begins with FILE: or doesn't begin with a > cache type. Most other cache types, like KEYRING, aren't file system > caches and should be treated the same way that you're treating KEYRING.
I'd like to avoid implementing the other ccache types because each type should be evaluated to allow webauth the opportunity to secure or deny the use of that ccache type. Because mod_webauth runs as the same user, a ccache is exposed to concurrent requests. We'd prefer to use the KEYRING over FILE ccache type specifically because it's possible to set 'Possessor' permissions on keys that would deny other processess running as the same user the ability to read those keys. This protects the ccache from being exposed to other apache requests. MIT's krb5 does not set the 'Possessor' permissions in krb5_cc_store_cred, and the default permissions allow keys to be shared by all processes with the same uid since it's not typical that you'd need to separate data created by the same user. In this case we do want to protect the data from other processes running as the same user, so we'll need to set the key permissions explicitly in webauth -- perhaps even use our own implementation of krb5_cc_store_cred so that the key can be created, linked, secured, then filled with the cred. So the submitted implementation of KEYRING support needs to be modified to include KEYRING specific work. I realize that my submitted patch did not cover any of that; I confess that I only just discovered that krb5 was not restricting it's ccache keys to 'Possessor' while investigating how the other available ccache types might behave if they were to be allowed as you recommend. If you'll agree, I'll resubmit to support the KEYRING type modified to explicitly set the ccache's key permissions to only allow 'Possessor' access. Ben
