Projects/Keyring collection cache

This is an early stage project for MIT Kerberos. It is being fleshed out by its proponents. Feel free to help flesh out the details of this project. After the project is ready, it will be presented for review and approval.

Scope

Implement a new Kernel based credential cache collection that uses the Keys API.

The new cahe type is a collection and is store in a per-user keyring avaialble to any user session and that can persist in the system until expiration time even in the absence of an active user session.

Background and previous work

The MIT Kerberos code base already include a KEYRING ccache type that uses kernel keyrings to implement a credential cache modeled after the FILE cache type. This cache type has 3 important limitations:

• Uses only session or process or thread based keyrings

This means the cache cannot survive a user logout and cannot be shared between different sessions of the same user.

• Uses the classic "user" key type

The "user" keytype is limited in size because use kernel locked memory so it has issues storing large tickets (like those including a MS-PAC AD) due to strict default quotas on this type of key

• It cannot represent cache collections.

DesignComponents

Linux Kernel improvements

Addition of a new key type "big_key" that allows us to create keys up to 1MiB in size, backed by internal kernel tmpfs, allowing the contents to be swapped out to disk (unlike most other keyrings, which remain in unswappable kernel memory).

Creation of a new public interface, keyctl_get_krbcache(uid_t, key_serial_t id). This API allows the user (and certain privileged root processes such as rpc.gssd and GSS-Proxy) to access the keys for a particular UID. This keyring is not tied to a session (so it can outlive a user on the system if they need to perform actions while not logged in, such as cron scripts access to Secure NFS). The kernel keyring is created automatically on the first request if it does not yet exist.

Proposed patches by David Howells with explanatory comments on the kernel krbcache keyring: http://mailman.mit.edu/pipermail/krbdev/2013-August/011650.html

Possible integration in the current KEYRING cache type

libkrb5 will now accept a new value for the credential cache string (for example: when used in KRB5CCNAME).

It will take the form:

 KEYRING:krbcache:$UID

to represent a credential cache collection and

 KEYRING:krbcache:$UID:tktXXXXX

to represent a specific key within a cache collection.

The new krbcache type wil create a special parent keyring as provided by the new keys call keyctl_get_krbcache()

In this keyring a key called krbcache:index will contain a 4 byte version number and the name of the current primary cache, pretty much like the 'primary' file contains the name of the primary cache for the DIR cache type.

Each cache will be stored in a child keyring, the format used in this keyring is the same as used by the classic KEYRING cache types except that tickets will be store in keys of type "big_key" instead of using the "user" type.