Ubuntu Manpage: keyrings - Kernelinterne Schlüsselverwaltungs- und -beibehaltungseinrichtung

BEZEICHNUNG

       keyrings - Kernelinterne Schlüsselverwaltungs- und -beibehaltungseinrichtung

BESCHREIBUNG

Die Linux-Schlüsselverwaltungseinrichtung ist der primäre Zugang für verschiedene
Kernelkomponenten, um Sicherheitsdaten, Authentifizierungsschlüssel,
Verschlüsselungsschlüssel und andere Daten im Kernel beizubehalten oder
zwischenzuspeichern.

Es werden Systemaufrufschnittstellen bereitgestellt, so dass Programme aus dem
Anwendungsraum diese Objekte verwalten können und die Einrichtung auch für eigene Zwecke
verwenden können; siehe add_key(2), request_key(2) und keyctl(2).

Eine Bibliothek und einige Hilfswerkzeuge im Benutzerraum werden bereitgestellt, um
Zugriff auf die Einrichtung zu erlauben. Siehe keyctl(1), keyctl(3) und keyutils(7) für
weitere Informationen.

Schlüssel
Ein Schlüssel hat die folgenden Attribute:

Seriennummer (ID)
Dies ist ein eindeutiger, ganzzahliger Aufhänger, über den bei Systemaufrufen der
Schlüssel referenziert wird. Die Seriennummer wird manchmal synonym als
Schlüssel-ID bezeichnet. In Programmen wird die Seriennummer durch den Typ
key_serial_t repräsentiert.

Typ Ein Schlüsseltyp definiert, welche Arten an Daten im Schlüssel gehalten werden
können, wie der vorgeschlagene Inhalt des Schlüssels ausgewertet und wie die
Nutzlast verwandt wird.

Es gibt eine Reihe von universellen Typen, sowie einige spezialisierte Typen,
definiert durch bestimmte Kernelkomponenten.

Beschreibung (Name)
Die Schlüsselbeschreibung ist eine darstellbare Zeichenkette, die als Suchausdruck
für den Schlüssel (im Zusammenspiel mit dem Schlüsseltyp) sowie als Anzeigename
verwandt wird. Während des Suchens kann die Beschreibung teilweise oder exakt
übereinstimmen.

Nutzlast (Daten)
Die Nutzlast ist der eigentliche Inhalt eines Schlüssels. Dieser wird normalerweise
gesetzt, wenn ein Schlüssel erzeugt wird, aber es ist möglich, dass der Kernel im
Benutzerraum anfragt, um die Instanziierung eines Schlüssels abzuschließen, falls
der Schlüssel dem Kernel bei der Anfrage noch nicht bekannt war. Weitere Details
finden Sie in request_key(2).

Die Nutzlast eines Schlüssel kann gelesen und aktualisiert werden, falls der
Schlüsseltyp dies unterstützt und falls der Aufrufende ausreichende Berechtigungen
erhalten hat.

Zugriffsrechte
Ähnlich wie bei Dateien hat jeder Schlüssel eine Eigentümer-Benutzerkennung, eine
Eigentümer-Gruppenkennung und eine Sicherheitskennzeichnung. Jeder Schlüssel hat
auch eine Gruppe an Berechtigungen, allerdings gibt es mehr als für eine normale
UNIX-Datei, und es gibt die zusätzliche Kategorie »Besitzer« neben den gewöhnlichen
Benutzer, Gruppe und andere (siehe Besitz weiter unten).

Beachten Sie, dass Schlüssel Kontingenten unterliegen, da sie nicht
auslagerungsfähigen Kernelspeicher benötigen. Die Eigentümer-Benutzerkennung legt
fest, auf wessen Kontingent dies läuft.

Ablaufzeit
Jeder Schlüssel kann über eine Ablaufzeit verfügen. Wenn diese Zeit verstrichen
ist, wird der Schlüssel als abgelaufen markiert und Zugriff darauf schlägt mit
EKEYEXPIRED fehl. Falls er nicht gelöscht, aktualisiert oder ersetzt wird, wird der
abgelaufene Schlüssel nach einer einstellbaren Zeit automatisch gelöscht
(Speicherbereinigung), zusammen mit allen Verweisen darauf, und Zugriffe auf den
Schlüssel schlagen mit dem Fehler ENOKEY fehl.

Referenzzähler
Jeder Schlüssel hat einen Referenzzähler. Schlüssel werden von Schlüsselbunden, von
derzeit aktiven Benutzern und von Anmeldeberechtigungen von Prozessen referenziert.
Wenn dieser Referenzzähler Null erreicht, dann wird der Schlüssel für die
Speicherbereinigung eingeplant.

Schlüsseltypen
Der Kernel stellt mehrere gundlegende Schlüsseltypen bereit:

