Provided by: manpages-de_2.5-1_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
       Benutzer-ID  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 Zugriffskontrolle)

       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));
              * Zugriffskontrolllisten  (»Access  Control  Lists«,  ACLs)  auf  beliebige Dateien
                setzen;
              * »sticky«-Bit von Verzeichnissen beim Dateilöschen ignorieren;
              * 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   Gruppen-ID-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  Benutzer-ID-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), 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;
              * ptrace(2)   PTRACE_SECCOMP_GET_FILTER  verwenden,  um  die  Seccomp-Filter  aller
                verfolgten Prozesse auszugeben;
              * 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

       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), shed_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) inspezieren

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

       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.

       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.

   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) & cap_bset) | P'(ambient)

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

           P'(inheritable) = P(inheritable)    [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

           cap_bset  ist der Wert der Capability-Begrenzungsmenge (weiter unten beschrieben)

       Eine privilegierte  Datei  verfügt  über  Capabilities  oder  hat  das  set-user-ID-  oder
       set-group-ID-Bit gesetzt.

       Hinweis: Die oben beschriebenen Capability-Übergänge könnten aus den gleichen Gründen, aus
       denen auch die Bits set-user-ID and set-group-ID  ignorieert  werden,  nicht  durchgeführt
       werden (d.h. Datei-Capabilities könnten ignoriert werden); siehe execve(2).

       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 während eines execve(2) ein allmächtigen root mit Capability-Mengen bereitzustellen:

       1. Falls ein Set-User-ID-Root-Programm ausgeführt  wird  oder  die  reale  oder  effektive
          Benutzer-ID  des  Prozesses 0 (root) ist sind die vererbbaren und erlaubten Dateimengen
          komplett auf nur Einsen definiert (d.h. alle Capabilities aktiviert).

       2. Falls ein Set-User-ID-Root-Programm ausgeführt wird oder die effektive Benutzer-ID  des
          Prozesses  0  ist  (root),  dann  ist  das  effektive  Datei-Bit  als  Eins (aktiviert)
          definiert.

       Das   Fazit   der   obigen    Regeln,    kombiniert    mit    den    oben    beschriebenen
       Capability-Umwandlungen, ist folgendes:

       *  Wenn  ein  Prozess  ein  Set-User-ID-Root-Programm mit execve(2) ausführt oder wenn ein
          Prozess mit einer effektiven UID von 0  ein  Programm  mit  execve  ausführt,  er  alle
          Capabilities  in  seinen erlaubten und effektiven Mengen erhält, außer denen, die durch
          die Capability-Begrenzungsmenge maskiert sind.

       *  Wenn ein Prozess mit einer echten UID von 0 ein Programm mit execve(2) ausführt, erhält
          es  alle  Capabilities in seiner erlaubten Capability-Menge, außer denen, die durch die
          Capability-Begrenzungsmenge maskiert sind.

       Die obigen Schritte ergeben  eine  Semantik,  die  identisch  zu  der  von  traditionellen
       UNIX-Systemen ist.

   Set-user-ID-root-Programme die Datei-Capabilities haben
       Wird   ein   Programm   ausgeführt,   das   sowohl  set-user-ID-Root  ist  als  auch  über
       Datei-Capabilities verfügt, führt dies dazu, dass der Prozess nur die durch  das  Programm
       eingeräumten  Capabilities  erlangt (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 Progresses, 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 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.

       Capability-Begrenzungsmenge seit Linux 2.6.25

       Seit  Linux  2.6.25  ist die Capability-Begrenzungsmenge ein pro-Thread-Attribut. (Es gibt
       keine systemweite Capability-Begrenzungsmenge 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.

   Effekt von Benutzer-ID-Änderungen auf Capabilities
       Um die traditionellen Semantiken für Übergänge zwischen 0 und von 0 verschiedenen  IDs  zu
       erhalten,  führt der Kernel folgende Änderungen an den Capability-Mengen eines Threads bei
       Änderung  der  echten,  effektiven,  gespeicherten  und   Dateisystem-Benutzer-ID   (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 IDs eine von 0  verschiedenen  Wert  haben,  dann
          werden  alle Capabilities aus den erlaubten, effektiven und Umgebungs-Capability-Mengen
          gelöscht.

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

       3. Falls die effektive Benutzer-ID 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-Benutzer-ID 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 Benutzer-IDs hat, verhindern
       möchte,   dass  seine  erlaubte  Capability-Menge  bereinigt  wird,  wenn  er  alle  seine
       Benutzer-IDs 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 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 und effektiven 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 Capabilities in diesen Mengen
              verliert. Dieser Schalter wird bei execve(2) immer 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 Benutzer-ID-Ä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.

       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 */

   Interaktion mit Benutzer-Namensräumen
       Für  eine  Diskussion der 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 ⟨http://wt.tuxomania.net/publications
       /posix.1e/⟩

ANMERKUNGEN

       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:
       ⟨http://www.kernel.org/pub/linux/libs/security/linux-privs⟩

       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  4.15  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,  Helge  Kreutzmann  <debian@helgefjell.de>  und  Dr. Tobias Quathamer
       <toddy@debian.org> 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>.