MAN page from Fedora 21 keyutils-libs-1.5.9-4.fc21.i686.rpm


Section: Kernel key management (7)
Updated: 21 Feb 2014


keyrings - In-kernel key management and retention facility 


Thekeyringsfacility is primarily a way for drivers to retain or cache security data,authentication keys, encryption keys and other data in the kernel.System call interfaces are provided so that userspace programs can manage thoseobjects and also use the facility for their own purposes.A library and some userspace utilities are provided to allow access to thefacility. Seekeyutils(7)manual page for more information.This document contains the following sections:
- Keys.
- Key types.
- Keyrings.
- Anchoring keys.
- Possession.
- Access rights.
- Searching for keys.
- On-demand key creation.
- Users.


The facility provides the concept of a 'key', where all of the aboveexamples are encapsulated within objects of this type.A 'key' contains the following elements:
Serial number
This is a unique integer handle by which a key is referred to in system callarguments.
This defines what sort of data can be held in the key, how the proposed contentof the key will be parsed and how the payload will be used.
There are a number of general purpose types available, plus some specialisttypes defined by specific drivers.
This is a printable string that is used as the search term for the key (inconjunction with the type) as well as a display name. The description may bepartially matched or exactly matched.
This is the actual content of a key. This is usually set when a key iscreated, but it is possible for the kernel to upcall to userspace to finish theinstantiation of a key if that key wasn't already known to the kernel when itwas requested.
A key's payload can be read and updated if the key type supports it and ifsuitable permission is granted to the caller.
Access rights
Each key has an owning user ID, an owning group and a security label - much asfiles do. They also have a set of permissions, though there are more than fora normal UNIX file, and there is an additional category beyond the usual user,group and other (see below).
Note that keys are quota controlled since they represent unswappable kernelmemory and the owning user ID specifies whose quota is to be debited.
Expiration time
Each key can have an expiration time set. When that time is reached, the keyis marked as being expired and accesses to it fail with EKEYEXPIRED. Ifnot deleted, updated or replaced, after a set amount of time, expired keys areautomatically removed along with all links to them and ENOKEY will bereported.
Reference count
Each key has a reference count. Keys are referenced by keyrings, by currentactive users and by a process's credentials. When the reference count reacheszero, the key is scheduled for garbage collection.See thekeyctl_describe(3)manual page for more information.


The facility provides several basic types of key:
Keys of this type are special. The payload consists of a set of links to otherkeys, analogous to a directory holding links to files. The main purpose of akeyring is to prevent other keys from being garbage collected because nothingrefers to them.
This is a general purpose key type. It may be instantiated with an arbitraryblob of data of up to about 32KB. It is kept entirely within kernel memory.It may be read and updated by userspace.
This is similar to user but it may hold data up to 1MB in size. The datamay be stored in the swap space rather than in kernel memory if the sizeexceeds the overhead of doing so (a tmpfs file is used - which requiresfilesystem structures to be allocated in the kernel).
This is similar to user but the contents may not be read by userspace.There are more specialised key types available also, but they're not discussedhere as they're not intended for normal userspace use.


As previously mentioned, keyrings are a special type of key that contain linksto other keys (which may include other keyrings). Keys may be linked to bymultiple keyrings. Keyrings may be considered as analogous to UNIX directorieswhere each directory contains a set of hard links to files.Several of the syscall functions available may only be applied to keyrings:
A key may be added to a keyring by system calls that create keys. Thisprevents the new key from being immediately deleted when the system call driverreleases its last reference to the key.
A link may be added to a keyring pointing to a key that is already known,provided this does not create a self-referential cycle.
A link may be removed from a keyring. When the last link to a key is removed,that key will be scheduled for deletion by the garbage collector.
All the links may be removed from a keyring.
A keyring may be considered the root of a tree or subtree in which keyringsform the branches and non-keyrings the leaves. This tree may be searched for aleaf matching a particular type and description.See thekeyctl_clear(3),keyctl_link(3),keyctl_search(3)andkeyctl_unlink(3)manual pages for more information.


To prevent a key from being prematurely garbage collected, it must anchored tokeep its reference count elevated when it is not in active use by the kernel.Keyrings are used to anchor other keys - each link is a reference on akey - but whilst keyrings are available to link to keys, keyrings themselvesare just keys and are also subject to the same anchoring necessity.The kernel makes available a number of anchor keyrings. Note that some ofthese keyrings will only be created when first accessed.
Process keyrings
Process credentials themselves reference keyrings with specific semantics.These keyrings are pinned as long as the set of credentials exists - which isusually as long as the process does.
There are three keyrings with different inheritance/sharing rules: The sessionkeyring (inherited and shared by all child processes), the process keyring(shared by all threads in a process) and the thread keyring (specific toa particular thread).
User keyrings
Each UID known to the kernel has a record that contains two keyrings: Theuser keyring and the user session keyring. These exist for as longas the UID record in the kernel exists. A link to the user keyring is placedin a new session keyring by pam_keyinit when a new login session isinitiated.
Persistent keyrings
There is a persistent keyring available to each UID known to the system.It may persist beyond the life of the UID record previously mentioned, but hasan expiration time set such that it is automatically cleaned up after a settime. This, for example, permits cron scripts to use credentials left when theuser logs out.
Note that the expiration time is reset every time the persistent key isrequested.
Special keyrings
There are special keyrings owned by the kernel that can anchor keys for specialpurposes. An example of this is the system keyring used for holdingencryption keys for module signature verification.
These are usually closed to direct alteration by userspace.See thethread-keyring(7),process-keyring(7),session-keyring(7),user-keyring(7),user-session-keyring(7),andpersistent-keyring(7)manual pages for more information.