"keyring"
Schlüsselbunde sind besondere Schlüssel, die eine Gruppe von Verweisen auf andere
Schlüssel (einschließlich anderer Schlüsselbunde) speichern, ähnlich wie ein
Verzeichnis Verweise auf Dateien speichert. Der Hauptzweck eines Schlüsselbundes
ist es, zu verhindern, dass andere Schlüssel aus dem Speicher bereinigt werden,
weil nichts mehr sie referenziert.

Schlüsselbunde mit Beschreibungen (Namen), die mit einem Punkt (».«) beginnen, sind
für die Implementierung reserviert.

"user" Dies ist ein Allzweck-Schlüsseltyp. Der Schlüssel wird im Gesamten im
Kernelspeicher gehalten. Die Nutzlast kann von Anwendungen im Benutzerraum gelesen
und aktualisiert werden.

Die Nutzlast von Schlüsseln dieses Typs ist ein beliebiger Datenblock (blob) mit
bis zu 32.767 byte.

Die Beschreibung kann eine beliebige gültige Zeichenkette sein. Es wird aber
bevorzugt, dass sie mit einem Präfix startet, das durch einen Doppelpunkt
abgetrennt wird, der den Dienst darstellt, für den der Schlüssel von Interesse ist
(beispielsweise "afs:mykey").

"logon" (seit Linux 3.3)
Dieser Schlüsseltyp ist im wesentlichen der gleiche wie "user", er kann aber nicht
gelesen werden (d.h. die Aktion KEYCTL_READ von keyctl(2)). Das bedeutet, dass die
Schlüssel-Nutzlast im Anwendungsraum niemals sichtbar ist. Dies ist für
Benutzername-Passwörter-Paare nützlich, die aus dem Anwendungsraum heraus nicht
lesbar sein sollten.

Die Beschreibung eines "logon"-Schlüssels muss mit einem nicht leeren,
Doppelpunkt-begrenzten Präfix beginnen, dessen Zweck darin besteht, den Dienst zu
identifizieren, dem der Schlüssel gehört. (Beachten Sie, dass sich das von
Schlüsseln des Typs "user" unterscheidet, bei denen die Aufnahme eines Präfix
empfohlen, dies aber nicht erzwungen wird.)

"big_key" (seit Linux 3.13)
Dieser Schlüssel ist ähnlich zum Schlüsseltyp "user", kann aber eine Nutzlast von
bis zu 1 MiB Größe enthalten. Dieser Schlüssel ist für Zwecke wie
Kerberos-Ticket-Zwischenspeicher nützlich.

Die Nutzlastdaten können in einem tmpfs-Dateisystem statt im Kernelspeicher
gespeichert werden, falls die Datengröße die Aufwandskosten des Speicherns der
Daten im Dateisystem übersteigt. (Zum Speichern von Daten in einem Dateisystem muss
der Kernel Dateisystemstrukturen im Kernel reservieren. Die Größe dieser Strukturen
bestimmt den Schwellwert, über dem die Tmpfs-Speichermethode verwandt wird.) Seit
Linux 4.8 werden die Nutzlastdaten beim Speichern im Tmpfs verschlüsselt, wodurch
verhindert wird, dass sie in unverschlüsselten Auslagerungsspeicher geschrieben
werden.

Es sind auch spezialisiertere Schlüsseltypen verfügbar, aber sie werden hier nicht
beschrieben, da sie nicht für den normalen Anwendungsraum gedacht sind.

Schlüsselnamen, die mit einem Punkt (».«) beginnen, sind für die Implementierung
reserviert.

Schlüsselbunde
Wie bereits erwähnt, sind Schlüsselbunde besondere Schlüsseltypen, die Verweise auf andere
Schlüssel enthalten (wozu auch Schlüsselbunde gehören können). Schlüssel können mit
mehreren Schlüsselbunden verbunden sein. Schlüsselbunde können als Analogon zu
UNIX-Verzeichnissen betrachtet werden, bei denen jedes Verzeichnis eine Reihe von harten
Verweisen auf Dateien enthält.

Auf Schlüsselbunde können verschiedene Aktionen (Systemaufrufe) durchgeführt werden:

Hinzufügen
Durch einen Systemaufruf, der Schlüssel erstellt, kann ein Schlüssel zu einem
Schlüsselbund hinzugefügt werden. Dies verhindert, dass ein neuer Schlüssel sofort
gelöscht wird, wenn der Systemaufruf seine letzte Referenz auf den Schlüssel
freigibt.

Verweisen
Ein Verweis kann zu einem Schlüsselbund hinzugefügt werden, der auf einen Schlüssel
zeigt, der bereits bekannt ist, vorausgesetzt, dies erzeugt keinen
selbstreferenzierenden Zyklus.

