capabilities(7) — manpages-de — Debian buster-backports — Debian Manpages\n/ buster-backports / manpages-de / capabilities(7)\nCAPABILITIES(7) Linux-Programmierhandbuch CAPABILITIES(7)\ncapabilities - Überblick über Linux-Capabilitys\nFü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.\nBeginnend mit Kernel 2.2 unterteilt Linux die Privilegien, die traditionell mit dem Superuser assoziiert sind, in getrennte Einheiten, die als Capabilitys bekannt sind. Diese können unabhängig voneinander aktiviert oder deaktiviert werden. Capabilitys sind ein Attribut pro Thread.\nListe der Capabilitys¶\nDie folgende Liste zeigt die in Linux implementierten Capabilitys und die Aktionen oder Verhalten, die jede Capability erlaubt:\nCAP_AUDIT_CONTROL (seit Linux 2.6.11)\nKernel-Auditierung aktivieren und deaktivieren; die Auditierung-Filterregel ändern; den Auditstatus und Filterregel abfragen.\nCAP_AUDIT_READ (seit Linux 3.16)\nErlaubt das Schreiben des Audit-Protokolls über einen Multicast-Netlink-Socket.\nCAP_AUDIT_WRITE (seit Linux 2.6.11)\nDatensätze in das Audit-Protokoll des Kernels schreiben.\nCAP_BLOCK_SUSPEND (seit Linux 3.5)\nFunktionalitäten einsetzen, die die System-Supsendierung blockieren können (epoll(7) EPOLLWAKEUP, /proc/sys/wake_lock).\nbeliebige Änderungen an Datei-UIDs und GIDs vornehmen (siehe chown(2)).\nLese-, Schreibe und Ausführrechteprüfungen umgehen. (DAC ist die Abkürzung für »discretionary access control«, benutzerbestimmbare Zugriffssteuerung)\nDateileserechteprüfungen und Verzeichnislese- und -ausführrechteprüfungen umgehen.\nVerwenden Sie den Schalter AT_EMPTY_PATH von linkat(2), um einen Link auf eine Datei, auf die sich ein Dateideskriptor bezieht, zu erstellen.\nRechteprü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;\nInode-Schalter für beliebige Dateien setzen (siehe ioctl_iflags(2));\nZugriffssteuerlisten (»Access Control Lists«, ACLs) auf beliebige Dateien setzen;\n»sticky«-Bit von Verzeichnissen beim Dateilöschen ignorieren;\nverändert Benutzer-erweiterte Attribute bei »sticky«-Verzeichnissen, die irgendeinem Benutzer gehören;\nO_NOATIME für beliebige Dateien in open(2) und fcntl(2) setzen.\nSet-User-ID- und Set-Group-ID-Modus-Bits nicht zurücksetzen, wenn eine Datei verändert wird;\ndas 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.\nSpeicher sperren (mlock(2), mlockall(2), mmap(2), shmctl(2)).\nRechteprüfungen für Aktionen mit System-V-IPC-Objekten umgehen.\nRechteprüfungen beim Senden von Signalen umgehen (siehe kill(2)). Dies schließt die ioctl(2)-KDSIGACCEPT-Aktion mit ein.\nCAP_LEASE (seit Linux 2.4)\nEtabliert Ausleihen für beliebige Dateien (siehe fcntl(2)).\nSetzt die Inode-Schalter FS_APPEND_FL und FS_IMMUTABLE_FL (siehe ioctl_iflags(2)).\nCAP_MAC_ADMIN (seit Linux 2.6.25)\nMAC-Konfiguration oder Statusänderungen erlauben. Implementiert für das Smack-Linux-Security-Modul (LSM).\nCAP_MAC_OVERRIDE (seit Linux 2.6.25)\nMandatory Access Control (MAC) außer Kraft setzen. Für das Smack-LSM implementiert.\nCAP_MKNOD (seit Linux 2.4)\nSpezielle Dateien mittels mknod(2) erstellen.\nVerschiedene Netz-bezogene Aktionen durchführen:\nAdministration von IP-Firewall, Masquerading und Abrechnung;\nan beliebige Adresse für eine transparente Proxyfunktion binden;\ntype-of-service (TOS) setzen;\nden »promiscuous«-Modus einschalten;\nsetsockopt(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.\nEinen Socket an einen privilegierten Internet-Domain-Port binden (Portnummern kleiner als 1024).\n(Unbenutzt) Socket-Broadcasts durchführen und auf Multicasts warten.\nRAW- und PACKET-Sockets verwenden;\nan beliebige Adresse für eine transparente Proxyfunktion binden.\nBeliebige Manipulationen an den GIDs und der Liste der ergänzenden GIDs des Prozesses vornehmen;\nGID fälschen, wenn Socket-Berechtigungsnachweise via UNIX-Domain-Sockets weitergebeben werden;\neine Gruppenkennungs-Abbildung in einen Benutzernamensraum schreiben (siehe user_namespaces(7)).\nCAP_SETFCAP (seit Linux 2.6.24)\nSetzt beliebige Capabilitys auf einer Datei.\nFalls Datei-Capabilitys unterstützt werden (d.h. seit Linux 2.6.24): Füge alle Capabilitys aus der Begrenzungsmenge des Threads zu der vererbbaren Menge hinzu; entferne Capabilitys aus der Begrenzungsmenge (via prctl(2) PR_CAPBSET_DROP); nehme Änderungen an den securebits-Schaltern vor.\nFalls 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-Capabilitys konfiguriert ist, da CAP_SETPCAP für diese Kernel eine komplett andere Semantik aufweist.)\nbeliebige Manipulationen der Prozess-UIDs vornehmen (setuid(2), setreuid(2), setresuid(2), setfsuid(2));\nUID fälschen, wenn Socket-Berechtigungsnachweise via UNIX-Domain-Sockets weitergebeben werden;\neine Benutzerkennung-Abbildung in einen Benutzernamensraum schreiben (siehe user_namespaces(7)).\nHinweis: Diese Capability ist überladen, siehe Hinweise für Kernel-Entwickler weiter unten.\neine Reihe von Systemadministratoraktionen ausführen, darunter: quotactl(2), mount(2), umount(2), pivot_root(2), swapon(2), swapoff(2), sethostname(2) und setdomainname(2);\nprivilegierte syslog(2)-Aktion ausführen (seit Linux 2.6.37 sollte CAP_SYSLOG verwandt werden, um diese Aktion zu erlauben);\nden VM86_REQUEST_IRQ-Befehl vm86(2) ausführen;\nIPC_SET- und IPC_RMID-Aktion auf beliebigen System-V-IPC-Objekten ausführen;\nRLIMIT_NPROC-Ressourcenbegrenzung außer Kraft setzen;\nAktionen an den Erweiterten Attributen (»Extended Attributes«) trusted und security durchführen (siehe xattr(7));\nioprio_set(2) verwenden, um IOPRIO_CLASS_RT und (vor Linux 2.6.25) IOPRIO_CLASS_IDLE-E/A-Scheduling-Klassen zuzuweisen;\nPID fälschen, wenn Socket-Berechtigungsnachweise via UNIX-Domain-Sockets weitergebeben werden;\ndie 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;\nSchalter 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);\nauf privilegierte perf-Ereignisinformationen zugreifen;\nsetns(2) aufrufen (benötigt CAP_SYS_ADMIN im Namensraum target);\nprivilegierte Aktionen KEYCTL_CHOWN und KEYCTL_SETPERM von keyctl(2) ausführen;\nden TIOCSTI ioctl(2) verwenden, um Zeichen in die Eingabewarteschlange eines Terminals, dass nicht das vom aufrufenden gesteuerte Terminal ist, einzufügen;\nveralteten Systemaufruf nfsservctl(2) verwenden;\nveralteten Systemaufruf bdflush(2) verwenden;\nverschiedene privilegierte Blockgeräte-ioctl(2)-Aktion ausführen;\nverschiedene privilegierte Dateisystem-ioctl(2)-Aktionen ausführen;\nprivilegierte ioctl(2)-Aktionen am Gerät /dev/random durchführen (siehe random(4));\neinen seccomp(2)-Filter installieren, ohne zuerst das no_new_privs Thread-Attribut setzen zu müssen;\nErlauben-/Verweigern-Regeln für Gerätesteuergruppen verändern;\nptrace(2) PTRACE_SECCOMP_GET_FILTER Aktionen einsetzen, um die Seccomp-Filter verfolgter Prozesse auszugeben;\ndie 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);\nadministrative Aktionen auf vielen Gerätetreibern ausführen.\nAutogroup-Nice-Werte durch Schreiben von /proc/[PID]/autogroup (siehe sched(7)) verändern.\nreboot(2) und kexec_load(2) verwenden.\nEinhängenamensräume mittels setns(2) ändern.\nKernelmodule laden und entladen (siehe init_module(2) und delete_module(2));\nin Kerneln vor 2.6.25: Capabilitys aus der systemweiten Capability-Begrenzungsmenge entfernen.\nden Nice-Wert von Prozessen erhöhen (nice(2), setpriority(2)) und den Nice-Wert von beliebigen Prozessen ändern;\nEchtzeit-Scheduling-Richtlinien zum Prozessaufruf und Scheduling-Richtlinien und -Prioritäten für beliebige Prozesse setzen (sched_setscheduler(2), sched_setparam(2), sched_setattr(2));\nCPU-Affinität für beliebige Prozesse setzen (sched_setaffinity(2));\nE/A-Scheduling-Klassen und -Prioritäten für beliebige Prozesse setzen (ioprio_set(2));\nmigrate_pages(2) auf beliebige Prozesse anwenden und Prozessen erlauben, auf beliebige Knoten zu migrieren;\nmove_pages(2) auf beliebige Prozesse anwenden;\nden Schalter MPOL_MF_MOVE_ALL mit mbind(2) und move_pages(2) verwenden.\nNachverfolgen beliebiger Prozesse mittels ptrace(2);\nget_robust_list(2) auf beliebige Prozesse anwenden;\nDaten vom oder zum Speicher beliebiger Prozesse mittels process_vm_readv(2) und process_vm_writev(2) übertragen;\nProzesse mittels kcmp(2) inspizieren.\nE/A-Port-Aktionen ausführen (iopl(2) und ioperm(2));\nauf /proc/kcore zugreifen;\ndie FIBMAP-Aktion ioctl(2) einsetzen;\nGeräte für den Zugriff auf x86-modellspezifische Register (MSRs, siehe msr(4)) öffnen;\nSpeichereinblendungen an Adressen unterhalb des durch /proc/sys/vm/mmap_min_addr angegebenen Wertes erstellen;\nDateien in /proc/bus/pci einblenden;\n/dev/mem und /dev/kmem öffnen;\nverschiedene SCSI-Geräte-Befehle ausführen;\nbestimmte Aktionen auf hpsa(4)- und cciss(4)-Geräten ausführen;\neine Reihe von Geräte-spezifischen Aktionen auf anderen Geräten ausführen.\nreservierten Platz auf Ext2-Dateisystemen verwenden;\nioctl(2)-Aufrufe ausführen, die das Journaling von Ext3 steuern;\nPlatten-Kontingent-Begrenzungen außer Kraft setzen;\nRessourcenbegrenzungen erhöhen (siehe setrlimit(2));\nmaximale Anzahl von Konsolen bei der Konsolenzuteilung außer Kraft setzen;\nmaximale Anzahl an Tastaturdefinitionen außer Kraft setzen;\nmehr als 64 Hz-Unterbrechungen von der Echtzeituhr erlauben;\ndie msg_qbytes-Begrenzung für eine System-V-Nachrichtenwarteschlange über die Grenze in /proc/sys/kernel/msgmnb anheben (siehe msgop(2) und msgctl(2));\nerlauben, 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));\ndie /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;\nF_SETPIPE_SZ verwenden, um die Kapazität einer Pipe über die in /proc/sys/fs/pipe-max-size angegebene Grenze erhöhen;\ndie /proc/sys/fs/mqueue/queues_max-Begrenzung beim Erstellen von POSIX-Nachrichtenwarteschlangen (siehe mq_overview(7)) außer Kraft setzen;\ndie prctl(2)-Aktion PR_SET_MM einsetzen;\n/proc/[PID]/oom_score_adj auf einen Wert niedriger als den zuletzt durch einen Prozess mit CAP_SYS_RESOURCE gesetzten Wert setzen.\nSystemuhr setzen (settimeofday(2), stime(2), adjtimex(2)); Echtzeit- (Hardware-)Uhr setzen.\nvhangup(2) einsetzen; verschiedene privilegierte ioctl(2)-Aktionen auf virtuelle Terminals einsetzen.\nCAP_SYSLOG (seit Linux 2.6.37)\nPrivilegierte syslog(2)-Aktionen ausführen. Siehe syslog(2) für Informationen, welche Aktionen Privilegien benötigen.\nÜ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).)\nCAP_WAKE_ALARM (seit Linux 3.0)\nEtwas auslösen, dass das System aufwecken wird (siehe die Timer CLOCK_REALTIME_ALARM und CLOCK_BOOTTIME_ALARM).\nFrühere und heutige Implementierungen¶\nEine komplette Implementierung von Capabilitys verlangt folgendes:\nFür alle privilegierten Aktionen muss der Kernel prüfen, ob der Thread die benötigten Capabilitys in seiner effektiven Menge hat.\nDer Kernel muss Systemaufrufe bereitstellen, die es erlauben, dass die Capability-Menge des Threads geändert und ermittelt wird.\nDas Dateisystem muss das Anhängen von Capabilitys an ausführbare Dateien erlauben, so dass ein Prozess solche Capabilitys erhält, wenn die Datei ausgeführt wird.\nVor Kernel 2.6.24 waren nur die ersten zwei dieser Anforderungen erfüllt, seit Kernel 2.6.24 sind alle drei Anforderungen erfüllt.\nHinweise für Kernel-Entwickler¶\nWenn Sie eine neue Kernel-Funktionalität hinzufügen, die über eine Capability geregelt werden soll, beachten Sie die nachfolgenden Punkte.\nDas 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.\nSie 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.)\nUm 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.\nVerwenden 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.\nFalls 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.\nCapability-Mengen von Threads¶\nJeder Thread hat die folgenden Capability-Mengen, die null oder mehr der oben aufgeführten Capabilitys enthalten:\nDies ist die begrenzende Übermenge für die effektiven Capabilitys, 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.\nFalls 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-Capabilitys diese Capability wieder bewilligen).\nDies ist eine Menge von Capabilitys, die über execve(2) hinweg erhalten bleiben. Vererbbare Capabilitys 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.\nDa vererbbare Capabilitys im allgemeinen nicht über execve(2)-Aufrufe erhalten werden, wenn dies nicht als Benutzer root erfolgt, sollten Anwendungen, die Hilfsprogramme mit erhöhten Capabilitys ausführen wollen, die Verwendung der unten beschriebenen Umgebungs-Capabilitys in Betracht ziehen.\nDies ist die Menge an Capabilitys, der vom Kernel zur Durchführung von Rechteprüfungen für den Thread verwandt wird.\nBounding (pro-Thread seit Linux 2.6.25)\nDie Capability-Begrenzungsmenge ist ein Mechanismus, der zur Begrenzung der Capabilitys, die während eines execve(2) erlangt werden, dienen kann.\nSeit 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.\nFür weitere Details über die Capability-Begrenzungsmenge, siehe unten.\nAmbient (Umgebung) (seit Linux 4.3)\nDies ist eine Menge von Capabilitys, 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.\nDie Umgebungs-Capability-Menge kann direkt mit prctl(2) verändert werden. Umgebungs-Capabilitys werden automatisch abgesenkt, falls entweder die entsprechende erlaubte oder vererbbare Capability abgesenkt wird.\nWird 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-Capabilitys verfügt, dann wird die Umgebungsmenge geleert. Umgebungs-Capabilitys werden zu der erlaubten Menge hinzugefügt und der effektiven Menge zugewiesen, wenn execve(2) aufgerufen wird. Falls Umgebungs-Capabilitys dazu führen, dass die erlaubten und effektiven Capabilitys während eines execve(2) anwachsen, löst dies keinen sicheren Ausführmodus, wie in ld.so(8) beschrieben, aus.\nEin mittels fork(2) erstelltes Kind erbt Kopien der Eltern-Capability-Menge. Lesen Sie weiter unten eine Diskussion der Behandlung von Capabilitys während execve(2).\nMittels capset(2) kann ein Thread seine eigenen Capability-Mengen bearbeiten (siehe unten).\nSeit 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.\nSeit 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 Capabilitys nach einem execve(2).\nDie drei Datei-Capability-Mengen sind:\nPermitted (erlaubt, früher als forced (erzwungen) bekannt):\nDiese Capabilitys werden dem Thread automatisch erlaubt, unabhängig von den geerbten Capabilitys des Threads.\nInheritable (vererbbar, früher als allowed (erlaubt) bekannt):\nDiese Menge wird mittels AND mit der vererbbaren Menge des Threads verknüpft, um zu bestimmen, welche vererbbaren Capabilitys in der erlaubten Menge des Threads nach einem execve(2) aktiviert werden.\nDies 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 Capabilitys in der neuen effektiven Menge sein.\nAktivieren 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 Capabilitys 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 Capabilitys, für die die entsprechenden erlaubten oder vererbbaren Schalter aktiviert sind, spezifiziert werden.\nErweiterte Attributversionierung von Datei-Capabilitys¶\nUm 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-Capabilitys verwandt wird. Diese Versionsnummern sind implementierungsintern und für Benutzerraum-Anwendungen nicht direkt sichtbar. Derzeit werden die folgenden Versionen unterstützt:\nDies war die ursprüngliche Datei-Capability-Implementierung, die 32-Bit-Masken für Datei-Capabilitys unterstützte.\nVFS_CAP_REVISION_2 (seit Linux 2.6.25)\nDiese Version erlaubt Datei-Capability-Masken in der Größe von 64 Bit und wurde notwendig, da die Anzahl an unterstützen Capabilitys 32 überstieg. Der Kernel unterstützt weiterhin transparent die Ausführung von Dateien mit 32-Bit-Version-1-Capability-Masken, aber wenn Capabilitys zu Dateien hinzugefügt werden, die bisher keine Capabilitys hatten, oder Capabilitys von bestehenden Dateien geändert werden, wird automatisch das Version-2-Schema (oder möglicherweise das unten beschriebene Version-3-Schema) verwandt.\nVFS_CAP_REVISION_3 (seit Linux 4.14)\nVersion-3-Datei-Capabilitys werden zur Unterstützung von (nachfolgend beschriebenen) namensraumbezogenen Datei-Capabilitys bereitgestellt.\nWie bei Version-2-Datei-Capabilitys 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.)\nVersion-3-Datei-Capabilitys sind so entwickelt worden, dass sie mit Version-2-Capabilitys koexistieren können, d.h. auf einem modernen Linux-System können einige Dateien Version-2-Capabilitys tragen, während andere Version-3-Capabilitys haben.\nVor Linux 4.14 war die einzige Art des erweiterten Attributs für Datei-Capabilitys, 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.\nSeit 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:\nDer 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.)\nDer 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.\nWenn ein erweitertes Attribut VFS_CAP_REVISION_3 security.capability erstellt wird, wird die Wurzelbenutzerkennung des erstellenden Namensraums des Benutzers in dem erweiterten Attribut gespeichert.\nIm 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.\nBeachten Sie, dass die Erstellung von erweiterten Version 3-security.capability-Attributen automatisch erfolgt. Mit anderen Worten: Der Kernel wird automatisch ein Version-3-Attribut erstellen, falls das Attribut unter den oben beschriebenen Umständen erstellt wird, wenn eine Anwendung im Benutzerraum ein security.capability-Attribut im Version-2-Format schreibt (setxattr(2)). Entsprechend wird das zurückgelieferte Attribut (automatisch) vereinfacht, um als Version-2-Attribut zu erscheinen (d.h. der Rückgabewert ist die Größe eines Version-2-Attrbutes und enthält nicht die Root-Benutzerkennung), wenn ein Version-3-security.capability-Attribut durch einen Prozess, der sich innerhalb eines Benutzernamensraums befindet, der durch die Root-Benutzerkennung (oder einem Abkömling dieses Namensraums) erstellt wurde, abgefragt wird. Diese automatische Übersetzung bedeutet, dass an den Werkzeugen im Benutzerraum (z.B. setcap(1) und getcap(1)) keine Änderung vorgenommen werden muss, damit diese Werkzeuge zum Erstellen und Abfragen von Version-3-security.capability-Attributen verwandt werden können.\nBeachten 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.\nUmwandlungen von Capabilitys während execve()¶\nWährend eines execve(2) berechnet der Kernel die neuen Capabilitys eines Prozesses mit dem folgenden Algorithmus:\nP'(ambient)     = (Datei ist privilegiert) ? 0 : P(ambient)\nP'(inheritable) = P(inheritable)    [d.h. unverändert]\nP'(bounding)    = P(bounding)       [d.h. unverändert]\nbezeichnet den Wert einer Capability-Menge des Threads vor dem execve(2)\nbezeichnet den Wert einer Capability-Menge des Threads nach dem execve(2)\nbezeichnet eine Datei-Capability-Menge\nBeachten Sie die nachfolgenden Details in Hinblick auf die obigen Capability-Umwandlungsregeln:\nDie 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 Capabilitys verfügt oder das Bit »set-user-ID« oder »set-group-ID« gesetzt hat.\nVor 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.\nHinweis: 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-Capabilitys ignoriert (als leer betrachtet) werden; siehe execve(2). Ähnlich werden Datei-Capabilitys ignoriert, falls der Kernel mit der Option no_file_caps gestartet wurde.\nHinweis: Entsprechend den obigen Regeln werden alle Capabilitys, die in der erlaubten und effektiven Menge vorhanden sind, zurückgesetzt, falls ein Prozess mit von Null verschiedenen Benutzerkennungen ein execve(2) durchführt. Für die Behandlung der Capabilitys, wenn ein Prozess mit der Benutzerkennung Null ein execve(2) durchführt, siehe unten unter Capabilitys und Ausführung von Programmen durch root.\nSicherheitsprüfungen für Capability-unfähige Programme¶\nEin Capability-unfähiges Programm ist eine Anwendung, die für Datei-Capabilitys markiert ist, aber noch nicht für die Verwendung des libcap(3)-APIs zur Bearbeitung seiner Capabilitys konvertiert wurde. (Mit anderen Worten, dies ist ein traditionelles »set-user-ID-root«-Programm, das auf Datei-Capabilitys umgestellt wurde, aber dessen Code nicht angepasst wurde, um mit Capabilitys umzugehen.) Für solche Anwendungen wird das effektive Capability-Bit auf die Datei gesetzt, so dass die erlaubten Capabilitys 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.\nBeim Ausführen eines Capability-unfähigen Programms prüft der Kernel nach den oben beschriebenen Umwandlungen, ob der Prozess alle erlaubten Capabilitys, 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 Capabilitys in der Datei-erlaubten Menge ausblenden könnte.) Falls der Prozess nicht die komplette Menge der Datei-erlaubten Capabilitys 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.\nCapabilitys und Ausführung von Programmen durch root¶\nUm die traditionellen UNIX-Semantiken abzubilden, führt der Kernel eine besondere Behandlung der Datei-Capabilitys durch, wenn ein Prozess mit UID 0 (root) ein Programm ausführt und wenn ein set-user-ID-root-Programm ausgeführt wird.\nNachdem 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:\nFalls 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 Capabilitys aktiviert) betrachtet. (Es gibt für dieses Verhalten eine Ausnahme, die unten in Set-user-ID-root-Programme, die Datei-Capabilitys haben beschrieben ist.)\nFalls 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.\nDiese fiktiven Werte für die Capability-Menge der Datei werden dann verwandt, um wie oben beschrieben den Übergang der Capabilitys des Prozesses während eines execve(2) zu berechnen.\nDaher vereinfacht sich die Berechnung der neuen erlaubten Capabilitys eines Prozesses wie folgt, wenn ein Prozess mit einer von 0 verschiedenen UID ein set-user-ID-root-Programm, das über keine Capabilitys 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:\nKonsequenterweise erlangt der Prozess alle Capabilitys 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.)\nDie in diesem Unterabschnitt beschriebene besondere Behandlung des Benutzers 0 (root) kann mittels des nachfolgend beschriebenen Securebits-Mechanismus deaktiviert werden.\nSet-user-ID-root-Programme, die Datei-Capabilitys haben¶\nEs gibt zu dem unter Capabilitys und Ausführung von Programmen durch root beschriebenen Verhalten eine Ausnahme. Falls (a) das ausgeführte Programm über Capabilitys 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-Capabilitys 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-Capabilitys verfügt. Wenn ein solches Programm ausgeführt wird, erlangt der Prozess nur die durch das Programm eingeräumten Capabilitys (d.h. nicht alle Capabilitys, was passierte, wenn ein set-user-ID-Root-Programm ausgeführt würde, das keine zugeordneten Datei-Capabilitys hat).\nBeachten 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 Capabilitys gewährt.\nDie Capability-Begrenzungsmenge ist ein Sicherheitsmechanismus, der zur Begrenzung der Capabilitys, die während eines execve(2) erlangt werden können, dienen kann. Die Begrenzungsmenge wird auf die folgende Art und Weise benutzt:\nWä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 Capabilitys dar, die einer ausführbaren Datei erlaubt werden dürfen.\n(Seit Linux 2.6.25) Die Capability-Begrenzungsmenge agiert als begrenzende Übermenge für die Capabilitys, 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 Capabilitys vorhanden ist, wenn er eine Datei mit execve(2) ausführt, die diese Capability in seiner vererbbaren Menge hat.\nBeachten Sie, dass die Begrenzungsmenge die erlaubten Datei-Capabilitys maskiert, aber nicht die vererbbaren Capabilitys. 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.\nAbhängig von der Kernelversion ist die Capability-Begrenzungsmenge entweder ein systemweites Attribut oder ein prozessweises Attribut.\nCapability-Begrenzungsmenge seit Linux 2.6.25\nSeit Linux 2.6.25 ist die Capability-Begrenzungsmenge ein pro-Thread-Attribut. (Die nachfolgend beschriebene systemweite Capability-Begrenzungsmenge existiert nicht mehr.)\nDie Begrenzungsmenge wird bei fork(2) von dem Elternprozess des Threads vererbt und bleibt über ein execve(2) erhalten.\nEin Thread kann mittels der Aktion prctl(2) PR_CAPBSET_DROP Capabilitys 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.\nEntfernen von Capabilitys aus der Begrenzungsmenge ist nur möglich, falls Datei-Capabilitys in den Kernel kompiliert wurden. In Kerneln vor Linux 2.6.33 waren Datei-Capabilitys 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-Capabilitys sind immer Teil des Kernels. Wenn Datei-Capabilitys in den Kernel kompiliert sind, beginnt der init-Prozess (der Urahn aller Prozesse) mit einer kompletten Begrenzungsmenge. Falls Datei-Capabilitys 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-Capabilitys gibt.\nDie 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.\nCapability-Begrenzungsmenge vor Linux 2.6.25\nIn 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.)\nNur der init-Prozess darf Capabilitys in der Capability-Begrenzungsmenge setzen; abgesehen davon kann der Superuser (oder genauer: ein Prozess mit der Capability CAP_SYS_MODULE) nur Capabilitys aus dieser Menge entfernen.\nAuf 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.\nDie systemweite Capability-Begrenzungsmengenfunktion wurde Linux in Version 2.2.11 hinzugefügt.\nEffekt von Benutzerkennungsänderungen auf Capabilitys¶\nUm 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:\nFalls 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 Capabilitys aus den erlaubten, effektiven und Umgebungs-Capability-Mengen gelöscht.\nFalls die effektive Benutzerkennung von 0 auf einen von 0 verschiedenen Wert geändert wird, werden alle Capabilitys aus der effektiven Menge gelöscht.\nFalls die effektive Benutzerkennung von einem von 0 verschiedenen Wert auf 0 geändert wird, dann wird die erlaubte Menge in die effektive Menge kopiert.\nFalls die Dateisystem-Benutzerkennung von 0 auf einen anderen Wert geändert wird (siehe setfsuid(2)), dann werden die folgenden Capabilitys 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 Capabilitys, die in der erlaubten Menge aktiviert waren, in der effektiven Menge aktiviert.\nFalls 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.\nProgrammatische Anpassung von Capability-Mengen¶\nEin 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:\nFalls 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.\n(Seit Linux 2.6.25) Die neue vererbbare Menge muss eine Teilmenge der Kombination der bestehenden vererbbaren Menge und der Capability-Begrenzungsmenge sein.\nDie neue erlaubte Menge muss eine Teilmenge der bestehenden erlaubten Menge sein (d.h. es ist nicht möglich, erlaubte Capabilitys zu erlangen, die der Thread derzeit nicht hat).\nDie neue effektive Menge muss eine Teilmenge der neuen erlaubten Menge sein.\nDer Schalter securebits: eine reine Capability-Umgebung einrichten¶\nBeginnend mit Kernel 2.6.26 und mit einem Kernel, in dem Datei-Capabilitys aktiviert sind, implementiert Linux eine Menge von pro-Thread-securebits-Schaltern, die zur Deaktivierung von spezieller Handhabung von Capabilitys für UID 0 (root) verwandt werden können. Dies sind die folgenden Schalter:\nDurch Setzen dieses Schalters darf ein Thread, der mindestens eine 0 UID hat, Capabilitys 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 Capabilitys verliert. Dieser Schalter wird bei execve(2) immer bereinigt.\nBachten Sie, dass selbst mit gesetztem Schalter SECBIT_KEEP_CAPS die effektiven Capabilitys 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 Capabilitys nicht bereinigt.\nDie 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.)\nDieser Schalter stellt die gleiche Funktionalität wie die ältere Aktion prctl(2) PR_SET_KEEPCAPS bereit.\nSetzen 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 Capabilitys)\nFalls dieses Bit gesetzt ist, dann verleiht der Kernel keine Capabilitys, 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 Capabilitys und Ausführung von Programmen durch root)\nDurch Setzen dieses Schalters dürfen keine Umgebungs-Capabilitys mit der prctl(2)-Aktion PR_CAP_AMBIENT_RAISE gehoben werden.\nJeder 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.\nDie 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.\nDie Schalter securebits werden von Kindprozessen vererbt. Während eines execve(2) werden alle Schalter beibehalten, außer SECBIT_KEEP_CAPS, das immer bereinigt wird.\nEine 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, Capabilitys zu erlangen, darin besteht, ein Programm auzuführen, das über die zugeordneten Datei-Capabilitys verfügt:\n/* Setzen/Sperren von SECBIT_NO_CAP_AMBIENT_RAISE\nist nicht erforderlich */\nEin set-user-ID-Programm, dessen UID auf die UID passt, die einen Benutzernamensraum erstellte, wird die Capabilitys in den erlaubten und effektiven Mengen übertragen, wenn es durch irgendeinen Prozess innerhalb dieses Namensraums (oder einen Benutzernamensraum, der davon abstammt) ausgeführt wird.\nDie obigen Regeln über die Umwandlung der Capabilitys des Prozesses während eines execve(2) werden genau in den Unterabschnitten Umwandlungen von Capabilitys während execve() und Capabilitys und Ausführung von Programmen durch root beschrieben, wobei im letzeren Unterabschnitt als Unterschied »root« die UID des Erstellers des Benutzernamensraums ist.\nTraditionelle (d.h. Version 2-)Datei-Capabilitys ordnen nur eine Menge von Capability-Masken einem binären Programm zu. Wenn ein Prozess ein Programm mit solchen Capabilitys ausführt, erlangt es die zugeordneten Capabilitys (innerhalb seines Benutzernamensraums) wie in den oben beschriebenen Regeln »Umwandlungen von Capabilitys während execve()« beschrieben.\nDa Version-2-Datei-Capabilitys dem ausführenden Prozess unabhängig davon, in welchem Namensraum er sich befindet, Capabilitys verleiht, dürfen nur privilegierte Prozesse Capabilitys 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-Capabilitys nutzlos sind. Es kann zum Beispiel in namensraumbezogenen Containern wünschenswert sein, in der Lage zu sein, ein Programm zu erstellen, das Capabilitys nur an Prozesse, die innerhalb dieses Containers ausgeführt werden, zu verleihen, aber nicht an Prozesse, die außerhalb des Containers ausgeführt werden.\nLinux 4.14 fügte sogenannte namensraumbezogene Datei-Capabilitys hinzu, um solche Fälle zu unterstützen. Namensraumbezogene Datei-Capabilitys 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-Capabilitys« 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.\nWie 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() Capabilitys an einen Prozess. Allerdings werden Capabilitys 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.\nInteraktion mit Benutzernamensräumen¶\nFür weitere Informationen über die Interaktion von Capabilitys und Benutzer-Namensräumen lesen Sie user_namespaces(7).\nKeine Standards regeln Capabilitys; die Linux-Capability-Implementierung basiert aber auf dem zurückgezogenen POSIX.1e-Entwurfsstandard; siehe https://archive.org/details/posix_1003.1e-990310.\nBeim Versuch, strace(1) auf Programme anzuwenden, die über Capabilitys verfügen (oder set-user-ID-root-Programme), könnten Sie die Option -u <Benutzername> nützlich finden. Etwas von der Art:\n$ sudo strace -o trace.log -u ceci ./meinprivprog\nVon Kernel 2.5.27 bis Kernel 2.6.26 waren Capabilitys eine optionale Kernelkomponente, die über die Kernelkonfigurationsoption CONFIG_SECURITY_CAPABILITIES aktiviert/deaktiviert werden könnte.\nDie 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 Capabilitys in diesen Mengen als aktiviert (1) angezeigt. Seit Linux 3.8 werden alle nicht existierenden Capabilitys (über CAP_LAST_CAP) als deaktiviert (0) angezeigt.\nDas Paket libcap stellt eine Suite von Routinen zum Setzen und Abfragen von Capabilitys 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:\nVor Kernel 2.6.24 und von Kernel 2.6.24 bis Kernel 2.6.32, falls Datei-Capabilitys nicht aktiviert sind, kann ein Thread mit der Capability CAP_SETPCAP die Capabilitys 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:\nIn 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.\nFalls Datei-Capabilitys 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.\ninclude/linux/capability.h in dem Linux-Kernelquellbaum\nDie deutsche Übersetzung dieser Handbuchseite wurde von Dr. Tobias Quathamer <toddy@debian.org> und Helge Kreutzmann <debian@helgefjell.de> erstellt.\n2. August 2019 Linux\nSource file: capabilities.7.de.gz (from manpages-de 4.10.0-1~bpo10+1)


