Projects/ProxyGSSAPI
This project is about creating a mechanism by which it is possible to proxy accepting and initializing a security context to a separate trusted system service without giving access to long term keys to an application. The proxy would be created at the mechglue layer so that any mechanism can be proxied.
Background
We have identified two main scenarios that benefit from this approach.
One is the ability to lock long term keys (especially the host/ key when the krb5 mechanism is used) into a trusted service on the system so that "less" trusted applications do not have direct access to the keys. This is a form of privilege separation that allows better control of the keys and reduces the attack surface of the system when it comes to gaining access to such keys.
The other is about trusting data being carried through, for example, krb5 tickets. In systems that use signed authorization data, it is fundamental for a "trusted" service to directly handle accepting a context so that it is impossible for an application to "fake" Authorization data by having access to the host keys and therefore being able to sign authorization data blobs. As an example think of a user accessing a FTP daemon and sending a user credentials (MS-PAC/PAD) in the ticket. A trusted service need to be able to verify that the KDC actually did sign this data in order to trust its authenticity and allow the system to create a user out of this data. A way to fully trust this data when it is signed by the long term key is to not allow the FTP service to have access to the long term keys, so that a subverted service is not allowed to create fake data and sign it in order to perform privilege elevation attacks.
Requirements
In order to be able to implement this proxy it is fundamental to be able to create an IPC mechanism to transfer data from the process handling the GSSAPI exchange to the trusted service holding the keys and negotiating the security context.
This IPC mechanism should use a defined protocol so that independent implementations of the trusted service can be created.
Interface stability either at an API level (if an endpoint library is created) or at the protocol level is highly desirable but not fundamental.
Considerations on the design
There are a few challenges that need to be considered for this project.
Access privilege. Currently access to credentials is determined base on file permissions. If the user/application have access to the keytab/credentials then it is allowed to use them for any purpose. By adding an IPC mechanism we need a mechanism to determine
* A design for how the desired functionality will be implemented * A breakdown of tasks or milestones to judge progress of the project * Screenshots or other proposed user interface descriptions * Documentation and sample code for any APIs that are proposed * Dependencies on other projects * Information on desired integration and release goals * Testing plan
