Manpages

BEZEICHNUNG

capabilities - Überblick über Linux-Capabilities

BESCHREIBUNG

Für den Zweck der Durchführung von Rechteprüfungen unterscheiden traditionelle UNIX-Implementierungen zwei Arten von Prozessen: Privilegierte Prozesse (deren effektive Benutzerkennung 0 ist, auch als Superuser oder Root benannt) und unprivilegierte Prozesse (deren effektive UID von Null verschieden ist). Privilegierte Prozesse übergehen alle Kernel-Rechteprüfungen, während unprivilegierte Prozesse der vollen Rechteprüfung, basierend auf den Berechtigungsnachweisen des Prozesses (normalerweise: effektive UID, effektive GID und ergänzende Gruppenliste), unterliegen.

Beginnend mit Kernel 2.2 unterteilt Linux die Privilegien, die traditionell mit dem Superuser assoziiert sind, in getrennte Einheiten, die als Capabilities bekannt sind. Diese können unabhängig voneinander aktiviert oder deaktiviert werden. Capabilities sind ein Attribut pro Thread.

Liste der Capabilities
Die folgende Liste zeigt die in Linux implementierten Capabilities und die Aktionen oder Verhalten, die jede Capability erlaubt:
CAP_AUDIT_CONTROL (seit Linux 2.6.11)

Kernel-Auditierung aktivieren und deaktivieren; die Auditierung-Filterregel ändern; den Auditstatus und Filterregel abfragen.

CAP_AUDIT_READ (seit Linux 3.16)

Erlaubt das Schreiben des Audit-Protokolls über einen Multicast-Netlink-Socket.

CAP_AUDIT_WRITE (seit Linux 2.6.11)

Datensätze in das Audit-Protokoll des Kernels schreiben.

CAP_BLOCK_SUSPEND (seit Linux 3.5)

Funktionalitäten einsetzen, die die System-Supsendierung blockieren können (epoll(7) EPOLLWAKEUP, /proc/sys/wake_lock).

CAP_CHOWN

beliebige Änderungen an Datei-UIDs und GIDs vornehmen (siehe chown(2)).

CAP_DAC_OVERRIDE

Lese-, Schreibe und Ausführrechteprüfungen umgehen. (DAC ist die Abkürzung für »discretionary access control«, benutzerbestimmbare Zugriffssteuerung)

CAP_DAC_READ_SEARCH

CAP_FOWNER

CAP_FSETID

CAP_IPC_LOCK

Speicher sperren (mlock(2), mlockall(2), mmap(2), shmctl(2)).

CAP_IPC_OWNER

Rechteprüfungen für Aktionen mit System-V-IPC-Objekten umgehen.

CAP_KILL

Rechteprüfungen beim Senden von Signalen umgehen (siehe kill(2)). Dies schließt die ioctl(2)-KDSIGACCEPT-Aktion mit ein.

CAP_LEASE (seit Linux 2.4)

Etabliert Ausleihen für beliebige Dateien (siehe fcntl(2)).

CAP_LINUX_IMMUTABLE

Setzt die Inode-Schalter FS_APPEND_FL und FS_IMMUTABLE_FL (siehe ioctl_iflags(2)).

CAP_MAC_ADMIN (seit Linux 2.6.25)

MAC-Konfiguration oder Statusänderungen erlauben. Implementiert für das Smack-Linux-Security-Modul (LSM).

CAP_MAC_OVERRIDE (seit Linux 2.6.25)

Mandatory Access Control (MAC) außer Kraft setzen. Für das Smack-LSM implementiert.

CAP_MKNOD (seit Linux 2.4)

Spezielle Dateien mittels mknod(2) erstellen.

CAP_NET_ADMIN

Verschiedene Netz-bezogene Aktionen durchführen:

CAP_NET_BIND_SERVICE

Einen Socket an einen privilegierten Internet-Domain-Port binden (Portnummern kleiner als 1024).

CAP_NET_BROADCAST

(Unbenutzt) Socket-Broadcasts durchführen und auf Multicasts warten.

CAP_NET_RAW

CAP_SETGID

CAP_SETFCAP (seit Linux 2.6.24)

Setzt beliebige Capabilities auf einer Datei.

CAP_SETPCAP

Falls Datei-Capabilites unterstützt werden (d.h. seit Linux 2.6.24): Füge alle Capabilities aus der Begrenzungsmenge des Threads zu der vererbbaren Menge hinzu; entferne Capabilities aus der Begrenzungsmenge (via prctl(2) PR_CAPBSET_DROP); nehme Änderungen an den securebits-Schaltern vor.

Falls Datei-Capabilites nicht unterstützt werden (d.h. Kernel vor Linux 2.6.24): eine Capability in der erlaubten Capability-Menge oder von anderen Prozessen entfernen oder dafür bewilligen. (Diese Eigenschaft von CAP_SETPCAP ist nicht verfügbar, falls der Kernel für die Unterstützung von Datei-Capabilities konfiguriert ist, da CAP_SETPCAP für diese Kernel eine komplett andere Semantik aufweist.)

CAP_SETUID

CAP_SYS_ADMIN

Hinweis: Diese Capability ist überladen, siehe Hinweise für Kernel-Entwickler weiter unten.

CAP_SYS_BOOT

reboot(2) und kexec_load(2) verwenden.