L137: Schulkinder freuen sich über neu sanierten Radweg an der Moerser Straße in Duisburg - Straßen.NRW\nDuisburg (straßen.nrw). Die Straßen.NRW-Regionalniederlassung Niederrhein hat ihr Versprechen eingelöst: Pünktlich zur ersten Schulwoche nach den Herbstferien konnte der neu sanierte Radweg an der L137, der Moerser Straße in Duisburg-Kaldenhausen, wieder für den Verkehr freigeben werden.\nBesonders freuten sich darüber zwei Schülerinnen, deren täglicher Schulweg über diesen Radweg führt und die ab sofort den neu sanierten Radweg nutzen können. Ekkehard Deußen, Straßen.NRW-Niederlassungsleiter der Regionalniederlassung Niederrhein, traf sich vor Ort mit den beiden Mädchen, um mit ihnen die durchgeführten Baumaßnahmen vor Ort in Augenschein zu nehmen.\nGiulia und Finja hatten über die ZDF-Kindersendungen PUR+ und logo! auf den aus ihrer Sicht gefährlichen Schulweg aufmerksam gemacht. Bei einem Vor-Ort-Termin Ende Mai 2021 hatte sich Niederlassungsleiter Deußen gemeinsam mit den Kindern ein Bild der Situation vor Ort gemacht und den beiden versprochen, hier schnell für Verbesserungen zu sorgen.\nSo wurden unter anderem die Bäume an der Straße zurückgeschnitten, um für bessere Lichtverhältnisse zu sorgen. Die Fahrbahn des Radweges wurde erneuert und verbreitert und es wurden neue Markierungen aufgebracht, um besser auf den Radweg aufmerksam zu machen: Der Trennstreifen zwischen der Fahrbahn des Kraftfahrzeugverkehrs und dem Radweg wurde verbreitert, sodass ein größerer Abstand zum Fahrzeugverkehr entstanden ist. Durch das Aufstellen von Leitpfosten mit Reflektoren wurde die Trennung zum Fahrzeugverkehr deutlicher gekennzeichnet. Ebenfalls wurde die Asphaltdecke des Trennstreifens optisch mit einer Grünmarkierung hervorgehoben.\nAußerdem wurde eine vorhandene Mittelinsel auf Höhe der Moerser Straße 37 als Querungshilfe umgestaltet. Die Radfahrenden haben jetzt (analog zu den neuen Regelungen der StVO für Radfahrende) in Fahrtrichtung Moers die Wahl, entweder auf der Fahrbahn zu fahren oder im beidseitigen Verkehr auf dem sanierten Rad-/Gehwegbereich auf der Ostseite der L137 (siehe auch „Zum Thema“). Außerdem wurde die Geschwindigkeit vor Ort von 70 km/h auf 50 km/h reduziert.\nMit diesen Maßnahmen ist ein erstes Etappenziel zur Verbesserung der Verkehrssituation für Radfahrende an der Moerser Straße erreicht. Es wurden alle Möglichkeiten ausgeschöpft, die die örtlichen Gegebenheiten und die Rahmenbedingungen aktuell erlauben. Dennoch wird auch eine „große Lösung“ weiter im Blick behalten, etwa einen separat angelegten Radweg zu realisieren. Dazu bedarf es jedoch eines großen Aufwandes, nicht nur finanziell und planungstechnisch, sondern auch, was die erforderlichen Verwaltungsverfahren betrifft (so wäre dazu etwa auch ein Planfeststellungsverfahren erforderlich, das mehrere Jahre in Anspruch nehmen kann).\nZum Thema: Radverkehrsnovelle – Aufhebung der Radwegenutzungspflicht\nGut zu wissen: Die Radverkehrsnovelle der StVO erlaubt es seit einem Gerichtsurteil des Bundesverwaltungsgerichtes im Jahr 2010, dass Radfahrende in bestimmten Situationen selbst entscheiden können, ob sie eine vorhandenen Radverkehrsanlage nutzen oder eine Straße im sogenannten Mischverkehr mit Kraftfahrzeugen (also auf der Fahrbahn) befahren. Das bedeutet im aktuellen Fall: Das Verkehrszeichen mit dem Symbol „Fahrrad frei“ erlaubt dem Radverkehr von Duisburg kommend die Nutzung des angelegten Radweges entgegen der eigentlichen Fahrtrichtung (in Fahrtrichtung Moers). Durch die Verbreiterung des Radweges an der L137 können sich hier nun auch zwei Radfahrende gefahrlos begegnen. Dennoch haben die Radfahrenden auch die Möglichkeit, in Richtung Moers mit dem KfZ-Verkehr auf der Fahrbahn zu fahren. Für diejenigen, die von Moers kommen, ist die Benutzung des Radweges hingegen Pflicht. Dies symbolisiert das blaue Fahrrad-Verkehrszeichen.\nPressefoto: Freuen sich über den neu sanierten Radweg: Die Kinder Giulia und Finja sowie Straßen.NRW-Niederlassungsleiter Ekkehard Deußen (v.l.) (Quelle: Straßen.NRW) (JPG 4,5 MB)


