On Friday, I was asked to quickly write policy for the new gssproxy daemon which was added to Fedora 19. Investigating it, I found I had a new security feature blog, I had to write.
Fedora 19 is adding the gssproxy daemon. gssproxy will be replacing rpc.svcgssd.
gssproxy is a a proxy daemon for the GSS-API, which is a higher level API used mainly in Kerberized applications.
File systems services like CIFS, (samba), NFS and AFS make lots of kerberos encryption calls within the kernel, using keying material handed into the kernel. But the initialization and creation, renewing and cleaning up of credential caches, really should be handled in user space. gssproxy is the daemon to handle this.
A useful feature of gssproxy will eliminate the need to daemons that use kerberos keytabs from needing to read them directly. Currently if you set up an Apache server with kerberos, it needs full read access to the keytab file, allowing it to see the keying material. If Apache gets hacked, the hacker would get full access to the secrets. With gssproxy developers could setup Apache to talk to gssproxy and allow it to handle the keytab file, eliminating this need. This will allow my team to alter the SELinux policy and prevent the Apache daemon from being able to read keying information directly and force it to talk to the daemon.
Another cool feature, explained to me by Simo Sorce, is to take an application that needs kerberos access to a nfs share, but does not know anything about kerberos or the gssapi. Currently the way you handle this is to wrap an init scripts with things like k5start so the application has a keytab and a credential cache regularly refreshed. Then rpc.gssd would have to look in /tmp for a ccache to use for the application user and allow the application authenticated access to the secure nfs share.
With gssproxy you will not longer need to do this. All you need to do is drop a keytab in /var/lib/gssproxy/clients/<id>.keytab and the gssproxy will automatically initiate a connection when nfs client needs it. Advantages of this method:
1. No more wrapping of init scripts
2. Privilege separation, the app has no access to the keytab
3. Initiate on request, if the app never needs nfs we never initiate or renew tickets unnecessarily
gssproxy can be setup to renew Kerberos Tickets from keytabs for long running jobs, eliminating a lot of previous hacks.