CAP_SYS_CHROOT

CAP_SYS_MODULE

CAP_SYS_NICE

CAP_SYS_PACCT

acct(2) verwenden.

CAP_SYS_PTRACE

CAP_SYS_RAWIO

CAP_SYS_RESOURCE

CAP_SYS_TIME

Systemuhr setzen (settimeofday(2), stime(2), adjtimex(2)); Echtzeit- (Hardware-)Uhr setzen.

CAP_SYS_TTY_CONFIG

vhangup(2) einsetzen; verschiedene privilegierte ioctl(2)-Aktionen auf virtuelle Terminals einsetzen.

CAP_SYSLOG (seit Linux 2.6.37)

CAP_WAKE_ALARM (seit Linux 3.0)

Etwas auslösen, dass das System aufwecken wird (siehe die Timer CLOCK_REALTIME_ALARM und CLOCK_BOOTTIME_ALARM).

Frühere und heutige Implementierungen
Eine komplette Implementierung von Capabilities verlangt folgendes:

Vor Kernel 2.6.24 waren nur die ersten zwei dieser Anforderungen erfüllt, seit Kernel 2.6.24 sind alle drei Anforderungen erfüllt.

Hinweise für Kernel-Entwickler
Wenn Sie eine neue Kernel-Funktionalität hinzufügen, die über eine Capability geregelt werden soll, beachten Sie die nachfolgenden Punkte.

Capability-Mengen von Threads
Jeder Thread hat die folgenden Capability-Mengen, die null oder mehr der oben aufgeführten Capabilities enthalten:
Permitted (erlaubt)

Dies ist die begrenzende Übermenge für die effektiven Capabilities, die ein Thread annehmen kann. Es ist auch die begrenzende Übermenge für die Capabilites, die zu der vererbbaren Menge durch einen Thread hinzugefügt werden dürfen, der nicht die Capability CAP_SETPCAP in seiner effektiven Menge hat.

Falls ein Thread eine Capability aus seiner erlaubten Menge entfernt, kann es diese Capability niemals wiedererlangen (außer es führt ein Set-User-ID-Root-Programm mit execve(2) aus oder ein Programm, dessen zugeordnete Datei-Capabilities diese Capability wieder bewilligen).

Inheritable (vererbbar)

Dies ist eine Menge von Capabilities, die über execve(2) hinweg erhalten bleiben. Vererbbare Capabilities bleiben bei der Ausführung jedes Programms vererbbar und vererbbare Capbabilities werden zu der erlaubten Menge bei der Ausführung eines Programms, das die entsprechenden Bits in der Datei-Vererbbaren-Menge gesetzt hat, hinzugefügt.

Da vererbbare Capabilities im allgemeinen nicht über execve(2)-Aufrufe erhalten werden, wenn dies nicht als Benutzer root erfolgt, sollten Anwendungen, die Hilfsprogramme mit erhöhten Capabilities ausführen wollen, die Verwendung der unten beschriebenen Umgebungs-Capabilities in Betracht ziehen.

Effective (effektiv)

Dies ist die Menge an Capabilities, der vom Kernel zur Durchführung von Rechteprüfungen für den Thread verwandt wird.

Bounding (pro-Thread seit Linux 2.6.25)

Die Capability-Begrenzungsmenge ist ein Mechanismus, der zur Begrenzung der Capabilities, die während eines execve(2) erlangt werden, dienen kann.

Seit Linux 2.6.25 ist dies eine pro-Thread-Capability-Menge. In älteren Kerneln war die Capability-Begrenzungsmenge ein systemweites Attribut, das von allen Threads des Systems gemeinsam benutzt wurde.

Für weitere Details über die Capability-Begrenzungsmenge, siehe unten.

Ambient (Umgebung) (seit Linux 4.3)

Dies ist eine Menge von Capabilities, die über execve(2) eines nicht privilegierten Programms hinweg erhalten bleiben. Die Umgebungs-Capability-Menge folgt der Invarianz, dass keine Capability jemals eine Umgebungs-Capability sein kann, falls sie nicht sowohl erlaubt als auch vererbbar ist.

Die Umgebungs-Capability-Menge kann direkt mit prctl(2) verändert werden. Umgebungs-Capabilities werden automatisch abgesenkt, falls entweder die entsprechende erlaubte oder vererbbare Capability abgesenkt wird.

Wird ein Programm ausgeführt, das die UID oder GID aufgrund von set-user-ID- oder set-group-ID-Bits ändert oder das über eine Menge an Datei-Capabilities verfügt, dann wird die Umgebungsmenge geleert. Umgebungs-Capabilities werden zu der erlaubten Menge hinzugefügt und der effektiven Menge zugewiesen, wenn execve(2) aufgerufen wird. Falls Umgebungs-Capabilities dazu führen, dass die erlaubten und effektiven Capabilities während eines execve(2) anwachsen, löst dies keinen sicheren Ausführmodus, wie in ld.so(8) beschrieben, aus.

Ein mittels fork(2) erstelltes Kind erbt Kopien der Eltern-Capability-Menge. Lesen Sie weiter unten eine Diskussion der Behandlung von Capabilities während execve(2).

Mittels capset(2) kann ein Thread seine eigenen Capability-Mengen bearbeiten (siehe unten).