Verweis entfernen
Ein Verweis kann von einem Schlüsselbund entfernt werden. Wenn der letzte Verweis
auf einen Schlüssel entfernt wurde, wird der Schlüssel zum Löschen durch die
Speicherbereinigung eingeplant.

Bereinigen
Alle Verweise können von einem Schlüsselbund entfernt werden.

Suchen Ein Schlüsselbund kann als Wurzel eines Baums oder Unterbaums betrachtet werden,
bei dem Schlüsselbunde die Zweige und Nicht-Schlüsselbunde die Blätter darstellen.
Dieser Baum kann nach einem Schlüssel durchsucht werden, der auf einen bestimmten
Typ und Beschreibung passt.

Siehe keyctl_clear(3), keyctl_link(3), keyctl_search(3) und keyctl_unlink(3) für weitere
Informationen.

Schlüsselverankerungen
Um zu verhindern, dass ein Schlüssel vom Speicher bereinigt wird, muss er verankert
werden, um seinen Referenzzähler erhöht zu halten, wenn er vom Kernel nicht aktiv benutzt
wird.

Schlüsselbunde werden verwandt, um andere Schlüssel zu verankern: jede Referenz ist eine
Referenz auf einen Schlüssel. Beachten Sie, dass Schlüsselbunde selbst einfach nur
Schlüssel sind und den gleichen Verankerungsanforderungen unterliegen, um zu verhindern,
dass sie speicherbereinigt werden.

Der Kernel stellt eine Reihe von verankerten Schlüsselbunden bereit. Beachten Sie, das
einige dieser Schlüsselbunde erst beim ersten Zugriff erstellt werden.

Prozessschlüsselbunde
Prozesszugangsberechtigungen selbst referenzieren Schlüsselbunde mit spezieller
Semantik. Diese Schlüsselbunde sind angeheftet, solange die Gruppe der
Zugangsberechtigungen existiert. Dies ist normalerweise so lange, wie der Prozess
existiert.

Es gibt drei Schlüsselbunde mit verschiedenen Vererbungs-/Mitbenutzungsregeln:
session-keyring(7) (vererbt an und von allen Kindprozessen mitbenutzt),
process-keyring(7) (vererbt von allen Threads in einem Prozess) und
thread-keyring(7) (spezifisch für einen bestimmten Thread).

Als Alternative zur Verwendung der tatsächlichen Schlüsselbundkennung können die
besonderen Schlüsselbundwerte KEY_SPEC_SESSION_KEYRING, KEY_SPEC_PROCESS_KEYRING
und KEY_SPEC_THREAD_KEYRING in Aufrufen von add_key(2), keyctl(2) und
request_key(2) verwandt werden, um auf die eigenen Instanzen des Aufrufenden von
diesen Schlüsselbunden zu verweisen.

Benutzerschlüsselbunde
Jede dem Kernel bekannte UID hat einen Datensatz, der zwei Schlüsselbunde enthält:
user-keyring(7) und user-session-keyring(7). Diese existieren solange wie der
UID-Datensatz im Kernel existiert.

Als Alternative zur Verwendung der tatsächlichen Schlüsselbundkennungen können bei
Aufrufen von add_key(2), keyctl(2) und request_key(2) die besonderen
Schlüsselbundwerte KEY_SPEC_USER_KEYRING und KEY_SPEC_USER_SESSION_KEYRING verwandt
werden, um auf die eigenen Instanzen des Aufrufenden von diesen Schlüsselbunden zu
verweisen.

Durch pam_keyinit(8) wird ein Verweis auf den Benutzerschlüsselbund in einem neuen
Sitzungsschlüsselbund abgelegt, wenn eine neue Anmeldesitzung begonnen wird.

Dauerhafte Schlüsselbunde
Für jede dem System bekannte UID ist ein persistent-keyring(7) verfügbar. Er kann
über den schon erwähnten UID-Datensatz hinaus bestehen bleiben, hat aber eine
Ablaufzeit gesetzt, so dass er nach einer gesetzten Zeit automatisch bereinigt
wird. Der dauerhafte Schlüsselbund erlaubt beispielsweise cron(8)-Skripten,
Berechtigungsnachweise zu verwenden, die im dauerhaften Schlüsselbund verbleiben,
nachdem sich der Benutzer abgemeldet hat.

Beachten Sie, dass die Ablaufzeit des dauerhaften Schlüsselbundes bei jeder Anfrage
des dauerhaften Schlüssels zurückgesetzt wird.

Besondere Schlüsselbunde
Der Kernel besitzt besondere Schüsselbunde, die Schlüssel für besondere Zwecke
verankern können. Ein Beispiel hiefür ist der Systemschlüsselbund, der für das
Halten der Verschlüsselungsschlüssel für Modulsignaturüberprüfung verwandt wird.

