Provided by: manpages-de_2.15-1build1_all bug

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