logo_kerberos.gif

Difference between revisions of "Projects/Keyring collection cache"

From K5Wiki
Jump to: navigation, search
(Possible integration in the current KEYRING cache type)
(Linux Kernel improvements)
Line 26: Line 26:
 
remain in unswappable kernel memory).
 
remain in unswappable kernel memory).
   
Creation of a new public interface, keyctl_get_krbcache(uid_t,
+
Creation of a new public interface, keyctl_get_persistent(uid_t,
 
key_serial_t id). This API allows the user (and certain privileged
 
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
 
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
 
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
+
can outlive a user on the system if there is the need to perform actions
not logged in, such as cron scripts access to Secure NFS). The kernel
+
while not logged in, such as cron scripts access to Secure NFS).
keyring is created automatically on the first request if it does not
+
This kernel keyring is created automatically on the first request if it
yet exist.
+
does not yet exist.
   
 
Proposed patches by David Howells with explanatory comments on the kernel krbcache keyring:
 
Proposed patches by David Howells with explanatory comments on the kernel krbcache keyring:
 
http://mailman.mit.edu/pipermail/krbdev/2013-August/011650.html
 
http://mailman.mit.edu/pipermail/krbdev/2013-August/011650.html
 
  +
(note now renamed to 'persistent')
   
 
== Augmenting the current KEYRING cache type ==
 
== Augmenting the current KEYRING cache type ==

Revision as of 12:24, 20 August 2013

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_persistent(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 there is the need to perform actions while not logged in, such as cron scripts access to Secure NFS). This 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 (note now renamed to 'persistent')

Augmenting the current KEYRING cache type

The current keyring ccache type accepts the following residual forms: KEYRING:<name> KEYRING:process:<name> KEYRING:thread:<name>

Where name is an arbitrary string. The first type implies the use of a session keyring.

libkrb5 will now accept a new values for the ccache name:

KEYRING:session:<name> KEYRING:user:<name> KEYRING:persistent:<uidnumber>

Also all the keyrings will now allow to create cache collections.

The session and user keyrings use the session and user's keyrings. The new persistent type uses a special keyring as provided by the new keyutils call keyctl_get_persistent(). It requires support from the kernel for this new type otherwise it will fallback to use a user type keyring.