Diese besonderen Schlüsselbunde sind normalerweise für die Bearbeitung aus dem
Anwendungsraum nicht zugänglich.

Ein ursprünglich geplanter »Gruppenschlüsselbund«, zum Speichern von Schlüsseln, die jeder
dem Kernel bekannten GID zugeordnet sind, ist bisher nicht implementiert und wird dies
wahrscheinlich auch nicht. Trotzdem wurde die Konstante KEY_SPEC_GROUP_KEYRING für diesen
Schlüsselbund definiert.

Besitz
Das Konzept des Besitzes ist zum Verständnis des Schlüsselbund-Sicherheitsmodells wichtig.
Ob ein Thread einen Schlüssel besitzt, wird durch folgende Regeln bestimmt:

(1) Jeder Schlüssel oder Schlüsselbund, der dem Aufrufenden keine Such-Berechtigung
gewährt, wird in den folgenden Regeln ignoriert.

(2) Ein Thread besitzt seinen session-keyring(7), process-keyring(7) und
thread-keyring(7) direkt, da diese Schlüsselbunde von seinen Zugangsberechtigungen
referenziert werden.

(3) Falls ein Schlüsselbund besessen wird, dann werden auch alle darin verwiesenen
Schlüssel besessen.

(4) Falls ein Schlüssel, auf den ein Schlüsselbund verweist, selber wieder ein
Schlüsselbund ist, dann gilt Regel (3) rekursiv.

(5) Falls ein Prozess vom Kernel hochgerufen wurde, um einen Schlüssel zu instanziieren
(siehe request_key(2)), dann besitzt er auch den Schlüsselbund des Anfragenden gemäß
Regel (1), als ob er der Anfragende wäre.

Beachten Sie, dass Besitz keine fundamentale Eigenschaft eines Schlüssels ist, sondern
jedesmal bei Bedarf neu berechnet werden muss.

Besitz wurde entwickelt, um es set-user-ID-Programmen zu ermöglichen, beispielsweise von
einer Benutzer-Shell ausgeführt zu werden und auf die Schlüssel des Benutzers zuzugreifen.
Indem Zugriff auf Schlüssel im Besitz erlaubt, aber Zugriff auf Basis des
Schlüsseleigentümers und dessen Gruppe verweigert wird, ist es möglich, den Zugriff auf
Schlüssel auf der Basis von Vergleichen von UID und GID zu vermeiden.

Wenn pam_keyinit(8) einen Sitzungsschlüssel erstellt, fügt es einen Verweis zu dem
user-keyring(7) hinzu und damit gelangt der Benutzerschlüssel und alles was darin ist
standardmäßig in den Besitz.

Zugriffsrechte
Jeder Schlüssel hat die folgenden sicherheitsbezogenen Attribute:

• Die Eigentümer-Benutzerkennung.

• Die Kennung der Gruppe, der Zugriff auf den Schlüssel erlaubt wird.

• Eine Sicherheitskennzeichnung

• Eine Berechtigungsmaske

Diese Berechtigungsmaske enthält vier Gruppen an Rechten. Die ersten drei Gruppen
schließen sich gegenseitig aus. Genau eine wird für eine bestimmte Berechtigungsprüfung
aktiv sein. In absteigender Priorität sind dies die Gruppen:

Benutzer
Diese Gruppe legt die Berechtigungen fest, die gewährt werden, wenn die
Benutzerkennung des Schlüssels auf die Dateisystem-Benutzerkennung des Aufrufenden
passt.

Gruppe Diese Gruppe legt die Berechtigungen fest, die gewährt werden, wenn die
Benutzerkennungen nicht übereinstimmten und die Schlüsselgruppenkennung auf die
Dateisystem-GID des Aufrufenden oder eine der ergänzenden Gruppenkennungen des
Aufrufenden passte.

weitere
Diese Gruppe legt die Berechtigungen fest, die gewährt werden, wenn weder die
Benutzerkennung des Schlüssels noch die Gruppenkennung passt.

Die vierte Gruppe an Berechtigungen ist:

Besitzer
Diese Gruppe legt die Berechtigungen fest, die gewährt werden, wenn der Schlüssel
vom Aufrufenden besessen wird.

Der vollständige Satz an Berechtigungen für einen Schlüssel ist die Vereinigung von der
ersten passenden der drei Gruppen mit der vierten Gruppe, falls der Schlüssel besessen
wird.

Die Gruppe an Rechten, die in jeder der vier Masken gewährt werden können, ist wie folgt:

Betrachten
Die Attribute des Schlüssels können gelesen werden. Dazu gehören der Typ, die
Beschreibung und die Zugriffsrechte (ohne die Sicherheitskennzeichnung).

