keyrings - Kernel-interne Schlüsselverwaltungs- und
-beibehaltungseinrichtung
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
Die deutsche Übersetzung dieser Handbuchseite wurde von Helge Kreutzmann
<
[email protected]> erstellt.
Diese Übersetzung ist Freie Dokumentation; lesen Sie die
GNU
General Public License Version 3 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