Yan Chen gewinnt sein erstes WSOP-Bracelet - PokerWorld24\nYan Chen gewinnt sein erstes WSOP-Bracelet\nDer US-Amerikaner Yan Chen hat am frühen Dienstagmorgen sein erstes Bracelet bei der World Series of Poker (WSOP) gewonnen. Der 45jährige setzte sich im Heads-Up gegen Mike Wattel durch. Nachdem es für den Pokerprofi Yan Chen bislang in den vergangenen zwei Jahren zwei Mal zu einer Teilnahme am Finaltisch reichte, konnte er nun bei der WSOP 2010 Event 14 gewinnen.\nBei dem $1.500 2-7 Draw Lowball (No-Limit) Event im Rio Hotel und Casino in Las Vegas nahmen insgesamt 250 Spieler teil. Somit gab es hierbei einen Preispool in Höhe von $337.500, der an die besten 28 Spieler verteilt wurde. Für den Sieger Yan Chen gab es $92.817 neben dem goldenen Armband. Im finalen Heads-Up setzte sich Chen mit gegen von Mike Wattel durch. Für den Unterlegenen gab es ein Preisgeld in Höhe von $57.375. Ebenfalls am Final Table mit von der Partie war der Russe Alexander Kravchenko, der am Ende Rang sieben erspielen konnte. In die Preisgeldränge schaffte es auch der Österreicher Sigi Stockinger aus Linz, der am Ende Rang 25 belegte und dafür ein Preisgeld von $2.943 erhielt. Bereits vorzeitig verabschiedet hatten sich bei Event 14 der WSOP 2010 unter anderem Katja Thater und George Danzer, so wie auch Tom „durrrrr“ Dwan, Chad Brown, Lex Veldhuis, Annette Obrestad, John Juanda oder Dario Minieri.\nBei Event 13 der WSOP 2010 befinden sich die Teilnehmer augenblicklich in Tag 2 von vier geplanten Tagen. Von einstmals 3.042 gestarteten Teilnehmern bei dem $1.000 No Limit Hold’Em waren am Dienstagmorgen noch 98 Spieler verblieben. Angeführt wurde das Feld zu diesem Zeitpunkt von David Bakes Baker mit 270.000 Chips vor dem Engländer Daniel Carter (240.000) und Daniel Suied (225.000). Mit von der Partie ist momentan auch noch der Deutsche Markus Faller, der sich aber im hinteren Drittel des Chipcounts befindet. In die 324 Preisgeldränge geschafft haben es immerhin fünf Deutsche, der beste nach Faller ist dabei Elias Wölfl, der für Rang 123 immerhin $2.847 kassierte.\nHoch interessant ist auch Event 15 der 41. WSOP im Rio in Las Vegas. Hierbei handelt es sich um die Seven Card Stud Hi-Low Split-8 or better World Championship mit einem Buy-In von 10.000 US-Dollar. Hier haben insgesamt 170 Pokerspieler die Karten in die Hand genommen und für einen Preispool in Höhe von $1.598.000 gesorgt. Allein auf den Sieger warten am morgigen Mittwoch $447.446 – neben dem Bracelet für Event 15 versteht sich. Ein Preisgeld gibt es für die ersten 16 Plätze und am Dienstagmorgen an Tag 2 waren noch 32 Spieler vertreten. Während hier einige Hochkaräter im Teilnehmerfeld wie Men Nguyen, Chad Brown, Doyle Brunson, Andy Bloch, Barry Greenstein oder Phil Ivey bereits die Segel streichen mussten, waren deutsche Vertreter erst gar nicht mit von der Partie. Angeführt wurde der Chipcount am Dienstagmorgen von Gary Benson mit 400.000 Chips vor Steve Zolotow (278.000) und John Juanda (270.000). Ebenfalls noch mit von der Partie waren unter anderem Dario Minieri, Jason Mercier, Dan Heimiller, Vladimir Schmelev oder Phil Hellmuth. Die Entscheidung bei Event 15 der WSOP 2010 fällt am morgigen Mittwoch an Tag 3 und pokerworld24.org wird Dich darüber auf dem Laufenden halten.