Lesen Für einen Schlüssel: Die Nutzlast des Schlüssels kann gelesen werden. Für einen
Schlüsselbund: Die Liste der Seriennummern (Schlüssel), die mit dem Schlüsselbund
verbunden sind, kann gelesen werden.

Schreiben
Die Nutzlast des Schlüssels kann aktualisiert werden und der Schlüssel kann
zurückgezogen werden. Für einen Schlüsselbund können Verweise hinzugefügt oder
entfernt werden und der Schlüsselbund kann komplett bereinigt werden (alle Verweise
entfernt).

Suchen Für einen Schlüssel (oder einen Schlüsselbund): Der Schlüssel kann in einer Suche
gefunden werden. Für einen Schlüsselbund: Schlüssel und Schlüsselbunde, auf die
verwiesen wird, können durchsucht werden.

Verweisen
Von Schlüsselbunden können Verweise auf Schlüssel erstellt werden. Der anfängliche
Verweis auf einen Schlüssel, der bei der Schlüsselerstellung etabliert wird,
benötigt diese Berechtigung nicht.

Attributsetzen
Die Details zum Eigentümer und der Sicherheitskennzeichnung können geändert werden,
die Ablaufzeit des Schlüssels kann gesetzt werden und der Schlüssel kann
zurückgezogen werden.

Zusätzlich zu den Zugriffsrechten kann jedes aktive Linux-Sicherheitsmodul (LSM) den
Zugriff auf einen Schlüssel verhindern, falls die Richtlinie das vorgibt. Ein Schlüssel
kann durch das LSM eine Sicherheitskennzeichnung oder andere Attribute erhalten; dieses
Kennzeichen kann mit keyctl_get_security(3) ermittelt werden.

Siehe keyctl_chown(3), keyctl_describe(3), keyctl_get_security(3), keyctl_setperm(3) und
selinux(8) für weitere Informationen.

Schlüssel suchen
Eine der zentralen Funktionalitäten der Schlüsselverwaltungseinrichtung von Linux ist die
Fähigkeit, einen Schlüssel zu finden, den ein Prozess aufbewahrt. Der Systemaufruf
request_key(2) ist der primäre Zugriffspunkt für Anwendungen aus dem Benutzerraum, um den
Schlüssel zu finden. (Intern steht dem Kernel etwas ähnliches für interne Komponenten, die
Schlüssel verwenden, zur Verfügung.)

Der Suchalgorithmus funktioniert wie folgt:

(1) Die Prozessschlüsselbunde werden in der folgenden Reihenfolge durchsucht: der
thread-keyring(7), falls er existiert, dann entweder der session-keyring(7), falls er
existiert, oder user-session-keyring(7), falls dieser existiert.

(2) Falls der Aufrufende ein Prozess war, der mittels des Hochruf-Mechanismus
request_key(2) aktiviert wurde, dann werden die Schlüsselbunde der ursprünglichen
Aufrufenden von request_key(2) auch durchsucht.

(3) Das Durchsuchen eines Schlüsselbundbaums ist eine Breitensuche: jeder Schlüsselbund
wird zuerst auf einen Treffer durchsucht, dann werden die Schlüsselbunde durchsucht,
auf die der erste Schlüsselbund verweist.

(4) Falls ein passender Schlüssel gefunden wird, der gültig ist, dann wird die Suche
beendet und der Schlüssel zurückgeliefert.

(5) Falls ein passender Schlüssel gefunden wird, an dem ein Fehlerzustand hängt, dann
wird dieser Fehlerzustand notiert und mit der Suche fortgefahren.

(6) Falls kein gültiger Schlüssel gefunden wird, dann wird der zuerst notierte
Fehlerzustand zurückgeliefert; andernfalls wird der Fehler ENOKEY zurückgeliefert.

Es kann auch nach einem bestimmten Schlüsselbund gesucht werden, dann gelten nur die
Schritte (3) bis (6).

Siehe request_key(2) und keyctl_search(3) für weitere Informationen.

Bedarfsgesteuerte Schlüsselerstellung
Falls ein Schlüssel nicht gefunden werden kann, wird request_key(2) einen neuen Schlüssel
erzeugen, falls das Argument callout_info angegeben wurde, und dann in den Benutzerraum
hochrufen, um den Schlüssel zu instanziieren. Damit ist es möglich, Schlüssel
bedarfsgesteuert zu erstellen.

Typischerweise beteiligt dies den Kernel, der einen neuen Prozess erzeugt, der das
Programm request-key(8) ausführt, das dann den geeigneten Handler basierend auf seiner
Konfiguration ausführt.

Dem Handler wird ein besonderer Autorisierungsschlüssel übergeben, der es ihm und nur ihm
erlaubt, den neuen Schlüssel zu instanziieren. Dies wird auch dazu verwandt, Suchen durch
das Handler-Programm zu erlauben, die auch die Schlüsselbunde des Anfragenden durchsuchen.

