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.
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.
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.