Provided by: manpages-de_4.21.0-2_all bug

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