Siehe request_key(2), keyctl_assume_authority(3), keyctl_instantiate(3), keyctl_negate(3),
keyctl_reject(3), request-key(8) und request-key.conf(5) für weitere Informationen.

/proc-Dateien
Der Kernel stellt verschiedene /proc-Dateien bereit, die Informationen über Schlüssel
offenlegen oder Beschränkungen für die Verwendung von Schlüsseln definieren.

/proc/keys (seit Linux 2.6.10)
Diese Datei legt eine Liste von Schlüsseln offen, für die der lesende Thread die
Betrachten-Berechtigung hat und stellt verschiedene Informationen über jeden
Schlüssel bereit. Der Thread muss den Schlüssel nicht besitzen, damit er in dieser
Datei sichtbar ist.

Die einzigen in dieser Liste aufgenommenen Schlüssel sind diejenigen, die dem
lesenden Prozess die Betrachten-Berechtigung gewähren (unabhängig davon, ob er sie
besitzt oder nicht). LSM-Sicherheitsüberprüfungen werden weiterhin durchgeführt und
könnten weitere Schlüssel herausfiltern, für die dem Prozess die Autorisierung zur
Betrachtung fehlt.

Nachfolgend ein Beispiel für die Daten, die Sie in der Datei sehen können (wobei
die Spalten für einfachere Bezüge nachfolgend nummeriert sind):

(1) (2) (3)(4) (5) (6) (7) (8) (9)
009a2028 I--Q--- 1 perm 3f010000 1000 1000 user krb_ccache:primary: 12
1806c4ba I--Q--- 1 perm 3f010000 1000 1000 keyring _pid: 2
25d3a08f I--Q--- 1 perm 1f3f0000 1000 65534 keyring _uid_ses.1000: 1
28576bd8 I--Q--- 3 perm 3f010000 1000 1000 keyring _krb: 1
2c546d21 I--Q--- 190 perm 3f030000 1000 1000 keyring _ses: 2
30a4e0be I------ 4 2d 1f030000 1000 65534 keyring _persistent.1000: 1
32100fab I--Q--- 4 perm 1f3f0000 1000 65534 keyring _uid.1000: 2
32a387ea I--Q--- 1 perm 3f010000 1000 1000 keyring _pid: 2
3ce56aea I--Q--- 5 perm 3f030000 1000 1000 keyring _ses: 1

Die in jeder Zeile dieser Datei gezeigten Felder sind wie folgt:

KENNUNG (1)
Die Kennung (Seriennummer) des Schlüssels, hexadezimal dargestellt.

Schalter (2)
Eine Gruppe von Schaltern, die den Status des Schlüssels beschreiben:

I Der Schlüssel wurde instanziiert.

R Der Schlüssel wurde zurückgezogen.

D Der Schlüssel ist tot (d.h. die Registrierung des Schlüsseltyps wurde
aufgehoben). (Während der Speicherbereinigung kann ein Schlüssel
kurzfristig in diesem Zustand sein).

Q Der Schlüssel wird für das Benutzerkontingent berücksichtigt.

U Der Schlüssel wird derzeit über einen Rückruf zum Anwendungsraum
konstruiert; siehe request-key(2).

N Der Schlüssel wird negativ instanziiert.

i Der Schlüssel wurde entwertet.

Einsatz (3)
Dies ist die Anzahl der Kernelzugangsberechtigungsstrukturen, die den
Schlüssel anheften (ungefähr: die Anzahl der Threads und offenen
Dateireferenzen, die sich auf diesen Schlüssel beziehen).

Zeitüberschreitung (4)
Die Zeitdauer, bis der Schlüssel ablaufen wird, ausgedrückt in
menschenlesbarer Form (Wochen, Tage, Stunden, Minuten und Sekunden). Die
Zeichenkette perm bedeutet hier, dass der Schlüssel permanent ist (keine
Zeitüberschreitung). Die Zeichenkette expd bedeutet, dass der Schlüssel
bereits abgelaufen ist, aber die Speicherbereinigung noch nicht erfolgte.

Berechtigungen (5)
Die Schlüsselberechtigungen, ausgedrückt in vier hexadezimalen Bytes, die
von links nach rechts den Besitzer, den Benutzer, die Gruppe und andere
Berechtigungen enthalten. Innerhalb jedes Bytes sind die Berechtigungsbits
wie folgt:

0x01 Betrachten
0x02 Lesen
0x04 Schreiben
0x08 Suchen
0x10 Verweisen
0x20 Attributsetzen

UID (6)
Die Benutzerkennung des Schlüsseleigentümers.

GID (7)
Die Gruppenkennung des Schlüssels. Hier bedeutet der Wert -1, dass der
Schlüssel keine Gruppenkennung hat. Dies kann unter bestimmten Umständen bei
vom Kernel erstellten Schlüsseln auftreten.