The concept of 'possession' is important to understanding the keyringssecurity model. Whether a thread possesses a key is determined by thefollowing rules:
Any key or keyring that does not grant Search permission to the caller isignored in all the following rules.
A thread possesses its session, process and threadkeyrings directly because those are pointed to by its credentials.
If a keyring is possessed, then any key it links to is also possessed.
If any key a keyring links to is itself a keyring, then rule (3) appliesrecursively.
If a process is upcalled from the kernel to instantiate a key, then it alsopossess's the requester's keyrings as in rule (1) as if it were therequester.Note that possession is not a fundamental property of a key, but must rather becalculated each time it is needed.Possession is designed to allow setuid programs run from, say, a user's shellto access the user's keys. It also allows the prevention of access to keysjust on the basis of UID and GID matches.When it creates the session keyring, the pam_keyinit module adds a linkto the user keyring, thus making the user keyring and anything it containspossessed by default.


Each key has the following security-related attributes:
- The owning user ID
- The ID of a group that is permitted to access the key
- A security label
- A permissions mask
The permissions mask is used to govern the following rights:
If set, the attributes of a key may be read. This includes the type,description and access rights (excluding the security label).
If set, the payload of a key may be read and a list of the serial numbers towhich a keyring has links may be read.
If set, the payload of a key may be updated, links may be added to or removedfrom a keyring, a keyring may be cleared completely and a key may be revoked.
If set, keyrings and subkeyrings may be searched and keys and keyrings may befound by that search.
If set, an additional link may be made to a key from a keyring. The initiallink to a key when it is created doesn't require this permit.
If set, the ownership details on a key and its security label may be changed,its expiration time may be set and it may be revoked.The permissions mask contains four sets of rights. The first three sets aremutually exclusive. One and only one will be in force at any one time. Inorder of descending priority:
Used if the key's user ID matches the caller's fsuid.
Used if the user ID didn't match and the key's group ID matches the caller'sfsgid or one of the caller's supplementary group list.
Used if neither the key's user ID nor group ID matched.The fourth set of rights is:
Used if a key is determined to be possessed by the caller.The complete set of rights for a key is the set union of whichever of the firstthree sets is selected plus the fourth if the key is possessed.If any right is granted to a thread for a key, then that thread will see thekey listed in /proc/keys. If no rights at all are granted, then that threadcan't even tell that the key exists.In addition to access rights, any active Linux Security Module mayprevent access to a key if its policy so dictates. A key may be given asecurity label or other attribute by the LSM which can be retrieved.See thekeyctl_chown(3),keyctl_describe(3),keyctl_get_security(3),keyctl_setperm(3)andselinux(8)manual pages for more information.


One of the key features of this facility is the ability to find a key that itis retaining. The request_key() system call is the primary point ofaccess for userspace to find a key to use (the kernel has something similaravailable).The search algorithm works as follows:
The three process keyrings are searched in the following order: the threadkeyring if it exists, the process keyring if it exists and then either thesession keyring if it exists or the user session keyring if that exists.
If the caller was a process that was invoked by the request_key() upcallmechanism then the keyrings of the original caller of that request_key()will be searched as well.
Each keyring is searched first for a match, then the keyrings referred to bythat keyring are searched.
If a matching key is found that is valid, then the search terminates and thatkey is returned.
If a matching key is found that has an error state attached, that error stateis noted and the search continues.
If valid matching key is found, then the first noted error state is returned orelse ENOKEY is returned.It is also possible to search a specific keyring, in which case only steps (3)to (6) apply.See therequest_key(2)andkeyctl_search(3)manual pages for more information.


If a key cannot be found, the request_key() system call will, if given acallout_info argument, create a new key and then upcall to userspace toinstantiate the key. This allows keys to be created on an as-needed basis.Typically, this will involve the kernel forking and exec'ing request-keyprogram, which will then execute the appopriate handler based on itsconfiguration.The handler is passed a special authorisation key that allows it and only it toinstantiate the new key. This is also used to permit searches performed by thehandler program to also search the requester's keyrings.See thekeyctl_assume_authority(3),keyctl_instantiate(3),keyctl_negate(3),keyctl_reject(3),request_key(2),request-key(8)andrequest-key.conf(5)manual pages for more information. 


The facility has a number of users and usages, but is not limited to thosethat already exist.In-kernel users of this facility include:
Network filesystems - DNS
The kernel uses the upcall mechanism provided by the keys to upcall touserspace to do DNS lookups and then to cache the results.
AF_RXRPC and kAFS - Authentication
The AF_RXRPC network protocol and the in-kernel AFS filesystem store the ticketneeded to do secured or encrypted traffic in keys. These are then looked up bynetwork operations on AF_RXRPC and filesystem operations on kAFS.
NFS - User ID mapping
The NFS filesystem uses keys to store foreign user ID to local user ID mapping.
CIFS - Password
The CIFS filesystem uses keys to store passwords for accessing remote shares.
Module verification
The kernel build process can be made to cryptographically sign modules. Thatsignature is then checked when a module is loaded.Userspace users of this facility include:
Kerberos key storage
The MIT Kerberos 5 facility (libkrb5) can use keys to store authenticationtokens which can be made to be automatically cleaned up a set time after theuser last uses them, but until then permits them to hang around after the userhas logged out so that cron scripts can use them.






This document was created byman2html,using the manual pages.