Linux Credentials

Documentation: https://www.kernel.org/doc/html/latest/security/credentials.html

Mutating Credentials

Credentials are designed to be fast to access, so they use the high-performance RCU mechanism under the hood.

• Each task may read and exchange its own credentials.
• Across tasks, only read access to credentials is permitted.

It is not permitted for a task to update the credentials of another task, and this assumption is also embodied in the “transactional” prepare/commit/abort API through which these updates are to be done:

Objective and Subjective Credentials

The Linux credentials object carries information about the credentials of a process, such as the process UID, GID, capabilities, as well as Landlock domains.

We distinguish between the objective and subjective credentials of a process:

• objective credentials (task->real_cred)
• subjective credentials (task->cred)
  • can be temporarily exchanged by the kernel, if an operation is to be done with the credentials of someone else; operations override _creds and restore_creds.

The ways of access differ between the task that the credentials belong to and others:

• Modification: current is by definition the only task who may modify its creds. Because of that, current creds may be read without any lock by the current task (using rcu_dereference_protected())
  • The API for modifying creds is specifically built so that no other task can accidentally modify creds, that is, the helper functions prepare_creds(), commit_creds() and abort_creds() always implicitly only work on current.
• Reading: other tasks may access another tasks creds, but only under a RCU read section (and the acquired creds pointer is then only valid within that read section)
  • _task_creds() within a RCU read section
  • convenience functions current_task_uid() and friends acquire the read section, grab the creds pointer, get the UID or another attribute, and release the read section again before returning.