Typ (8)
Der Schlüsseltyp (Benutzer, Schlüsselbund, usw.)

Beschreibung (9)
Die Schlüsselbeschreibung (Name). Dieses Feld enthält eine beschreibende
Information über den Schlüssel. Für die meisten Schlüsseltypen hat es die
folgende Form:

Name[: Extra-info]

Das Unterfeld Name ist die Schlüsselbeschreibung (der Name). Das optionale
Feld Extra-Info stellt einige weitere Informationen über den Schlüssel
bereit. Die hier auftauchende Information hängt vom Schlüsseltyp wie folgt
ab:

"user" und "logon"
Die Größe in Byte der Schlüsselnutzlast (dezimal dargestellt).

"keyring"
Die Anzahl der Schlüssel, auf die vom Schlüsselbund verwiesen wird,
oder die Zeichenkette empty, falls es keine Schlüssel gibt, auf die
vom Schlüsselbund verwiesen wird.

"big_key"
Die Nutzlastgröße in Byte, gefolgt entweder von der Zeichenkette
[file], falls die Schlüsselnutzlast den Schwellwert übersteigt, was
bedeutet, dass die Nutzlast in einem (auslagerungsfähigen)
tmpfs(5)-Dateisystem gespeichert ist, oder der Zeichenkette [buff],
die anzeigt, dass der Schlüssel klein genug ist, um sich im
Kernelspeicher zu befinden.

Für den Schlüsseltyp ".request_key_auth" (Autorisierungsschlüssel, siehe
request_key(2)) hat das Beschreibungsfeld die im folgenden Beispiel gezeigte
Form:

key:c9a9b19 pid:28880 ci:10

Die drei Unterfelder sind wie folgt definiert:

key Die hexadezimale Kennung des Schlüssels, der im anfragenden Programm
instanziiert wird.

pid Die PID (Prozesskennung) des anfragenden Programms.

ci Die Länge der Abrufdaten, mit denen der angefragte Schlüssel
instanziiert werden soll (d.h. die Länge der Nutzlast, die dem
Autorisierungsschlüssel zugeordnet ist).

/proc/key-users (seit Linux 2.6.10)
Diese Datei listet verschiedene Informationen über jede Benutzerkennung auf, die im
System mindestens einen Schlüssel hat. Beispielsweise könnten Sie in dieser Datei
Folgendes sehen:

0: 10 9/9 2/1000000 22/25000000
42: 9 9/9 8/200 106/20000
1000: 11 11/11 10/200 271/20000

Die Bedeutung der Felder in jeder Zeile im Einzelnen:

UID Die Benutzerkennung.

Verwendung
Dies ist ein kernelinterner Verwendungszähler für die Kernelstruktur, die
zur Aufzeichnung der Schlüsselbenutzer verwandt wird.

GAnzSchlüssel/AnzISchlüssel
Die Gesamtanzahl der von diesem Benutzer besessenen Schlüssel und die Anzahl
dieser Schlüssel, die instanziiert wurden.

AnzSchlüssel/Maxschlüssel
Die Anzahl der Schlüssel, die dieser Benutzer besitzt und die maximale
Anzahl der Schlüssel, die der Benutzer besitzen kann.

AnzBytes/MaxBytes
Die Anzahl an Bytes, die in Nutzlasten von Schlüsseln, die im Besitz dieses
Benutzers sind, konsumiert wurden und die obere Grenze der Anzahl an Bytes,
die in Schlüsselnutzlasten für diesen Benutzer möglich sind.

/proc/sys/kernel/keys/gc_delay (seit Linux 2.6.32)
Der Wert in dieser Datei legt das Intervall in Sekunden fest, nachdem
zurückgezogene und abgelaufene Schlüssel der Speicherbereinigung unterliegen. Der
Zweck für ein solches Intervall besteht darin, dass es ein Zeitfenster gibt, in dem
der Anwendungsraum einen Fehler sehen kann (EKEYREVOKED bzw. EKEYEXPIRED), der
anzeigt, was mit dem Schlüssel passierte.

Der Vorgabewert in dieser Datei ist 300 (d.h. 5 Minuten).

/proc/sys/kernel/keys/persistent_keyring_expiry (seit Linux 3.13)
Diese Datei definiert ein Intervall in Sekunden, auf das die
Ablauf-Zeitüberschreitung bei jedem Zugriff auf den dauerhaften Schlüsselbund
zurückgesetzt wird (mittels keyctl_get_persistent(3) oder der Aktion
KEYCTL_GET_PERSISTENT von keyctl(2)).

Der Vorgabewert in dieser Datei ist 259200 (d.h. 3 Tage).