Seit Linux 3.2 legt die Datei /proc/sys/kernel/cap_last_cap den numerischen Wert der höchsten vom laufenden Kernel unterstützten Capability offen. Dies kann zur Bestimmung des höchsten Bits, das in einer Capability-Gruppe gesetzt werden kann, genutzt werden.

Datei-Capabilities
Seit Kernel 2.6.24 unterstützt der Kernel die Zuordnung von Capability-Mengen zu einer ausführbaren Datei mittels setcap(8). Die Datei-Capability-Mengen werden in erweiterten Attributen namens security.capability gespeichert (siehe setxattr(2) und xattr(7)). Das Schreiben in diese erweiterten Attribute benötigt die Capability CAP_SETFCAP. Die Datei-Capability-Mengen bestimmen zusammen mit den Capability-Mengen des Threads die Capabilities nach einem execve(2).

Die drei Datei-Capabilities-Mengen sind:
Permitted (erlaubt, früher als forced (erzwungen) bekannt):

Diese Capabilities werden dem Thread automatisch erlaubt, unabhängig von den geerbten Capabilities des Threads.

Inheritable (vererbbar, früher als allowed (erlaubt) bekannt):

Diese Menge wird mittels AND mit der vererbbaren Menge des Threads verknüpft, um zu bestimmen, welche vererbbaren Capabilities in der erlaubten Menge des Threads nach einem execve(2) aktiviert werden.

Effective (effektiv):

Dies ist keine Menge, sondern eher ein einziges Bit. Falls dieses Bit gesetzt ist, dann werden während eines execve(2) die gesamten erlaubten Capabilties für den Thread in die effektive Menge hochgezogen. Falls dieses Bit nicht gesetzt ist, dann wird nach einem execve(2) keine der erlaubten Capabilities in der neuen effektiven Menge sein.