Milliardenrisiken bei Trennung von Schiene- und Zugbetrieb: Mehdorn: Trennung von Netz gefährdet Reform\nMilliardenrisiken bei Trennung von Schiene- und Zugbetrieb Mehdorn: Trennung von Netz gefährdet Reform\nEine Trennung von Schienennetz und Transport würde nach Ansicht von Bahnchef Hartmut Mehdorn die gesamte Zukunftsstrategie der Deutschen Bahn gefährden.\n17.05.2001 - 10:33 Uhr\nTrennung gefährdet die Bahnreform\ndpa BERLIN. Wenn die gültige Planung nicht gehalten werden könne, seien Risiken in Milliardenhöhe absehbar. Großinvestitionen müssten völlig neu bewertet werden, sagte Mehdorn am Donnerstag in Berlin. Eine Entscheidung über die Trennung von Trasse und Zugbetrieb dürfe keinesfalls bis zur Bundestagswahl im nächsten Jahr verschoben werden.\nWegen der dann erforderlichen Neubewertung von Großprojekten und Sanierungsverzögerungen könnte die gesamte Bahnreform in Frage gestellt werden. Eine aufgelöste Bahn wäre gegenüber ausländischen Konkurrenten schwer benachteiligt, sagte Mehdorn am Donnerstag bei der Vorlage des Geschäftsberichts für das vergangene Jahr in Berlin.\nEr fügt hinzu: "Wer aber glaubt, dass Wettbewerber aus Ländern mit geschützten Heimatmärkten sich hier die Rosinen herauspicken können und die Deutsche Bahn fährt dann den Rest in der Fläche, der irrt."\nFinanzvorstand Diethelm Sack kündigte für 2001 ein negatives Betriebsergebnis nach Zinsen an. Im vergangenen Jahr hatte die Bahn mit 199 Mill. ? noch positiv abgeschlossen. Schwarze Zahlen will der Konzern nach einer erwarteten mehrjährigen Verlustphase bis 2004 wieder erreichen.\nDer Chef der Bahngewerkschaft Transnet Norbert Hansen forderte statt weiterer Streichungen von Angeboten eine offensive Marktstrategie der Bahn. Dass jeder zweite Bürger noch nicht mit der Bahn gefahren sei, zeige welch großes Kundenpotenzial es gebe, sagte Hansen im ZDF-Morgenmagazin.


« Zurück | TopVintage » Kleidung » Hosen & Playsuits » Hosen » King Louie » 40s Ava Pablo Straight Pants in Apple Pink\nTags 40s , 7/8 Hosen , Polkadot , Sustainable Fashion\nMit dieser 40s Ava Pablo Straight Pants in Apple Pink wird es ein Kinderspiel sein um dich von deiner retro und stilvollen Seite zu zeigen! Diese wundervolle Hose ist versehen mit einer dazupassenden Bindeschleife und schmeichelhaften, gerade geschnittenen 7/8 Hosenbeinen. Aus herrlich geschmeidiger Viskose (nicht dehnbar) in einem sanften Rotton und mit einem Muster aus cremefarbenen Polkadots. Bekommt dieses Schätzchen von dir auch die volle Punktzahl? ;-)\nGerade geschnittene, 7/8 Hosenbeine