Die folgenden Dateien (die von privilegierten Prozessen schreibbar sind) werden zur
Durchsetzung von Kontingenten zur Anzahl der Schlüssel und der Anzahl an Daten-Bytes, die
in der Schlüsselnutzlast gespeichert werden können, verwandt:

/proc/sys/kernel/keys/maxbytes (seit Linux 2.6.26)
Dies ist die maximale Anzahl an Daten-Bytes, die ein von Root verschiedener
Benutzer in Nutzlasten in Schlüsseln, die ihm gehören, halten kann.

Der Vorgabewert in dieser Datei ist 20.000.

/proc/sys/kernel/keys/maxkeys (seit Linux 2.6.26)
Dies ist die maximale Anzahl an Schlüsseln, die ein von root verschiedener Benutzer
besitzen kann.

Der Vorgabewert in dieser Datei ist 200.

/proc/sys/kernel/keys/root_maxbytes (seit Linux 2.6.26)
Dies ist die maximale Anzahl an Daten-Bytes, die der Benutzer root (UID 0 in dem
Wurzelbenutzernamensraum) in der Nutzlast der Schlüssel, die root gehören, halten
kann.

Der Vorgabewert in dieser Datei ist 25.000.000 (20.000 vor Linux 3.17).

/proc/sys/kernel/keys/root_maxkeys (seit Linux 2.6.26)
Dies ist die maximale Anzahl von Schlüsseln, die der Benutzer root (UID 0 in dem
Wurzelbenutzernamensraum) besitzen kann.

Der Vorgabewert in dieser Datei ist 1.000.000 (200 vor Linux 3.17).

Beachten Sie, dass in Bezug auf Schlüsselbunde jeder Verweis 4 byte der
Schlüsselbundnutzlast verbraucht.

Benutzer
Die Schlüsselverwaltungseinrichtung von Linux hat eine Reihe von Benutzern und
Verwendungen, aber sie ist nicht auf die bereits existierenden beschränkt.

Kernelinterne Benutzer dieser Einrichtung sind unter anderem:

Netzwerkdateisystem - DNS
Der Kernel verwendet den durch die Schlüssel bereitgestellten Hochruf-Mechanismus,
um im Benutzerraum hochzurufen, DNS-Nachschlagen durchzuführen und die Ergebnisse
zwischenzuspeichern.

AF_RXRPC und kAFS - Authentifizierung
Das Netzwerkprotokoll AF_RXRPC und das kernelinterne AFS-Dateisystem verwenden
Schlüssel, um die benötigten Tickets für gesicherten oder verschlüsselten
Datenverkehr zu speichern. Diese werden dann bei Netzwerkaktionen für AF_RXRPC- und
Dateisystem-Aktionen bei kAFS nachgeschlagen.

NFS - Benutzerkennungsabbildung
Das NFS-Dateisystem verwendet Schlüssel, um Abbildungen von fremden
Benutzerkennungen auf lokale Benutzerkennungen zu speichern.

CIFS - Passwort
Das CIFS-Dateisystem verwendet Schlüssel, um Passwörter für den Zugriff auf ferne
Laufwerksfreigaben zu speichern.

Modulüberprüfung
Der Kernel-Bauprozess kann Module kryptographisch signieren. Diese Signatur wird
beim Laden des Moduls überprüft.

Anwendungsraum-Benutzer dieser Einrichtung sind unter anderem:

Kerberos-Schlüsselspeicher
Die MIT-Kerberos-5-Einrichtung (libkrb5) kann Schlüssel verwenden, um
Authentifizierungs-Merkmale zu speichern, die dann so eingerichtet werden können,
dass sie nach einer bestimmten Zeit nach der letzten Verwendung automatisch
bereinigt werden, aber bis dahin vorhanden sein können, nachdem der Benutzer sich
abgemeldet hat, so dass cron(8)-Skripte sie verwenden können.

SIEHE AUCH

       keyctl(1), add_key(2), keyctl(2), request_key(2), keyctl(3), keyutils(7),
       persistent-keyring(7), process-keyring(7), session-keyring(7), thread-keyring(7),
       user-keyring(7), user-session-keyring(7), pam_keyinit(8), request-key(8)

       Die Kernel-Quelldateien Documentation/crypto/asymmetric-keys.txt und unter
       Documentation/security/keys (oder in der Datei Documentation/security/keys.txt vor Linux
       4.13).

ÜBERSETZUNG

       Die deutsche Übersetzung dieser Handbuchseite wurde von Helge Kreutzmann
       <debian@helgefjell.de> erstellt.

       Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License
       Version 3 ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ oder neuer bezüglich der Copyright-
       Bedingungen. Es wird KEINE HAFTUNG übernommen.

       Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-
       Mail an die Mailingliste der Übersetzer ⟨debian-l10n-german@lists.debian.org⟩.