capabilities

CAPABILITIES(7)            Linux-Programmierhandbuch           CAPABILITIES(7)



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
              * Dateileserechteprüfungen und Verzeichnislese- und
                -ausführrechteprüfungen umgehen.
              * open_by_handle_at(2) aufrufen.
              * Verwenden Sie den Schalter AT_EMPTY_PATH von linkat(2), um
                einen Link auf eine Datei, auf die sich ein Dateideskriptor
                bezieht, zu erstellen.

       CAP_FOWNER
              * Rechteprüfungen umgehen, die normalerweise verlangen, dass
                die Dateisystem-UID des Prozesses mit der UID der Datei
                übvereinstimmt (z.B. chmod(2), utime(2)), hierbei sind
                Aktionen, die durch CAP_DAC_OVERRIDE und CAP_DAC_READ_SEARCH
                abgedeckt sind, ausgeschlossen;
              * Inode-Schalter für beliebige Dateien setzen (siehe
                ioctl_iflags(2));
              * Zugriffssteuerlisten (»Access Control Lists«, ACLs) auf
                beliebige Dateien setzen;
              * »sticky«-Bit von Verzeichnissen beim Dateilöschen
                ignorieren;
              * modify user extended attributes on sticky directory owned by
                any user;
              * O_NOATIME für beliebige Dateien in open(2) und fcntl(2)
                setzen.

       CAP_FSETID
              * Set-User-ID- und Set-Group-ID-Modus-Bits nicht zurücksetzen,
                wenn eine Datei verändert wird;
              * das Set-Group-ID-Bit für eine Datei setzen, deren GID nicht
                auf das Dateisystem- oder eine der ergänzenden GIDs des
                aufrufenden Prozesses passt.

       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:
              * Schnittstellenkonfiguration;
              * Administration von IP-Firewall, Masquerading und Abrechnung;
              * Routing-Tabellen verändern;
              * an beliebige Adresse für eine transparente Proxyfunktion
                binden;
              * type-of-service (TOS) setzen;
              * Treiberstatistiken bereinigen;
              * den »promiscuous«-Modus einschalten;
              * Multicasting aktivieren;
              * setsockopt(2) verwenden, um die folgenden Socket-Optionen zu
                setzen: SO_DEBUG, SO_MARK, SO_PRIORITY (für eine Priorität
                auÃerhalb des Bereichs 0 bis 6), SO_RCVBUFFORCE und
                SO_SNDBUFFORCE.

       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
              * RAW- und PACKET-Sockets verwenden;
              * an beliebige Adresse für eine transparente Proxyfunktion
                binden.

       CAP_SETGID
              * Beliebige Manipulationen an den GIDs und der Liste der
                ergänzenden GIDs des Prozesses vornehmen;
              * GID fälschen, wenn Socket-Berechtigungsnachweise via
                UNIX-Domain-Sockets weitergebeben werden;
              * eine Gruppenkennungs-Abbildung in einen Benutzernamensraum
                schreiben (siehe user_namespaces(7)).

       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
              * beliebige Manipulationen der Prozess-UIDs vornehmen
                (setuid(2), setreuid(2), setresuid(2), setfsuid(2));
              * UID fälschen, wenn Socket-Berechtigungsnachweise via
                UNIX-Domain-Sockets weitergebeben werden;
              * eine Benutzerkennung-Abbildung in einen Benutzernamensraum
                schreiben (siehe user_namespaces(7)).

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

              * eine Reihe von Systemadministratoraktionen ausführen,
                darunter: quotactl(2), mount(2), umount(2), pivot_root(2),
                swapon(2), swapoff(2), sethostname(2) und setdomainname(2);
              * privilegierte syslog(2)-Aktion ausführen (seit Linux 2.6.37
                sollte CAP_SYSLOG verwandt werden, um diese Aktion zu
                erlauben);
              * den VM86_REQUEST_IRQ-Befehl vm86(2) ausführen;
              * IPC_SET- und IPC_RMID-Aktion auf beliebigen
                System-V-IPC-Objekten ausführen;
              * RLIMIT_NPROC-Ressourcenbegrenzung auÃer Kraft setzen;
              * Aktionen an den Erweiterten Attributen (»Extended
                Attributes«) trusted und security durchführen (siehe
                attr(7));
              * lookup_dcookie(2) verwenden;
              * ioprio_set(2) verwenden, um IOPRIO_CLASS_RT und (vor Linux
                2.6.25) IOPRIO_CLASS_IDLE-E/A-Scheduling-Klassen zuzuweisen;
              * PID fälschen, wenn Socket-Berechtigungsnachweise via
                UNIX-Domain-Sockets weitergebeben werden;
              * die systemweite Grenze der Anzahl der offenen Dateien
                (/proc/sys/fs/file-max) in Systemaufrufen, die Dateien öffnen
                (z.B. accept(2), execve(2), open(2), pipe(2)) überschreiben;
              * Schalter CLONE_* einsetzen, der neue Namensräume mit clone(2)
                und unshare(2) erstellt (seit Linux 3.8 benötigt die
                Erzeugung von Benutzernamensräumen allerdings keine
                Capability mehr);
              * perf_event_open(2) aufrufen;
              * auf privilegierte perf-Ereignisinformationen zugreifen;
              * setns(2) aufrufen (benötigt CAP_SYS_ADMIN im Namensraum
                target);
              * fanotify_init(2) aufrufen;
              * bpf(2) aufrufen;
              * privilegierte Aktionen KEYCTL_CHOWN und KEYCTL_SETPERM von
                keyctl(2) ausführen;
              * madvise(2)-MADV_HWPOISON-Aktion ausführen;
              * den TIOCSTI ioctl(2) verwenden, um Zeichen in die
                Eingabewarteschlange eines Terminals, dass nicht das vom
                aufrufenden gesteuerte Terminal ist, einzufügen;
              * veralteten Systemaufruf nfsservctl(2) verwenden;
              * veralteten Systemaufruf bdflush(2) verwenden;
              * verschiedene privilegierte Blockgeräte-ioctl(2)-Aktion
                ausführen;
              * verschiedene privilegierte Dateisystem-ioctl(2)-Aktionen
                ausführen;
              * privilegierte ioctl(2)-Aktionen am Gerät /dev/random
                durchführen (siehe random(4));
              * einen seccomp(2)-Filter installieren, ohne zuerst das
                no_new_privs Thread-Attribut setzen zu müssen;
              * Erlauben-/Verweigern-Regeln für Gerätesteuergruppen setzen;
              * ptrace(2) PTRACE_SECCOMP_GET_FILTER Aktionen einsetzen, um die
                Seccomp-Filter verfolgter Prozesse auszugeben;
              * die Aktion PTRACE_SETOPTIONS von ptrace(2) einsetzen, um den
                Seccomp-Schutz des verfolgten Prozesses vorübergehend auÃer
                Kraft zu setzen (d.h. der Schalter PTRACE_O_SUSPEND_SECCOMP);
              * administrative Aktionen auf vielen Gerätetreibern ausführen.

       CAP_SYS_BOOT
              reboot(2) und kexec_load(2) verwenden.

       CAP_SYS_CHROOT
              * chroot(2) verwenden;
              * Einhängenamensräume mittels setns(2) ändern.

       CAP_SYS_MODULE
              * Kernelmodule laden und entladen (siehe init_module(2) und
                delete_module(2));
              * in Kerneln vor 2.6.25: Capabilities aus der systemweiten
                Capability-Begrenzungsmenge entfernen.

       CAP_SYS_NICE
              * den Nice-Wert von Prozessen erhöhen (nice(2), setpriority(2))
                und den Nice-Wert von beliebigen Prozessen ändern;
              * Echtzeit-Scheduling-Richtlinien zum Prozessaufruf und
                Scheduling-Richtlinien und -Prioritäten für beliebige
                Prozesse setzen (sched_setscheduler(2), sched_setparam(2),
                sched_setattr(2));
              * CPU-Affinität für beliebige Prozesse setzen
                (sched_setaffinity(2));
              * E/A-Scheduling-Klassen und -Prioritäten für beliebige
                Prozesse setzen (ioprio_set(2));
              * migrate_pages(2) auf beliebige Prozesse anwenden und Prozessen
                erlauben, auf beliebige Knoten zu migrieren;
              * move_pages(2) auf beliebige Prozesse anwenden;
              * den Schalter MPOL_MF_MOVE_ALL mit mbind(2) und move_pages(2)
                verwenden.

       CAP_SYS_PACCT
              acct(2) verwenden.

       CAP_SYS_PTRACE
              * Nachverfolgen beliebiger Prozesse mittels ptrace(2);
              * get_robust_list(2) auf beliebige Prozesse anwenden;
              * Daten vom oder zum Speicher beliebiger Prozesse mittels
                process_vm_readv(2) und process_vm_writev(2) übertragen;
              * Prozesse mittels kcmp(2) inspizieren.

       CAP_SYS_RAWIO
              * E/A-Port-Aktionen ausführen (iopl(2) und ioperm(2));
              * auf /proc/kcore zugreifen;
              * die FIBMAP-Aktion ioctl(2) einsetzen;
              * Geräte für den Zugriff auf x86-modellspezifische Register
                (MSRs, siehe msr(4)) öffnen;
              * /proc/sys/vm/mmap_min_addr aktualisieren;
              * Speichereinblendungen an Adressen unterhalb des durch
                /proc/sys/vm/mmap_min_addr angegebenen Wertes erstellen;
              * Dateien in /proc/bus/pci einblenden;
              * /dev/mem und /dev/kmem öffnen;
              * verschiedene SCSI-Geräte-Befehle ausführen;
              * bestimmte Aktionen auf hpsa(4)- und cciss(4)-Geräten
                ausführen;
              * eine Reihe von Geräte-spezifischen Aktionen auf anderen
                Geräten ausführen.

       CAP_SYS_RESOURCE
              * reservierten Platz auf Ext2-Dateisystemen verwenden;
              * ioctl(2)-Aufrufe ausführen, die das Journaling von Ext3
                steuern;
              * Platten-Quota-Begrenzungen auÃer Kraft setzen;
              * Ressourcenbegrenzungen erhöhen (siehe setrlimit(2));
              * RLIMIT_NPROC-Ressourcenbegrenzung auÃer Kraft setzen;
              * maximale Anzahl von Konsolen bei der Konsolenzuteilung auÃer
                Kraft setzen;
              * maximale Anzahl an Tastaturdefinitionen auÃer Kraft setzen;
              * mehr als 64 Hz-Unterbrechungen von der Echtzeituhr erlauben;
              * die msg_qbytes-Begrenzung für eine
                System-V-Nachrichtenwarteschlange über die Grenze in
                /proc/sys/kernel/msgmnb anheben (siehe msgop(2) und
                msgctl(2));
              * erlauben, die Ressourcenbegrenzung RLIMIT_NOFILE bezüglich
                der Anzahl der »laufenden« Dateideskriptoren zu umgehen,
                wenn Dateideskriptoren an andere Prozesse mittels
                UNIX-Domain-Sockets übergeben werden (siehe unix(7));
              * die /proc/sys/fs/pipe-size-max-Begrenzung beim Setzen der
                Kapazität einer Pipe mittels des F_SETPIPE_SZ-Befehls
                fcntl(2) auÃer Kraft setzen;
              * F_SETPIPE_SZ verwenden, um die Kapazität einer Pipe über die
                in /proc/sys/fs/pipe-max-size angegebene Grenze erhöhen;
              * die /proc/sys/fs/mqueue/queues_max-Begrenzung beim Erstellen
                von POSIX-Nachrichtenwarteschlangen (siehe mq_overview(7))
                auÃer Kraft setzen;
              * die prctl(2)-Aktion PR_SET_MM einsetzen;
              * /proc/[PID]/oom_score_adj auf einen Wert niedriger als den
                zuletzt durch einen Prozess mit CAP_SYS_RESOURCE gesetzten
                Wert setzen.

       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)
              * Privilegierte syslog(2)-Aktionen ausführen. Siehe syslog(2)
                für Informationen, welche Aktionen Privilegien benötigen.
              * Ãber /proc bereitgestellte Kernel-Adressen und andere
                Schnittstellen anschauen, wenn /proc/sys/kernel/kptr_restrict
                den Wert 1 hat. (Lesen Sie die Diskussion über kptr_restrict
                in proc(5).)

       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:

       1. Für alle privilegierten Aktionen muss der Kernel prüfen, ob der
          Thread die benötigten Capabilities in seiner effektiven Menge hat.

       2. Der Kernel muss Systemaufrufe bereitstellen, die es erlauben, dass
          die Capability-Menge des Threads geändert und ermittelt wird.

       3. Das Dateisystem muss das Anhängen von Capabilities an ausführbare
          Dateien erlauben, so dass ein Prozess solche Capabilities erhält,
          wenn die Datei ausgeführt wird.

       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.

       *  Das Ziel von Capabilitys besteht darin, die Macht des
          Systembenutzers in Teile zu zerlegen. Wird dann ein Programm, das
          eine oder mehrere Capabilitys hat, kompromittiert, dann kann weniger
          Schaden angerichtet werden, als wenn das Programm mit Root-Rechten
          liefe.

       *  Sie haben die Wahl, entweder ein neues Capability für Ihre neue
          Funktionalität hinzuzufügen, oder die Funktionalität einer
          bereits bestehenden Capability zuzuordnen. Um die Menge der
          Capabilitys auf eine verwaltbare GröÃe zu begrenzen, wird die
          zweite Variante bevorzugt, auÃer es gibt überzeugende Gründe, die
          erste Variante zu wählen. (Es gibt auch eine technische Grenze: Die
          GröÃe der Capability-Menge ist derzeit auf 64 bit beschränkt.)

       *  Um zu bestimmen, zu welcher bestehenden Capability Ihre neue
          Funktionalität am besten zugeordnet werden könnte, prüfen Sie die
          obige Liste der Capabilitys, um ein »Silo« zu finden, in das Ihre
          neue Funktionalität am besten passt. Ein Vorgehen besteht darin, zu
          bestimmen, ob es andere Funktionalitäten gibt, die Capabilitys
          benötigen, die immer zusammen mit Ihrer neuen Funktionalität
          benötigt werden. Falls Ihre neue Funktionalität ohne diese andere
          Funktionalität nutzlos ist, dann sollten Sie die gleiche Capability
          wie die andere Funktionalität verwenden.

       *  Verwenden Sie nicht CAP_SYS_ADMIN, falls Sie es irgendwie vermeiden
          können. Ein riesiger Anteil an bestehenden
          Capability-Ãberprüfungen ist dieser Capability zugeordnet (siehe
          die Teilliste weiter oben). Sie kann glaubhaft als »der neue Root«
          bezeichnet werden, da sie eine groÃe Bandbreite an Rechten verleiht,
          und andererseits bedeutet ihr groÃer Geltungsbereich, dass es eine
          Capability ist, die von vielen privilegierten Programmen benötigt
          wird. Verschlimmern Sie das Problem nicht. Die einzigen neuen
          Funktionalitäten, die CAP_SYS_ADMIN zugeordnet werden sollten, sind
          diejenigen, die eng zu bestehenden Anwendungsfällen in diesem Silo
          passen.

       *  Falls Sie ermittelt haben, dass Sie wirklich eine neue Capability
          für Ihre Funktionalität benötigen, führen Sie sie nicht als
          »Einzelverwendung«-Capability ein (oder benennen Sie es so). Daher
          war beispielsweise die Ergänzung der hochspezifischen CAP_SYS_PACCT
          wahrscheinlich ein Fehler. Versuchen Sie stattdessen, Ihre neue
          Capability als ein breiteres Silo zu identifizieren und zu benennen,
          in das andere, damit im Zusammenhang stehende zukünftige
          Anwendungsfälle passen könnten.

   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:

       (1) Der Thread, der das Attribut schreibt, befindet sich in einem
           nichtinitialen Benutzernamensraum. (Genauer: Der Thread befindet
           sich in einem Benutzernamensraum, der sich von dem unterscheidet,
           unter dem das darunterliegende Dateisystem eingehängt wurde.)

       (2) Der Thread hat die Capability CAP_SETFCAP über der Datei-Inode,
           was bedeutet, dass (a) der Thread die Capability CAP_SETFCAP in
           seinem eigenen Benutzernamensraum hat und (b) die UID und GID der
           Datei-Inode Abbildungen in den Namensraum des schreibenden
           Benutzers haben.

       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.

       Note that the creation of a version 3 security.capability extended
       attribute is automatic.  That is to say, when a user-space application
       writes (setxattr(2))  a security.capability attribute in the version 2
       format, the kernel will automatically create a version 3 attribute if
       the attribute is created in the circumstances described above.
       Correspondingly, when a version 3 security.capability attribute is
       retrieved (getxattr(2))  by a process that resides inside a user
       namespace that was created by the root user ID (or a descendant of that
       user namespace), the returned attribute is (automatically)  simplified
       to appear as a version 2 attribute (i.e., the returned value is the
       size of a version 2 attribute and does not include the root user ID).
       These automatic translations mean that no changes are required to
       user-space tools (e.g., setcap(1)  and getcap(1))  in order for those
       tools to be used to create and retrieve version 3 security.capability
       attributes.

       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:

           P()   bezeichnet den Wert einer Capability-Menge des Threads vor
                 dem execve(2)

           P'()  bezeichnet den Wert einer Capability-Menge des Threads nach
                 dem execve(2)

           F()   bezeichnet eine Datei-Capability-Menge

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

       *  Die Umgebungs-Capability-Menge ist erst seit Linux 4.3 vorhanden.
          Bei der Bestimmung der Ãbergänge der Umgebungsmenge während eines
          execve(2) bezeichnet eine privilegierte Datei eine, die über
          Capabilities verfügt oder das Bit »set-user-ID« oder
          »set-group-ID« gesetzt hat.

       *  Vor Linux 2.6.25 war die Begrenzungsmenge ein systemweites Attribut,
          das von allen Threads gemeinsam benutzt wurde. Dieser systemweite
          Wert wurde eingesetzt, um die neue erlaubte Menge während eines
          execve(2) zu berechnen, auf die gleiche Art wie oben für
          P(bounding) gezeigt.

       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 einer von Null verschiedenen Benutzerkennung 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:

       1. Falls die reale oder effektive Benutzerkennung des Prozesses 0
          (root) ist, dann werden die vererbbaren und erlaubten Mengen
          ignoriert; stattdessen werden sie fiktiv als komplett Eins (d.h.
          alle Capabilities aktiviert) betrachtet. (Es gibt für dieses
          Verhalten eine Ausnahme, die unten in Set-user-ID-root-Programme,
          die Datei-Capabilities haben beschrieben ist.)

       2. Falls die effektive Benutzerkennung des Prozesses 0 (root) ist oder
          das effektive Bit der Datei tatsächlich aktiviert ist, dann wird
          das effektive Datei-Bit fiktiv als Eins (aktiviert) definiert.

       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:

       * Während eines execve(2) wird die Capability-Begrenzungsmenge mittels
         AND mit der erlaubten Datei-Capability-Menge verknüpft und das
         Ergebnis dieser Aktion wird der erlaubten Capability-Menge des
         Threads zugewiesen. Die Capability-Begrenzungsmenge stellt daher eine
         Grenze für die erlaubten Capabilities dar, die einer ausführbaren
         Datei erlaubt werden dürfen.

       * (Seit Linux 2.6.25) Die Capability-Begrenzungsmenge agiert als
         begrenzende Ãbermenge für die Capabilities, die ein Thread zu seiner
         vererbbaren Menge mittels capset(2) hinzufügen kann. Das bedeutet,
         dass ein Thread eine Capability nicht zu seiner vererbbaren Menge
         hinzufügen kann, falls es nicht in der Begrenzungsmenge enthalten
         ist, selbst falls es in seinen erlaubten Capabilities vorhanden ist,
         wenn er eine Datei mit execve(2) ausführt, die diese Capability in
         seiner vererbbaren Menge hat.

       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:

       1. Falls einer der realen, effektiven oder gespeicherten Set-User-IDs
          vorher 0 war und als Ergebnis der UID-Ãnderung alle dieser Kennungen
          eine von 0 verschiedenen Wert haben, dann werden alle Capabilities
          aus den erlaubten, effektiven und Umgebungs-Capability-Mengen
          gelöscht.

       2. Falls die effektive Benutzerkennung von 0 auf einen von 0
          verschiedenen Wert geändert wird, werden alle Capabilities aus der
          effektiven Menge gelöscht.

       3. Falls die effektive Benutzerkennung von einem von 0 verschiedenen
          Wert auf 0 geändert wird, dann wird die erlaubte Menge in die
          effektive Menge kopiert.

       4. Falls die Dateisystem-Benutzerkennung von 0 auf einen anderen Wert
          geändert wird (siehe setfsuid(2)), dann werden die folgenden
          Capabilities aus der effektiven Menge entfernt: CAP_CHOWN,
          CAP_DAC_OVERRIDE, CAP_DAC_READ_SEARCH, CAP_FOWNER, CAP_FSETID,
          CAP_LINUX_IMMUTABLE (seit Linux 2.6.30), CAP_MAC_OVERRIDE und
          CAP_MKNOD (seit Linux 2.6.30). Falls die Dateisystem-UID von einem
          von 0 verschiedenen Wert auf 0 geändert wird, dann werden alle
          dieser Capabilities, die in der erlaubten Menge aktiviert waren, in
          der effektiven Menge aktiviert.

       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:

       1. Falls der Aufrufende nicht über die Capability CAP_SETPCAP
          verfügt, dann muss die neue vererbbare Menge eine Teilmenge der
          Kombination der bestehenden vererbbaren und erlaubten Menge sein.

       2. (Seit Linux 2.6.25) Die neue vererbbare Menge muss eine Teilmenge
          der Kombination der bestehenden vererbbaren Menge und der
          Capability-Begrenzungsmenge sein.

       3. Die neue erlaubte Menge muss eine Teilmenge der bestehenden
          erlaubten Menge sein (d.h. es ist nicht möglich, erlaubte
          Capabilities zu erlangen, die der Thread derzeit nicht hat).

       4. Die neue effektive Menge muss eine Teilmenge der neuen erlaubten
          Menge sein.

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

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

       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:

       * In der pre-2.6.25-Implementierung maskiert die systemweite
         Capability-Begrenzungsmenge /proc/sys/kernel/cap-bound diese
         Capability immer und dies kann ohne Veränderung der Kernelquellen
         und dessen Neubau nicht geändert werden.

       * Falls Datei-Capabilities in der aktuellen Implementierung deaktiviert
         sind, dann startet init derart, dass diese Capability aus seiner
         prozessweisen Begrenzungsmenge entfernt ist und dass die
         Begrenzungsmenge von allen anderen im System erstellten Prozessen
         vererbt wird.

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.02 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 FIXME:
       Einheitliche Ãbersetzung von Transformation, Dr. Tobias Quathamer
       <toddy@debian.org> und Helge Kreutzmann <debian@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@lists.debian.org>.



Linux                           2. August 2019                 CAPABILITIES(7)