From Fedora Project Wiki
(GSS Proxy)
(Comments and Discussion)
Line 113: Line 113:
== Comments and Discussion ==
== Comments and Discussion ==
* See [[Talk:Features/Your_Feature_Name]]  <!-- This adds a link to the "discussion" tab associated with your page.  This provides the ability to have ongoing comments or conversation without bogging down the main feature page -->
* See [[Talk:Features/gssproxy]]  <!-- This adds a link to the "discussion" tab associated with your page.  This provides the ability to have ongoing comments or conversation without bogging down the main feature page -->

Revision as of 15:48, 12 July 2012

All sections of this template are required for review by FESCo. If any sections are empty it will not be reviewed

GSS Proxy


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.


  • Email: <>

Current status

  • Targeted release: Fedora 18
  • Last updated: 2012/06/30
  • Percentage of completion: 90%

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 keytabe entries for
  HTTP/* principals for accepting security contexts.
- Possibly an ssh-agent-like SSH agent for GSS credentials -- a

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.

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.


Work on the GSSAPI mechglue library is in progress but is currently not finished.

In order to properly load our mechglue library, some modifications to the system GSSAPI/Kerberos library (MIT) are required. Work on this has well progressed and is coordinated with upstream (MIT).

How To Test

Currently we use a test program (shipped with the main tarball) in order to do basic testing of our implementation. Once the mechglue interface is in place, any tests done for the GSSAPI interface itself would 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.


The kernel will use the gssproxy interface.

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.


  • The gssproxy project wiki page of the MIT Consortium: [1]
  • Protocol Documentation is available online as well: [2].

Release Notes

  • TBD

Comments and Discussion