Aktivieren des effektiven Datei-Capability-Bits impliziert, dass jede erlaubte oder vererbte Datei-Capability, die dazu führt, dass ein Thread die entsprechende erlaubte Capability während eines execve(2) erlangt (siehe die oben beschriebenen Transformationsregeln), auch dazu führt, dass er die Capability in seiner effektiven Menge erlangt. Werden daher Capabilities zu einer Datei zugeweisen ((setcap(8), cap_set_file(3), cap_set_fd(3)), falls der effektive Schalter für irgendeine Capability aktiviert ist, dann muss der effektive Schalter auch als aktiviert für alle anderen Capabilities, für die die entsprechenden erlaubten oder vererbbaren Schalter aktiviert sind, spezifiziert werden.

Erweiterte Attributversionierung von Datei-Capabilities
Um Erweiterbarkeit zu erlauben, unterstützt der Kernel ein Schema, um eine Versionsnummer innerhalb des erweiterten Attributs security.capability zu kodieren, die zur Implementierung von Datei-Capabilities verwandt wird. Diese Versionsnummern sind implementierungsintern und für Benutzerraum-Anwendungen nicht direkt sichtbar. Derzeit werden die folgenden Versionen untersützt:
VFS_CAP_REVISION_1

Dies war die ursprüngliche Datei-Capability-Implementierung, die 32-Bit-Masken für Datei-Capabilities unterstützte.

VFS_CAP_REVISION_2 (seit Linux 2.6.25)

Diese Version erlaubt Datei-Capability-Masken in der Größe von 64 Bit und wurde notwendig, da die Anzahl an unterstützen Capabilities 32 überstieg. Der Kernel unterstützt weiterhin transparent die Ausführung von Dateien mit 32-Bit-Version-1-Capability-Masken, aber wenn Capabilities zu Dateien hinzugefügt werden, die bisher keine Capabilities hatten, oder Capabilities von bestehenden Dateien geändert werden, wird automatisch das Version-2-Schema (oder möglicherweise das unten beschriebene Version-3-Schema) verwandt.

VFS_CAP_REVISION_3 (seit Linux 4.14)

Version-3-Datei-Capabilities werden zur Unterstützung von (nachfolgend beschriebenen) namensraumbezogenen Datei-Capabilities bereitgestellt.

Wie bei Version-2-Datei-Capabilities sind die Version-3-Capability Masken 64 Bit groß. Aber zusätzlich wird die Wurzelbenutzerkennung des Namensraums in dem erweiterten Attribut security.capability kodiert. (Eine Namensraum-Wurzelbenutzerkennung ist der Wert, auf den die Benutzerkennung 0 innerhalb dieses Namensraums in dem ursprünglichen Namensraum abgebildet wird.)

Version-3-Datei-Capabilities sind so entwickelt worden, dass sie mit Version-2-Capabilities koexistieren können, d.h. auf einem modernen Linux-System können einige Dateien Version-2-Capabilities tragen, während andere Version-3-Capabilities haben.

Vor Linux 4.14 war die einzige Art des erweiterten Attributs für Datei-Capabilities, die an eine Datei angehängt werden konnten, ein VFS_CAP_REVISION_2-Attribut. Seit Linux 4.14 hängt die Version des erweiterten Attributs security.capability, die an eine Datei angehängt werden kann, von den Umständen ab, unter denen das Attribut erstellt wurde.

Seit Linux 4.14 wird ein erweitertes Attribut security.capability automatisch als ein Version-3-(VFS_CAP_REVISION_3)-Attribut erstellt (oder in ein solches umgewandelt), falls beide folgenden Punkte zutreffen:

Wenn ein erweitertes Attribut VFS_CAP_REVISION_3 security.capability erstellt wird, wird die Wurzelbenutzerkennung des erstellenden Namensraums des Benutzers in dem erweiterten Attribut gespeichert.

Im Gegensatz dazu wird beim Erstellen oder Verändern eines erweiterten Attributs security.capability aus einem privilegierten (CAP_SETFCAP) Thread, der sich in dem Namensraum befindet, unter dem das darunterliegende Dateisystem eingehängt wurde (dies bedeutet normalerweise den anfänglichen Benutzernamensraum), automatisch zu der Erstellung eines Version-2-(VFS_CAP_REVISION_2)-Attributs führen.

Beachten Sie, dass die Erstellung von erweiterten Version 3-security.capability-Attributen automatisch erfolgt. Mit anderen Worten: Der Kernel wird automatisch ein Version-3-Attribut erstellen, falls das Attribut unter den oben beschriebenen Umständen erstellt wird, wenn eine Anwendung im Benutzerraum ein security.capability-Attribut im Version-2-Format schreibt (setxattr(2)). Entsprechend wird das zurückgelieferte Attribut (automatisch) vereinfacht, um als Version-2-Attribut zu erscheinen (d.h. der Rückgabewert ist die Größe eines Version-2-Attrbutes und enthält nicht die Root-Benutzerkennung), wenn ein Version-3-security.capability-Attribut durch einen Prozess, der sich innerhalb eines Benutzernamensraums befindet, der durch die Root-Benutzerkennung (oder einem Abkömling dieses Namensraums) erstellt wurde, abgefragt wird. Diese automatische Übersetzung bedeutet, dass an den Werkzeugen im Benutzerraum (z.B. setcap(1) und getcap(1)) keine Änderung vorgenommen werden muss, damit diese Werkzeuge zum Erstellen und Abfragen von Version-3-security.capability-Attributen verwandt werden können.

Beachten Sie, dass der Datei entweder ein erweitertes Attribut security.capability der Version 2 oder 3 zugeordnet werden kann, aber nicht beide: Erstellung oder Änderung des erweiterten Attributs security.capability wird automatisch die Version abhängig von den Umständen, in denen das erweiterte Attribut erstellt oder verändert wird, anpassen.

Umwandlungen von Capabilities während execve()
Während eines execve(2) berechnet der Kernel die neuen Capabilities eines Prozesses mit dem folgenden Algorithmus:

P’(ambient)     = (Datei ist privilegiert) ? 0 : P(ambient)

P’(permitted)   = (P(inheritable) & F(inheritable)) |
                  (F(permitted) & P(bounding)) | P’(ambient)

P’(effective)   = F(effective) ? P’(permitted) : P’(ambient)

P’(inheritable) = P(inheritable)    [d.h. unverändert]


P’(bounding)    = P(bounding)       [d.h. unverändert]

wobei:

Beachten Sie die nachfolgenden Details in Hinblick auf die obigen Capability-Umwandlungsregeln:

Hinweis: Während der oben beschriebenen Capability-Übergänge könnten aus den gleichen Gründen, aus denen auch die Bits set-user-ID and set-group-ID ignoriert werden, Datei-Capabilities ignoriert (als leer betrachtet) werden; siehe execve(2). Ähnlich werden Datei-Capabilities ignoriert, falls der Kernel mit der Option no_file_caps gestartet wurde.

Hinweis: Entsprechend den obigen Regeln werden alle Capabilities, die in der erlaubten und effektiven Menge vorhanden sind, zurückgesetzt, falls ein Prozess mit von Null verschiedenen Benutzerkennungen ein execve(2) durchführt. Für die Behandlung der Capabilities, wenn ein Prozess mit der Benutzerkennung Null ein execve(2) durchführt, siehe unten unter Capabilities und Ausführung von Programmen durch root.

Sicherheitsprüfungen für Capability-unfähige Programme
Ein Capability-unfähiges Programm ist eine Anwendung, die für Datei-Capabilities markiert ist, aber noch nicht für die Verwendung des libcap(3)-APIs zur Bearbeitung seiner Capabilities konvertiert wurde. (Mit anderen Worten, dies ist ein traditionelles »set-user-ID-root«-Programm, das auf Datei-Capabilities umgestellt wurde, aber dessen Code nicht angepasst wurde, um mit Capabilities umzugehen.) Für solche Anwendungen wird das effektive Capability-Bit auf die Datei gesetzt, so dass die erlaubten Capabilities automatisch beim Ausführen der Datei in der effektiven Menge aktiviert werden. Der Kernel erkennt für den hier beschriebenen Zweck eine Datei, die das effektive Capability-Bit gesetzt hat, als Capability-unfähig.

Beim Ausführen eines Capability-unfähigen Programms prüft der Kernel nach den oben beschriebenen Umwandlungen, ob der Prozess alle erlaubten Capabilities, die in der Datei-erlaubten Menge angegeben wurden, erlangt hat. (Ein typischer Grund, warum dies nicht passieren könnte, liegt darin, dass die Capability-Begrenzungsmenge einige der Capabilities in der Datei-erlaubten Menge ausblenden könnte.) Falls der Prozess nicht die komplette Menge der Datei-erlaubten Capabilities erlangte, schlägt execve(2) mit dem Fehler EPERM fehl. Dies verhindert mögliche Sicherheitsrisiken, die daraus resultieren, dass ein Capability-unfähiges Programm mit weniger als den benötigten Privilegien ausgeführt wird. Beachten Sie, dass definitionsgemäß die Anwendung das Problem nicht selbst erkennen könnte, da sie nicht das libcap(3)-API einsetzt.

Capabilities und Ausführung von Programmen durch root
Um die traditionellen UNIX-Semantiken abzubilden, führt der Kernel eine besondere Behandlung der Datei-Capabilities durch, wenn ein Prozess mit UID 0 (root) ein Programm ausführt und wenn ein set-user-ID-root-Programm ausgeführt wird.

Nachdem alle Änderungen an der effektiven Kennung des Prozesses vorgenommen wurden, die durch das Modus-Bit set-user-ID des Programmes ausgelöst wurden, z.B. Umschalten der effektiven Benutzerkennung auf 0 (root), da ein set-user-ID-root-Programm ausgeführt wurde, berechnet der Kernel die Datei-Capability-Menge wie folgt:

Diese fiktiven Werte für die Capability-Menge der Datei werden dann verwandt, um wie oben beschrieben den Übergang der Capabilities des Prozesses während eines execve(2) zu berechnen.

Daher vereinfacht sich die Berechnung der neuen erlaubten Capabilities eines Prozesses wie folgt, wenn ein Prozess mit einer von 0 verschiedenen UID ein set-user-ID-root-Programm, das über keine Capabilities verfügt, mit execve(2) ausführt, oder wenn ein Prozess, dessen reale und effektive UIDs Null sind, ein Programm mit execve(2) ausführt:

P’(permitted)   = P(inheritable) | P(bounding)

P’(effective)   = P’(permitted)

Konsequenterweise erlangt der Prozess alle Capabilities in seiner erlaubten und effektiven Capability-Menge, außer denen, die in seiner Capability-Begrenzungsmenge ausmaskiert sind. (In der Berechnung von P’(permitted) kann der Ausdruck für P’(ambient) wegvereinfacht werden, da er per Definition eine gültige Untermenge von P(inheritable) ist.)

Die in diesem Unterabschnitt beschriebene besondere Behandlung des Benutzers 0 (root) kann mittels des nachfolgend beschriebenen Securebits-Mechanismus deaktiviert werden.

Set-user-ID-root-Programme, die Datei-Capabilities haben
Es gibt zu dem unter Capabilities und Ausführung von Programmen durch root beschriebenen Verhalten eine Ausnahme. Falls (a) das ausgeführte Programm über Capabilities verfügt und (b) die reale Benutzerkennung des Prozesses nicht 0 (root) ist und (c) die effektive Benutzerkennung des Prozesses 0 (root) ist, dann werden die Datei-Capabilities berücksichtigt (d.h. sie werden nicht fiktiv als komplett Einsen angenommen). Der normale Weg, bei dem diese Situation auftreten kann, ist die Ausführung eines set-UID-root-Programms, das auch über Datei-Capabilities verfügt. Wenn ein solches Programm ausgeführt wird, erlangt der Prozess nur die durch das Programm eingeräumten Capabilities (d.h. nicht alle Capabilities, was passierte, wenn ein set-user-ID-Root-Programm ausgeführt würde, das keine zugeordneten Datei-Capabilities hat).

Beachten Sie, dass einem Programm eine leere Capability-Menge zugeordnet werden kann und es daher möglich ist, ein set-user-ID-root-Programm zu erstellen, das die effektive und die gespeicherte set-user-ID des Prozesses, der das Programm ausführt, auf 0 setzt, aber dem Prozess keine Capabilities gewährt.

Capability-Begrenzungsmenge
Die Capability-Begrenzungsmenge ist ein Sicherheitsmechanismus, der zur Begrenzung der Capabilities, die während eines execve(2) erlangt werden können, dienen kann. Die Begrenzungsmenge wird auf die folgende Art und Weise benutzt:

Beachten Sie, dass die Begrenzungsmenge die erlaubten Datei-Capabilities maskiert, aber nicht die vererbbaren Capabilities. Falls ein Thread eine Capability in seiner vererbbaren Menge betreut, die nicht in seiner Begrenzungsmenge ist, dann kann er weiterhin die Capability in seiner erlaubten Menge erlangen, indem er eine Datei ausführt, die diese Capability in seiner vererbbaren Menge enthält.

Abhängig von der Kernelversion ist die Capability-Begrenzungsmenge entweder ein systemweites Attribut oder ein prozessweises Attribut.

Capability-Begrenzungsmenge seit Linux 2.6.25

Seit Linux 2.6.25 ist die Capability-Begrenzungsmenge ein pro-Thread-Attribut. (Die nachfolgend beschriebene systemweite Capability-Begrenzungsmenge existiert nicht mehr.)

Die Begrenzungsmenge wird bei fork(2) von dem Elternprozess des Threads vererbt und bleibt über ein execve(2) erhalten.

Ein Thread kann mittels der Aktion prctl(2) PR_CAPBSET_DROP Capabilities aus seiner Begrenzungsmenge entfernen, vorausgesetzt, er verfügt über die Capability CAP_SETPCAP. Sobald eine Capability aus der Begrenzungsmenge entfernt wurde, kann sie nicht mehr zu der Menge wieder hinzugefügt werden. Ein Thread kann mittels der Aktion prctl(2) PR_CAPBSET_READ herausfinden, ob eine Capability in seiner Begrenzungsmenge liegt.

Entfernen von Capabilities aus der Begrenzungsmenge ist nur möglich, falls Datei-Capabilities in den Kernel kompiliert wurden. In Kerneln vor Linux 2.6.33 waren Datei-Capabilities eine optionale Funktionalität, die mittels der Option CONFIG_SECURITY_FILE_CAPABILITIES konfigurierbar war. Seit Linux 2.6.33 ist die Konfigurationsoption entfernt und Datei-Capabilities sind immer Teil des Kernels. Wenn Datei-Capabilities in den Kernel kompiliert sind, beginnt der init-Prozess (der Urahn aller Prozesse) mit einer kompletten Begrenzungsmenge. Falls Datei-Capabilities nicht in den Kernel kompiliert sind, dann beginnt init mit einer vollständigen Begrenzungsmenge ohne CAP_SETPCAP, da diese Capability eine andere Bedeutung hat, wenn es keine Datei-Capabilities gibt.

Die Entfernung einer Capability aus der Begrenzungsmenge entfernt sie nicht aus der vererbbaren Menge des Threads. Allerdings verhindert es das Zurückfügen in die vererbbare Menge des Threads in der Zukunft.

Capability-Begrenzungsmenge vor Linux 2.6.25

In Kerneln vor 2.6.25 ist die Capability-Begrenzungsmenge ein systemweites Attribut, das alle Threads auf dem System betrifft. Auf die Begrenzungsmenge kann über die Datei /proc/sys/kernel/cap-bound zugegriffen werden. (Zur Erhöhung der Konfusion wird dieser Bitmaskenparameter als vorzeichenbehaftete Dezimalzahl in /proc/sys/kernel/cap-bound ausgedrückt.)

Nur der init-Prozess darf Capabilities in der Capability-Begrenzungsmenge setzen; abgesehen davon kann der Superuser (oder genauer: ein Prozess mit der Capability CAP_SYS_MODULE) nur Capabilities aus dieser Menge entfernen.

Auf einem Standardsystem maskiert die Capability-Begrenzungsmenge immer die Capability CAP_SETPCAP. Um diese Einschränkung zu entfernen (gefährlich!), verändern Sie die Definition von CAP_INIT_EFF_SET in include/linux/capability.h und bauen Ihren Kernel neu.

Die systemweite Capability-Begrenzungsmengenfunktion wurde Linux in Version 2.2.11 hinzugefügt.

Effekt von Benutzerkennungsänderungen auf Capabilities
Um die traditionellen Semantiken für Übergänge zwischen 0 und von 0 verschiedenen Kennungen zu erhalten, führt der Kernel folgende Änderungen an den Capability-Mengen eines Threads bei Änderung der realen, effektiven, gespeicherten und Dateisystem-Benutzerkennung (unter Verwendung von setuid(2), setresuid(2) oder ähnlich) durch:

Falls ein Thread, der einen Wert 0 für mindestens eine seiner Benutzerkennungen hat, verhindern möchte, dass seine erlaubte Capability-Menge bereinigt wird, wenn er alle seine Benutzerkennungen auf einen von 0 verschiedenen Wert setzt, kann er dies mittels der unten beschriebenen SECBIT_KEEP_CAPS-Securebits-Schaltern erreichen.

Programmatische Anpassung von Capability-Mengen
Ein Thread kann seine erlaubten, effektiven und vererbbaren Capability-Mengen mittels der Systemaufrufe capget(2) und capset(2) ermitteln und ändern. Allerdings werden für diesen Zweck die Verwendung von cap_get_proc(3) und cap_set_proc(3), beide im Paket libcap bereitgestellt, empfohlen. Die folgenden Regeln bestimmen die Änderungen an den Capability-Mengen des Threads:

Der Schalter securebits: eine reine Capability-Umgebung einrichten
Beginnend mit Kernel 2.6.26 und mit einem Kernel, in dem Datei-Capabilities aktiviert sind, implementiert Linux eine Menge von pro-Thread-securebits-Schaltern, die zur Deaktivierung von spezieller Handhabung von Capabilities für UID 0 (root) verwandt werden können. Dies sind die folgenden Schalter:
SECBIT_KEEP_CAPS

Durch Setzen dieses Schalters darf ein Thread, der mindestens eine 0 UID hat, Capabilities in seiner erlaubten Menge behalten, wenn er alle UIDs auf von 0 verschiedene Werte umschaltet. Falls dieser Schalter nicht gesetzt ist, dann führt das Umschalten der UIDs dazu, dass er alle erlaubten Capabilities verliert. Dieser Schalter wird bei execve(2) immer bereinigt.

Bachten Sie, dass selbst mit gesetztem Schalter SECBIT_KEEP_CAPS die effektiven Capabilities eines Threads bereinigt werden, wenn er seine effektive UID auf einen von Null verschiedenen Wert umschaltet. Falls der Thread allerdings über diesen Schalter verfügt und seine effektive UID bereits von Null verschieden ist und der Thread anschließend alle anderen UIDs auf einen von Null verschiedenen Wert umschaltet, dann werden die effektiven Capabilities nicht bereinigt.

Die Einstellung des Schalters SECBIT_KEEP_CAPS wird ignoriert, falls der Schalter SECBIT_NO_SETUID_FIXUP gesetzt ist. (Letzterer Schalter stellt eine Übermenge des Effekts des ersteren Schalters bereit.)

Dieser Schalter stellt die gleiche Funktionalität wie die ältere Aktion prctl(2) PR_SET_KEEPCAPS bereit.

SECBIT_NO_SETUID_FIXUP

Setzen dieses Schalters hindert den Kernel daran, die erlaubten, effektiven und Umgebungs-Capability-Mengen des Prozesses anzupassen, wenn die effektive und die Dateisystem-UID eines Threads zwischen null und von null verschiedenen Werten umgeschaltet werden. (Lesen Sie den Abschnitt Effekt von Benutzerkennungsänderungen auf Capabilities)

SECBIT_NOROOT

Falls dieses Bit gesetzt ist, dann verleiht der Kernel keine Capabilities, wenn ein Set-User-ID-Root-Programm ausgeführt wird oder wenn ein Prozess mit einer effektiven oder realen UID von 0 execve(2) aufruft. (Lesen Sie den Abschnitt Capabilities und Ausführung von Programmen durch root)

SECBIT_NO_CAP_AMBIENT_RAISE

Durch Setzen dieses Schalters dürfen keine Umgebungs-Capabilities mit der prctl(2)-Aktion PR_CAP_AMBIENT_RAISE gehoben werden.

Jeder der obigen »basis«-Schalter hat einen begleitenden »gesperrten« Schalter. Das Setzen eines »gesperrten« Schalters ist unumkehrbar und hat den Effekt, dass weitere Änderungen an dem entsprechenden Basisschalter nicht mehr möglich sind. Die gesperrten Schalter sind: SECBIT_KEEP_CAPS_LOCKED, SECBIT_NO_SETUID_FIXUP_LOCKED, SECBIT_NOROOT_LOCKED und SECBIT_NO_CAP_AMBIENT_RAISE_LOCKED.

Die Schalter securebits können mit den Aktionen prctl(2) PR_SET_SECUREBITS und PR_GET_SECUREBITS geändert und abgefragt werden. Die Capability CAP_SETPCAP wird für die Veränderung der Schalter benötigt. Beachten Sie, dass die Konstanten SECBIT_* nur nachdem Sie die Header-Datei <linux/securebits.h> eingebunden haben verfügbar sind.

Die Schalter securebits werden von Kindprozessen vererbt. Während eines execve(2) werden alle Schalter beibehalten, außer SECBIT_KEEP_CAPS, das immer bereinigt wird.

Eine Anwendung kann den folgenden Aufruf verwenden, um sich selbst und alle seine Abkömmlinge in eine Umgebung zu sperren, in der die einzige Möglichkeit, Capabilities zu erlangen, darin besteht, ein Programm auzuführen, das über die zugeordneten Datei-Capabilities verfügt:

prctl(PR_SET_SECUREBITS,
        /* SECBIT_KEEP_CAPS off */
        SECBIT_KEEP_CAPS_LOCKED |
        SECBIT_NO_SETUID_FIXUP |
        SECBIT_NO_SETUID_FIXUP_LOCKED |
        SECBIT_NOROOT |
        SECBIT_NOROOT_LOCKED);
        /* Setzen/Sperren von SECBIT_NO_CAP_AMBIENT_RAISE
           ist nicht erforderlich */

Namensraumbezogene »set-user-ID-root«-Programme
Ein set-user-ID-Programm, dessen UID auf die UID passt, die einen Benutzernamensraum erstellte, wird die Capabilities in den erlaubten und effektiven Mengen übertragen, wenn es durch irgendeinen Prozess innerhalb dieses Namensraums (oder einen Benutzernamensraum, der davon abstammt) ausgeführt wird.

Die obigen Regeln über die Umwandlung der Capabilities des Prozesses während eines execve(2) werden genau in den Unterabschnitten Umwandlungen von Capabilities während execve() und Capabilities und Ausführung von Programmen durch root beschrieben, wobei im letzeren Unterabschnitt als Unterschied »root« die UID des Erstellers des Benutzernamensraums ist.

Namensraumbezogene Datei-Capabilities
Traditionelle (d.h. Version 2-)Datei-Capabilities ordnen nur eine Menge von Capability-Masken einem binären Programm zu. Wenn ein Prozess ein Programm mit solchen Capabilities ausführt, erlangt es die zugeordneten Capabilities (innerhalb seines Benutzernamensraums) wie in den oben beschriebenen Regeln »Umwandlungen von Capabilities während execve()« beschrieben.

Da Version-2-Datei-Capabilities dem ausführenden Prozess unabhängig davon, in welchem Namensraum er sich befindet, Capabilities verleiht, dürfen nur privilegierte Prozesse Capabilities einer Datei zuordnen. Hier bedeutet »privilegiert«, dass ein Prozess über die Capability CAP_SETFCAP in dem Benutzernamensraum, in dem das Dateisystem eingehängt wurde (normalerweise dem initialen Namensraum), verfügt. Diese Einschränkung führt dazu, dass in bestimmten Einsatzfällen Datei-Capabilities nutzlos sind. Es kann zum Beispiel in namensraumbezogenen Containern wünschenswert sein, in der Lage zu sein, ein Programm zu erstellen, das Capabilities nur an Prozesse, die innerhalb dieses Containers ausgeführt werden, zu verleihen, aber nicht an Prozesse, die außerhalb des Containers ausgeführt werden.

Linux 4.14 fügte sogenannte namensraumbezogene Datei-Capabilities hinzu, um solche Fälle zu unterstützen. Namensraumbezogene Datei-Capabilities werden als Version 3 (d.h. VFS_CAP_REVISION_3) erweiterte Attribute security.capability aufgezeichnet. Solch ein Attribut wird automatisch unter den oben in »Erweiterte Attributversionierung von Datei-Capabilities« beschriebenen Umständen erstellt. Wenn ein erweitertes Version-3-Attribut security.capability erstellt wird, zeichnet der Kernel nicht nur die Capability-Maske in dem erweiterten Attribut auf, sondern auch die Benutzerkennung von root in dem Namensraum.

Wie mit Programmen, die eine Datei-Capability VFS_CAP_REVISION_2 haben, verleiht ein Programm mit Datei-Capability VFS_CAP_REVISION_3 während eines execve() Capabilities an einen Prozess. Allerdings werden Capabilities nur verliehen, falls das Programm von einem Prozess ausgeführt wird, der in einem Benutzernamensraum, dessen UID 0 auf die Wurzelbenutzerkennung, die in dem erweiterten Attribut gespeichert ist, abgebildet ist oder wenn er von einem Prozess ausgeführt wird, der in einem Nachkommen solch eines Namensraums liegt.

Interaktion mit Benutzernamensräumen
Für weitere Informationen über die Interaktion von Capabilities und Benutzer-Namensräumen lesen Sie user_namespaces(7).

KONFORM ZU

Keine Standards regeln Capabilities; die Linux-Capability-Implementierung basiert aber auf dem zurückgezogenen POSIX.1e-Entwurfsstandard; siehe https://archive.org/details/posix_1003.1e-990310">https://archive.org/details/posix_1003.1e-990310.

ANMERKUNGEN

Beim Versuch, strace(1) auf Programme anzuwenden, die über Capabilities verfügen (oder set-user-ID-root-Programme), könnten Sie die Option -u <Benutzername> nützlich finden. Etwas von der Art:

$ sudo strace -o trace.log -u ceci ./meinprivprog

Von Kernel 2.5.27 bis Kernel 2.6.26 waren Capabilities eine optionale Kernelkomponente, die über die Kernelkonfigurationsoption CONFIG_SECURITY_CAPABILITIES aktiviert/deaktiviert werden könnte.

Die Datei /proc/[PID]/task/TID/status kann zum Betrachten der Capability-Mengen eines Threads verwandt werden. Die Datei /proc/[PID]/status zeigt die Capability-Mengen des Haupt-Threads eines Prozesses. Vor Linux 3.8 wurden nicht existierende Capabilities in diesen Mengen als aktiviert (1) angezeigt. Seit Linux 3.8 werden alle nicht existierenden Capabilities (über CAP_LAST_CAP) als deaktiviert (0) angezeigt.

Das Paket libcap stellt eine Suite von Routinen zum Setzen und Abfragen von Capabilities bereit, die komfortablere und änderungsstabilere Schnittstellen als die von capset(2) und capget(2) bereitstellen. Dieses Paket stellt auch die Programme setcap(8) und getcap(8) zur Verfügung. Es kann unter folgender Adresse gefunden werden:
https://git.kernel.org/pub/scm/libs/libcap/libcap.git/refs/">https://git.kernel.org/pub/scm/libs/libcap/libcap.git/refs/.

Vor Kernel 2.6.24 und von Kernel 2.6.24 bis Kernel 2.6.32, falls Datei-Capabilities nicht aktiviert sind, kann ein Thread mit der Capability CAP_SETPCAP die Capabilities von anderen Threads manipulieren. Allerdings ist dies nur theoretisch möglich, da kein Thread jemals über CAP_SETPCAP in einem der folgenden Fälle verfügt:

SIEHE AUCH

capsh(1), setpriv(1), prctl(2), setfsuid(2), cap_clear(3), cap_copy_ext(3), cap_from_text(3), cap_get_file(3), cap_get_proc(3), cap_init(3), capgetp(3), capsetp(3), libcap(3), proc(5), credentials(7), pthreads(7), user_namespaces(7), captest(8), filecap(8), getcap(8), netcap(8), pscap(8), setcap(8)

include/linux/capability.h in dem Linux-Kernelquellbaum

KOLOPHON

Diese Seite ist Teil der Veröffentlichung 5.07 des Projekts Linux-man-pages. Eine Beschreibung des Projekts, Informationen, wie Fehler gemeldet werden können sowie die aktuelle Version dieser Seite finden sich unter https://www.kernel.org/doc/man-pages/.

ÜBERSETZUNG

Die deutsche Übersetzung dieser Handbuchseite wurde von Dr. Tobias Quathamer <toddy [AT] debian.org> und Helge Kreutzmann <debian [AT] helgefjell.de> 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 <debian-l10n-german [AT] lists.org>.