| Line 81: | Line 81: | ||
<!-- What other packages (RPMs) depend on this package? Are there changes outside the developers' control on which completion of this feature depends? In other words, completion of another feature owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate? Other upstream projects like the kernel (if this is not a kernel feature)? --> | <!-- What other packages (RPMs) depend on this package? Are there changes outside the developers' control on which completion of this feature depends? In other words, completion of another feature owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate? Other upstream projects like the kernel (if this is not a kernel feature)? --> | ||
The kernel | The kernel nfs server can benefit from the gssproxy interface in version 3.10. | ||
== Contingency Plan == | == Contingency Plan == | ||
Revision as of 14:53, 14 May 2013
GSS Proxy
Summary
The main purpose of this project is to replace rpc.svcgssd(8), the server-side rpcsec_gss daemon.
The gss-proxy consists of a standardized RPC protocol, a client and server implementation with other future components. The gss-proxy protocol allows proxying of GSSAPI initiation and authentication.
Owner
- Name: Simo Sorce
- Email: <ssorce@redhat.com>
- Name: Günther Deschner
- Email: <gdeschner@redhat.com>
Current status
- Targeted release: Fedora 19
- Last updated: 2013-05-14
- Percentage of completion: 100%
Detailed Description
The goal is to have a GSS-API proxy, with standardizable protocol and a [somewhat portable] reference client and server implementation. There are several motivations for this some of which are:
- Kernel-mode GSS-API applications (CIFS, NFS, AFS, ...) need to be able to leave all complexity of GSS_Init/Accept_sec_context() out of the kernel by upcalling to a daemon that does all the dirty work.
- Isolation and privilege separation for user-mode applications. For example: letting HTTP servers use but not see the keytab entries for HTTP/* principals for accepting security contexts.
- Possibly an ssh-agent-like SSH agent for GSS credentials -- a gss-agent.
In order to use the gssproxy only the gssproxy daemon has to be started at boottime. Once this is done, the GSSAPI mechglue library will make sure all GSSAPI calls issued by an application are directed to the gssproxy service transparently. Depending on the configuration of the system, the gssproxy daemon will then allow or disallow access to cryptographic keys stored in keytabs on the system.
Two major features that are planned to be achieved for Fedora19:
- rpc.gssd, the NFS client application, should be enabled to use the gssproxy. It will be possible to aquire tickets for kerberized NFS mounts given user keytabs.
- gssproxy will offer Kerberos ticket renewal when user keytabs are available
Benefit to Fedora
The key benefit for Fedora will be that we can provide more fine grained control over controlling access of applications to highly sensible cryptographic key material (keytabs). This in general improves security on the system.
Scope
Gssproxy and all depending components are appropriately changed, all changes are part of the upstream projects and integrated in Fedora to provide a proxy infrastructure for GSSAPI. The gssproxy mechglue library is packaged and can be loaded from the GSSAPI version shipped on Fedora 19.
How To Test
Currently we use two test programs (shipped with the main tarball) in order to do basic testing of our implementation. With the mechglue interface is in place, any tests done for the GSSAPI interface itself allow to test the gssproxy as well.
For the current testing you need to have a working KDC, one needs to create a keytab and gssproxy needs to be properly installed and configured.
User Experience
The usage of the gssproxy protocol and implementation is completely transparent for the user. Also applications do not need to be modified in order to benefit from the gssproxy.
Dependencies
The kernel nfs server can benefit from the gssproxy interface in version 3.10.
Contingency Plan
In case the gssproxy is not complete by the end of the final development freeze, Fedora can just decide to not ship it.
Documentation
- The gssproxy project wiki page of the MIT Consortium: [1]
- Protocol Documentation is available online as well: [2].
Release Notes
- gssproxy is an opensource project that aims to improve GSSAPI usage from both the kernel (for authenticating remote file system access) as well as user-space applications. It does provide fine-grained access control on Kerberos keytab access and it overcomes various limitations the kernel had when dealing with Kerberos tickets.