.\" -*- coding: UTF-8 -*- .\" Copyright (c) 2002 by Michael Kerrisk .\" .\" %%%LICENSE_START(VERBATIM) .\" Permission is granted to make and distribute verbatim copies of this .\" manual provided the copyright notice and this permission notice are .\" preserved on all copies. .\" .\" Permission is granted to copy and distribute modified versions of this .\" manual under the conditions for verbatim copying, provided that the .\" entire resulting derived work is distributed under the terms of a .\" permission notice identical to this one. .\" .\" Since the Linux kernel and libraries are constantly changing, this .\" manual page may be incorrect or out-of-date. The author(s) assume no .\" responsibility for errors or omissions, or for damages resulting from .\" the use of the information contained herein. The author(s) may not .\" have taken the same level of care in the production of this manual, .\" which is licensed free of charge, as they might when working .\" professionally. .\" .\" Formatted or processed versions of this manual, if unaccompanied by .\" the source, must acknowledge the copyright and authors of this work. .\" %%%LICENSE_END .\" .\" 6 Aug 2002 - Initial Creation .\" Modified 2003-05-23, Michael Kerrisk, .\" Modified 2004-05-27, Michael Kerrisk, .\" 2004-12-08, mtk Added O_NOATIME for CAP_FOWNER .\" 2005-08-16, mtk, Added CAP_AUDIT_CONTROL and CAP_AUDIT_WRITE .\" 2008-07-15, Serge Hallyn .\" Document file capabilities, per-process capability .\" bounding set, changed semantics for CAP_SETPCAP, .\" and other changes in 2.6.2[45]. .\" Add CAP_MAC_ADMIN, CAP_MAC_OVERRIDE, CAP_SETFCAP. .\" 2008-07-15, mtk .\" Add text describing circumstances in which CAP_SETPCAP .\" (theoretically) permits a thread to change the .\" capability sets of another thread. .\" Add section describing rules for programmatically .\" adjusting thread capability sets. .\" Describe rationale for capability bounding set. .\" Document "securebits" flags. .\" Add text noting that if we set the effective flag for one file .\" capability, then we must also set the effective flag for all .\" other capabilities where the permitted or inheritable bit is set. .\" 2011-09-07, mtk/Serge hallyn: Add CAP_SYSLOG .\" .\"******************************************************************* .\" .\" This file was generated with po4a. Translate the source file. .\" .\"******************************************************************* .TH CAPABILITIES 7 "13. August 2020" Linux Linux\-Programmierhandbuch .SH BEZEICHNUNG capabilities \- Überblick über Linux\-Capabilitys .SH BESCHREIBUNG Für den Zweck der Durchführung von Rechteprüfungen unterscheiden traditionelle UNIX\-Implementierungen zwei Arten von Prozessen: \fIPrivilegierte\fP Prozesse (deren effektive Benutzerkennung 0 ist, auch als Superuser oder Root benannt) und \fIunprivilegierte\fP 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. .PP .\" Beginnend mit Kernel 2.2 unterteilt Linux die Privilegien, die traditionell mit dem Superuser assoziiert sind, in getrennte Einheiten, die als \fICapabilitys\fP bekannt sind. Diese können unabhängig voneinander aktiviert oder deaktiviert werden. Capabilitys sind ein Attribut pro Thread. .SS "Liste der Capabilitys" Die folgende Liste zeigt die in Linux implementierten Capabilitys und die Aktionen oder Verhalten, die jede Capability erlaubt: .TP \fBCAP_AUDIT_CONTROL\fP (seit Linux 2.6.11) Kernel\-Auditierung aktivieren und deaktivieren; die Auditierung\-Filterregel ändern; den Auditstatus und Filterregel abfragen. .TP \fBCAP_AUDIT_READ\fP (seit Linux 3.16) .\" commit a29b694aa1739f9d76538e34ae25524f9c549d59 .\" commit 3a101b8de0d39403b2c7e5c23fd0b005668acf48 Erlaubt das Schreiben des Audit\-Protokolls über einen Multicast\-Netlink\-Socket. .TP \fBCAP_AUDIT_WRITE\fP (seit Linux 2.6.11) .\" FIXME Add FAN_ENABLE_AUDIT Datensätze in das Audit\-Protokoll des Kernels schreiben. .TP \fBCAP_BLOCK_SUSPEND\fP (seit Linux 3.5) Funktionalitäten einsetzen, die die System\-Supsendierung blockieren können (\fBepoll\fP(7) \fBEPOLLWAKEUP\fP, \fI/proc/sys/wake_lock\fP). .TP \fBCAP_BPF\fP (seit Linux 5.8) privilegierte BPF\-Aktionen einsetzen; siehe \fBbpf\fP(2) und \fBbpf\-helpers\fP(7). .IP Diese Capability wurde in Linux 5.8 hinzugefügt, um die BPF\-Funktionalität aus der überladenen Capability \fBCAP_SYS_ADMIN\fP auszugliedern. .TP \fBCAP_CHECKPOINT_RESTORE\fP (seit Linux 5.9) .\" commit 124ea650d3072b005457faed69909221c2905a1f .PD 0 .RS .IP * 2 Aktualisiert \fI/proc/sys/kernel/ns_last_pid\fP (siehe \fBpid_namespaces\fP(7)); .IP * .\" FIXME There is also some use case relating to .\" prctl_set_mm_exe_file(); in the 5.9 sources, see .\" prctl_set_mm_map(). verwendet die Funktionalität \fIset_tid\fP von \fBclone3\fP(2); .IP * liest die Inhalte der symbolischen Links in \fI/proc/[PID]/map_files\fP für andere Prozesse. .RE .PD .IP Diese Capability wurde in Linux 5.9 hinzugefügt, um die Prüfpunkt\-/Wiederherstellungs\-Funktionalität aus der überladenen Capability \fBCAP_SYS_ADMIN\fP auszugliedern. .TP \fBCAP_CHOWN\fP beliebige Änderungen an Datei\-UIDs und GIDs vornehmen (siehe \fBchown\fP(2)). .TP \fBCAP_DAC_OVERRIDE\fP Lese\-, Schreibe und Ausführrechteprüfungen umgehen. (DAC ist die Abkürzung für »discretionary access control«, benutzerbestimmbare Zugriffssteuerung) .TP \fBCAP_DAC_READ_SEARCH\fP .PD 0 .RS .IP * 2 Dateileserechteprüfungen und Verzeichnislese\- und \-ausführrechteprüfungen umgehen. .IP * \fBopen_by_handle_at\fP(2) aufrufen. .IP * Verwenden Sie den Schalter \fBAT_EMPTY_PATH\fP von \fBlinkat\fP(2), um einen Link auf eine Datei, auf die sich ein Dateideskriptor bezieht, zu erstellen. .RE .PD .TP \fBCAP_FOWNER\fP .PD 0 .RS .IP * 2 Rechteprüfungen umgehen, die normalerweise verlangen, dass die Dateisystem\-UID des Prozesses mit der UID der Datei übvereinstimmt (z.B. \fBchmod\fP(2), \fButime\fP(2)), hierbei sind Aktionen, die durch \fBCAP_DAC_OVERRIDE\fP und \fBCAP_DAC_READ_SEARCH\fP abgedeckt sind, ausgeschlossen; .IP * Inode\-Schalter für beliebige Dateien setzen (siehe \fBioctl_iflags\fP(2)); .IP * Zugriffssteuerlisten (»Access Control Lists«, ACLs) auf beliebige Dateien setzen; .IP * »sticky«\-Bit von Verzeichnissen beim Dateilöschen ignorieren; .IP * verändert \fIBenutzer\fP\-erweiterte Attribute bei »sticky«\-Verzeichnissen, die irgendeinem Benutzer gehören; .IP * \fBO_NOATIME\fP für beliebige Dateien in \fBopen\fP(2) und \fBfcntl\fP(2) setzen. .RE .PD .TP \fBCAP_FSETID\fP .PD 0 .RS .IP * 2 Set\-User\-ID\- und Set\-Group\-ID\-Modus\-Bits nicht zurücksetzen, wenn eine Datei verändert wird; .IP * 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. .RE .PD .TP \fBCAP_IPC_LOCK\fP .\" FIXME . As at Linux 3.2, there are some strange uses of this capability .\" in other places; they probably should be replaced with something else. Speicher sperren (\fBmlock\fP(2), \fBmlockall\fP(2), \fBmmap\fP(2), \fBshmctl\fP(2)). .TP \fBCAP_IPC_OWNER\fP Rechteprüfungen für Aktionen mit System\-V\-IPC\-Objekten umgehen. .TP \fBCAP_KILL\fP .\" FIXME . CAP_KILL also has an effect for threads + setting child .\" termination signal to other than SIGCHLD: without this .\" capability, the termination signal reverts to SIGCHLD .\" if the child does an exec(). What is the rationale .\" for this? Rechteprüfungen beim Senden von Signalen umgehen (siehe \fBkill\fP(2)). Dies schließt die \fBioctl\fP(2)\-\fBKDSIGACCEPT\fP\-Aktion mit ein. .TP \fBCAP_LEASE\fP (seit Linux 2.4) Etabliert Ausleihen für beliebige Dateien (siehe \fBfcntl\fP(2)). .TP \fBCAP_LINUX_IMMUTABLE\fP Setzt die Inode\-Schalter \fBFS_APPEND_FL\fP und \fBFS_IMMUTABLE_FL\fP (siehe \fBioctl_iflags\fP(2)). .TP \fBCAP_MAC_ADMIN\fP (seit Linux 2.6.25) MAC\-Konfiguration oder Statusänderungen erlauben. Implementiert für das Smack\-Linux\-Security\-Modul (LSM). .TP \fBCAP_MAC_OVERRIDE\fP (seit Linux 2.6.25) Mandatory Access Control (MAC) außer Kraft setzen. Für das Smack\-LSM implementiert. .TP \fBCAP_MKNOD\fP (seit Linux 2.4) Spezielle Dateien mittels \fBmknod\fP(2) erstellen. .TP \fBCAP_NET_ADMIN\fP Verschiedene Netz\-bezogene Aktionen durchführen: .PD 0 .RS .IP * 2 Schnittstellenkonfiguration; .IP * Administration von IP\-Firewall, Masquerading und Abrechnung; .IP * Routing\-Tabellen verändern; .IP * an beliebige Adresse für eine transparente Proxyfunktion binden; .IP * type\-of\-service (TOS) setzen; .IP * Treiberstatistiken bereinigen; .IP * den »promiscuous«\-Modus einschalten; .IP * Multicasting aktivieren; .IP * \fBsetsockopt\fP(2) verwenden, um die folgenden Socket\-Optionen zu setzen: \fBSO_DEBUG\fP, \fBSO_MARK\fP, \fBSO_PRIORITY\fP (für eine Priorität außerhalb des Bereichs 0 bis 6), \fBSO_RCVBUFFORCE\fP und \fBSO_SNDBUFFORCE\fP. .RE .PD .TP \fBCAP_NET_BIND_SERVICE\fP Einen Socket an einen privilegierten Internet\-Domain\-Port binden (Portnummern kleiner als 1024). .TP \fBCAP_NET_BROADCAST\fP .\" FIXME Since Linux 4.2, there are use cases for netlink sockets .\" commit 59324cf35aba5336b611074028777838a963d03b (Unbenutzt) Socket\-Broadcasts durchführen und auf Multicasts warten. .TP \fBCAP_NET_RAW\fP .PD 0 .RS .IP * 2 RAW\- und PACKET\-Sockets verwenden; .IP * an beliebige Adresse für eine transparente Proxyfunktion binden. .RE .PD .\" Also various IP options and setsockopt(SO_BINDTODEVICE) .TP \fBCAP_PERFMON\fP (seit Linux 5.8) verschiedene Leistungsüberwachungsmechanismen einzusetzen, einschließlich: .RS .IP * 2 .PD 0 \fBperf_event_open\fP(2) aufrufen; .IP * verschiedene BPF\-Aktionen einzusetzen, die Leistungsauswirkungen haben. .RE .PD .IP Diese Capability wurde in Linux 5.8 hinzugefügt, um die Überwachungsfunktionalität aus der überladenen Capability \fBCAP_SYS_ADMIN\fP auszugliedern. Siehe auch die Kernelquelldatei \fIDocumentation/admin\-guide/perf\-security.rst\fP. .TP \fBCAP_SETGID\fP .RS .PD 0 .IP * 2 Beliebige Manipulationen an den GIDs und der Liste der ergänzenden GIDs des Prozesses vornehmen; .IP * GID fälschen, wenn Socket\-Berechtigungsnachweise via UNIX\-Domain\-Sockets weitergebeben werden; .IP * eine Gruppenkennungs\-Abbildung in einen Benutzernamensraum schreiben (siehe \fBuser_namespaces\fP(7)). .PD .RE .TP \fBCAP_SETFCAP\fP (seit Linux 2.6.24) Setzt beliebige Capabilitys auf einer Datei. .TP \fBCAP_SETPCAP\fP Falls 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 \fBprctl\fP(2) \fBPR_CAPBSET_DROP\fP); nehme Änderungen an den \fIsecurebits\fP\-Schaltern vor. .IP 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 \fBCAP_SETPCAP\fP ist nicht verfügbar, falls der Kernel für die Unterstützung von Datei\-Capabilitys konfiguriert ist, da \fBCAP_SETPCAP\fP für diese Kernel eine komplett andere Semantik aufweist.) .TP \fBCAP_SETUID\fP .RS .PD 0 .IP * 2 beliebige Manipulationen der Prozess\-UIDs vornehmen (\fBsetuid\fP(2), \fBsetreuid\fP(2), \fBsetresuid\fP(2), \fBsetfsuid\fP(2)); .IP * UID fälschen, wenn Socket\-Berechtigungsnachweise via UNIX\-Domain\-Sockets weitergebeben werden; .IP * eine Benutzerkennung\-Abbildung in einen Benutzernamensraum schreiben (siehe \fBuser_namespaces\fP(7)). .PD .RE .\" FIXME CAP_SETUID also an effect in exec(); document this. .TP \fBCAP_SYS_ADMIN\fP \fIHinweis:\fP Diese Capability ist überladen, siehe \fIHinweise für Kernel\-Entwickler\fP weiter unten. .IP .PD 0 .RS .IP * 2 eine Reihe von Systemadministratoraktionen ausführen, darunter: \fBquotactl\fP(2), \fBmount\fP(2), \fBumount\fP(2), \fBpivot_root\fP(2), \fBswapon\fP(2), \fBswapoff\fP(2), \fBsethostname\fP(2) und \fBsetdomainname\fP(2); .IP * privilegierte \fBsyslog\fP(2)\-Aktion ausführen (seit Linux 2.6.37 sollte \fBCAP_SYSLOG\fP verwandt werden, um diese Aktion zu erlauben); .IP * den \fBVM86_REQUEST_IRQ\fP\-Befehl \fBvm86\fP(2) ausführen; .IP * auf die gleiche Prüfpunkt\-/Wiederherstellungsfunktionalität zugreifen, die durch \fBCAP_CHECKPOINT_RESTORE\fP gelenkt wird (die letztere, aber schwächere Capability wird für den Zugriff auf dieses Funktionalität bevorzugt). .IP * die gleichen BPF\-Aktionen durchführen, die durch \fBCAP_BPF\fP gelenkt werden (die letztere, aber schwächere Capability wird für den Zugriff auf dieses Funktionalität bevorzugt). .IP * die gleichen Leistungsüberwachungsmechanismen einsetzen, die durch \fBCAP_PERFMON\fP gelenkt werden (die letztere, aber schwächere Capability wird für den Zugriff auf dieses Funktionalität bevorzugt). .IP * \fBIPC_SET\fP\- und \fBIPC_RMID\fP\-Aktion auf beliebigen System\-V\-IPC\-Objekten ausführen; .IP * \fBRLIMIT_NPROC\fP\-Ressourcenbegrenzung außer Kraft setzen; .IP * Aktionen an den erweiterten Attributen \fItrusted\fP und \fIsecurity\fP durchführen (siehe \fBxattr\fP(7)); .IP * \fBlookup_dcookie\fP(2) verwenden; .IP * \fBioprio_set\fP(2) verwenden, um \fBIOPRIO_CLASS_RT\fP und (vor Linux 2.6.25) \fBIOPRIO_CLASS_IDLE\fP\-E/A\-Scheduling\-Klassen zuzuweisen; .IP * PID fälschen, wenn Socket\-Berechtigungsnachweise via UNIX\-Domain\-Sockets weitergebeben werden; .IP * die systemweite Grenze der Anzahl der offenen Dateien (\fI/proc/sys/fs/file\-max\fP) in Systemaufrufen, die Dateien öffnen (z.B. \fBaccept\fP(2), \fBexecve\fP(2), \fBopen\fP(2), \fBpipe\fP(2)) überschreiben; .IP * Schalter \fBCLONE_*\fP einsetzen, der neue Namensräume mit \fBclone\fP(2) und \fBunshare\fP(2) erstellt (seit Linux 3.8 benötigt die Erzeugung von Benutzernamensräumen allerdings keine Capability mehr); .IP * auf privilegierte \fIperf\fP\-Ereignisinformationen zugreifen; .IP * \fBsetns\fP(2) aufrufen (benötigt \fBCAP_SYS_ADMIN\fP im Namensraum \fItarget\fP); .IP * \fBfanotify_init\fP(2) aufrufen; .IP * privilegierte Aktionen \fBKEYCTL_CHOWN\fP und \fBKEYCTL_SETPERM\fP von \fBkeyctl\fP(2) ausführen; .IP * \fBmadvise\fP(2)\-\fBMADV_HWPOISON\fP\-Aktion ausführen; .IP * den \fBTIOCSTI\fP \fBioctl\fP(2) verwenden, um Zeichen in die Eingabewarteschlange eines Terminals, dass nicht das vom aufrufenden gesteuerte Terminal ist, einzufügen; .IP * veralteten Systemaufruf \fBnfsservctl\fP(2) verwenden; .IP * veralteten Systemaufruf \fBbdflush\fP(2) verwenden; .IP * verschiedene privilegierte Blockgeräte\-\fBioctl\fP(2)\-Aktion ausführen; .IP * verschiedene privilegierte Dateisystem\-\fBioctl\fP(2)\-Aktionen ausführen; .IP * privilegierte \fBioctl\fP(2)\-Aktionen am Gerät \fI/dev/random\fP durchführen (siehe \fBrandom\fP(4)); .IP * einen \fBseccomp\fP(2)\-Filter installieren, ohne zuerst das \fIno_new_privs\fP Thread\-Attribut setzen zu müssen; .IP * Erlauben\-/Verweigern\-Regeln für Gerätesteuergruppen verändern; .IP * \fBptrace\fP(2) \fBPTRACE_SECCOMP_GET_FILTER\fP Aktionen einsetzen, um die Seccomp\-Filter verfolgter Prozesse auszugeben; .IP * die Aktion \fBPTRACE_SETOPTIONS\fP von \fBptrace\fP(2) einsetzen, um den Seccomp\-Schutz des verfolgten Prozesses vorübergehend außer Kraft zu setzen (d.h. der Schalter \fBPTRACE_O_SUSPEND_SECCOMP\fP); .IP * administrative Aktionen auf vielen Gerätetreibern ausführen; .IP * Autogroup\-Nice\-Werte durch Schreiben von \fI/proc/[PID]/autogroup\fP (siehe \fBsched\fP(7)) verändern. .RE .PD .TP \fBCAP_SYS_BOOT\fP \fBreboot\fP(2) und \fBkexec_load\fP(2) verwenden. .TP \fBCAP_SYS_CHROOT\fP .RS .PD 0 .IP * 2 \fBchroot\fP(2) verwenden; .IP * Einhängenamensräume mittels \fBsetns\fP(2) ändern. .PD .RE .TP \fBCAP_SYS_MODULE\fP .RS .PD 0 .IP * 2 Kernelmodule laden und entladen (siehe \fBinit_module\fP(2) und \fBdelete_module\fP(2)); .IP * in Kerneln vor 2.6.25: Capabilitys aus der systemweiten Capability\-Begrenzungsmenge entfernen. .PD .RE .TP \fBCAP_SYS_NICE\fP .PD 0 .RS .IP * 2 den Nice\-Wert von Prozessen absenken (\fBnice\fP(2), \fBsetpriority\fP(2)) und den Nice\-Wert von beliebigen Prozessen ändern; .IP * Echtzeit\-Scheduling\-Richtlinien zum Prozessaufruf und Scheduling\-Richtlinien und \-Prioritäten für beliebige Prozesse setzen (\fBsched_setscheduler\fP(2), \fBsched_setparam\fP(2), \fBsched_setattr\fP(2)); .IP * CPU\-Affinität für beliebige Prozesse setzen (\fBsched_setaffinity\fP(2)); .IP * E/A\-Scheduling\-Klassen und \-Prioritäten für beliebige Prozesse setzen (\fBioprio_set\fP(2)); .IP * .\" FIXME CAP_SYS_NICE also has the following effect for .\" migrate_pages(2): .\" do_migrate_pages(mm, &old, &new, .\" capable(CAP_SYS_NICE) ? MPOL_MF_MOVE_ALL : MPOL_MF_MOVE); .\" .\" Document this. \fBmigrate_pages\fP(2) auf beliebige Prozesse anwenden und Prozessen erlauben, auf beliebige Knoten zu migrieren; .IP * \fBmove_pages\fP(2) auf beliebige Prozesse anwenden; .IP * den Schalter \fBMPOL_MF_MOVE_ALL\fP mit \fBmbind\fP(2) und \fBmove_pages\fP(2) verwenden. .RE .PD .TP \fBCAP_SYS_PACCT\fP \fBacct\fP(2) verwenden. .TP \fBCAP_SYS_PTRACE\fP .PD 0 .RS .IP * 2 Nachverfolgen beliebiger Prozesse mittels \fBptrace\fP(2); .IP * \fBget_robust_list\fP(2) auf beliebige Prozesse anwenden; .IP * Daten vom oder zum Speicher beliebiger Prozesse mittels \fBprocess_vm_readv\fP(2) und \fBprocess_vm_writev\fP(2) übertragen; .IP * Prozesse mittels \fBkcmp\fP(2) inspizieren. .RE .PD .TP \fBCAP_SYS_RAWIO\fP .PD 0 .RS .IP * 2 E/A\-Port\-Aktionen ausführen (\fBiopl\fP(2) und \fBioperm\fP(2)); .IP * auf \fI/proc/kcore\fP zugreifen; .IP * die \fBFIBMAP\fP\-Aktion \fBioctl\fP(2) einsetzen; .IP * Geräte für den Zugriff auf x86\-modellspezifische Register (MSRs, siehe \fBmsr\fP(4)) öffnen; .IP * \fI/proc/sys/vm/mmap_min_addr\fP aktualisieren; .IP * Speichereinblendungen an Adressen unterhalb des durch \fI/proc/sys/vm/mmap_min_addr\fP angegebenen Wertes erstellen; .IP * Dateien in \fI/proc/bus/pci\fP einblenden; .IP * \fI/dev/mem\fP und \fI/dev/kmem\fP öffnen; .IP * verschiedene SCSI\-Geräte\-Befehle ausführen; .IP * bestimmte Aktionen auf \fBhpsa\fP(4)\- und \fBcciss\fP(4)\-Geräten ausführen; .IP * eine Reihe von Geräte\-spezifischen Aktionen auf anderen Geräten ausführen. .RE .PD .TP \fBCAP_SYS_RESOURCE\fP .PD 0 .RS .IP * 2 reservierten Platz auf Ext2\-Dateisystemen verwenden; .IP * \fBioctl\fP(2)\-Aufrufe ausführen, die das Journaling von Ext3 steuern; .IP * Platten\-Kontingent\-Begrenzungen außer Kraft setzen; .IP * Ressourcenbegrenzungen erhöhen (siehe \fBsetrlimit\fP(2)); .IP * \fBRLIMIT_NPROC\fP\-Ressourcenbegrenzung außer Kraft setzen; .IP * maximale Anzahl von Konsolen bei der Konsolenzuteilung außer Kraft setzen; .IP * maximale Anzahl an Tastaturdefinitionen außer Kraft setzen; .IP * mehr als 64 Hz\-Unterbrechungen von der Echtzeituhr erlauben; .IP * die \fImsg_qbytes\fP\-Begrenzung für eine System\-V\-Nachrichtenwarteschlange über die Grenze in \fI/proc/sys/kernel/msgmnb\fP anheben (siehe \fBmsgop\fP(2) und \fBmsgctl\fP(2)); .IP * erlauben, die Ressourcenbegrenzung \fBRLIMIT_NOFILE\fP bezüglich der Anzahl der »laufenden« Dateideskriptoren zu umgehen, wenn Dateideskriptoren an andere Prozesse mittels UNIX\-Domain\-Sockets übergeben werden (siehe \fBunix\fP(7)); .IP * die \fI/proc/sys/fs/pipe\-size\-max\fP\-Begrenzung beim Setzen der Kapazität einer Pipe mittels des \fBF_SETPIPE_SZ\fP\-Befehls \fBfcntl\fP(2) außer Kraft setzen; .IP * \fBF_SETPIPE_SZ\fP verwenden, um die Kapazität einer Pipe über die in \fI/proc/sys/fs/pipe\-max\-size\fP angegebene Grenze erhöhen; .IP * die \fI/proc/sys/fs/mqueue/queues_max\fP, \fI/proc/sys/fs/mqueue/msg_max\fP, und \fI/proc/sys/fs/mqueue/msgsize_max\fP\-Begrenzungen beim Erstellen von POSIX\-Nachrichtenwarteschlangen (siehe \fBmq_overview\fP(7)) außer Kraft setzen; .IP * die \fBprctl\fP(2)\-Aktion \fBPR_SET_MM\fP einsetzen; .IP * \fI/proc/[PID]/oom_score_adj\fP auf einen Wert niedriger als den zuletzt durch einen Prozess mit \fBCAP_SYS_RESOURCE\fP gesetzten Wert setzen. .RE .PD .TP \fBCAP_SYS_TIME\fP Systemuhr setzen (\fBsettimeofday\fP(2), \fBstime\fP(2), \fBadjtimex\fP(2)); Echtzeit\- (Hardware\-)Uhr setzen. .TP \fBCAP_SYS_TTY_CONFIG\fP \fBvhangup\fP(2) einsetzen; verschiedene privilegierte \fBioctl\fP(2)\-Aktionen auf virtuelle Terminals einsetzen. .TP \fBCAP_SYSLOG\fP (seit Linux 2.6.37) .RS .PD 0 .IP * 2 Privilegierte \fBsyslog\fP(2)\-Aktionen ausführen. Siehe \fBsyslog\fP(2) für Informationen, welche Aktionen Privilegien benötigen. .IP * Über \fI/proc\fP bereitgestellte Kernel\-Adressen und andere Schnittstellen anschauen, wenn \fI/proc/sys/kernel/kptr_restrict\fP den Wert 1 hat. (Lesen Sie die Diskussion über \fIkptr_restrict\fP in \fBproc\fP(5).) .PD .RE .TP \fBCAP_WAKE_ALARM\fP (seit Linux 3.0) .\" Etwas auslösen, dass das System aufwecken wird (siehe die Timer \fBCLOCK_REALTIME_ALARM\fP und \fBCLOCK_BOOTTIME_ALARM\fP). .SS "Frühere und heutige Implementierungen" Eine komplette Implementierung von Capabilitys verlangt folgendes: .IP 1. 3 Für alle privilegierten Aktionen muss der Kernel prüfen, ob der Thread die benötigten Capabilitys in seiner effektiven Menge hat. .IP 2. Der Kernel muss Systemaufrufe bereitstellen, die es erlauben, dass die Capability\-Menge des Threads geändert und ermittelt wird. .IP 3. Das 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. .PP .\" 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. .SS "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. .IP * 3 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. .IP * 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.) .IP * 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. .IP * Verwenden Sie \fInicht\fP \fBCAP_SYS_ADMIN\fP, 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 \fBCAP_SYS_ADMIN\fP zugeordnet werden sollten, sind diejenigen, die \fIeng\fP zu bestehenden Anwendungsfällen in diesem Silo passen. .IP * .\" 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 \fBCAP_SYS_PACCT\fP 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. .SS "Capability\-Mengen von Threads" Jeder Thread hat die folgenden Capability\-Mengen, die null oder mehr der oben aufgeführten Capabilitys enthalten: .TP \fIPermitted\fP (erlaubt) Dies 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 \fBCAP_SETPCAP\fP in seiner effektiven Menge hat. .IP 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 \fBexecve\fP(2) aus oder ein Programm, dessen zugeordnete Datei\-Capabilitys diese Capability wieder bewilligen). .TP \fIInheritable\fP (vererbbar) Dies ist eine Menge von Capabilitys, die über \fBexecve\fP(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. .IP Da vererbbare Capabilitys im allgemeinen nicht über \fBexecve\fP(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. .TP \fIEffective\fP (effektiv) Dies ist die Menge an Capabilitys, der vom Kernel zur Durchführung von Rechteprüfungen für den Thread verwandt wird. .TP \fIBounding\fP (pro\-Thread seit Linux 2.6.25) Die Capability\-Begrenzungsmenge ist ein Mechanismus, der zur Begrenzung der Capabilitys, die während eines \fBexecve\fP(2) erlangt werden, dienen kann. .IP Seit Linux 2.6.25 ist dies eine pro\-Thread\-Capability\-Menge. In älteren Kerneln war die Capability\-Begrenzungsmenge ein systemweites Attribut, das von allen Threads des Systems gemeinsam benutzt wurde. .IP Für weitere Details über die Capability\-Begrenzungsmenge, siehe unten. .TP \fIAmbient\fP (Umgebung) (seit Linux 4.3) .\" commit 58319057b7847667f0c9585b9de0e8932b0fdb08 Dies ist eine Menge von Capabilitys, die über \fBexecve\fP(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. .IP Die Umgebungs\-Capability\-Menge kann direkt mit \fBprctl\fP(2) verändert werden. Umgebungs\-Capabilitys werden automatisch abgesenkt, falls entweder die entsprechende erlaubte oder vererbbare Capability abgesenkt wird. .IP 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\-Capabilitys verfügt, dann wird die Umgebungsmenge geleert. Umgebungs\-Capabilitys werden zu der erlaubten Menge hinzugefügt und der effektiven Menge zugewiesen, wenn \fBexecve\fP(2) aufgerufen wird. Falls Umgebungs\-Capabilitys dazu führen, dass die erlaubten und effektiven Capabilitys während eines \fBexecve\fP(2) anwachsen, löst dies keinen sicheren Ausführmodus, wie in \fBld.so\fP(8) beschrieben, aus. .PP Ein mittels \fBfork\fP(2) erstelltes Kind erbt Kopien der Eltern\-Capability\-Menge. Lesen Sie weiter unten eine Diskussion der Behandlung von Capabilitys während \fBexecve\fP(2). .PP Mittels \fBcapset\fP(2) kann ein Thread seine eigenen Capability\-Mengen bearbeiten (siehe unten). .PP .\" commit 73efc0394e148d0e15583e13712637831f926720 .\" Seit Linux 3.2 legt die Datei \fI/proc/sys/kernel/cap_last_cap\fP 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. .SS Datei\-Capabilitys Seit Kernel 2.6.24 unterstützt der Kernel die Zuordnung von Capability\-Mengen zu einer ausführbaren Datei mittels \fBsetcap\fP(8). Die Datei\-Capability\-Mengen werden in erweiterten Attributen namens \fIsecurity.capability\fP gespeichert (siehe \fBsetxattr\fP(2) und \fBxattr\fP(7)). Das Schreiben in diese erweiterten Attribute benötigt die Capability \fBCAP_SETFCAP\fP. Die Datei\-Capability\-Mengen bestimmen zusammen mit den Capability\-Mengen des Threads die Capabilitys nach einem \fBexecve\fP(2). .PP Die drei Datei\-Capability\-Mengen sind: .TP \fIPermitted\fP (erlaubt, früher als \fIforced\fP (erzwungen) bekannt): Diese Capabilitys werden dem Thread automatisch erlaubt, unabhängig von den geerbten Capabilitys des Threads. .TP \fIInheritable\fP (vererbbar, früher als \fIallowed\fP (erlaubt) bekannt): Diese 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 \fBexecve\fP(2) aktiviert werden. .TP \fIEffective\fP (effektiv): Dies ist keine Menge, sondern eher ein einziges Bit. Falls dieses Bit gesetzt ist, dann werden während eines \fBexecve\fP(2) die gesamten erlaubten Capabilties für den Thread in die effektive Menge hochgezogen. Falls dieses Bit nicht gesetzt ist, dann wird nach einem \fBexecve\fP(2) keine der erlaubten Capabilitys in der neuen effektiven Menge sein. .IP .\" 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 \fBexecve\fP(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 ((\fBsetcap\fP(8), \fBcap_set_file\fP(3), \fBcap_set_fd\fP(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. .SS "Erweiterte Attributversionierung von Datei\-Capabilitys" Um Erweiterbarkeit zu erlauben, unterstützt der Kernel ein Schema, um eine Versionsnummer innerhalb des erweiterten Attributs \fIsecurity.capability\fP 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: .TP \fBVFS_CAP_REVISION_1\fP Dies war die ursprüngliche Datei\-Capability\-Implementierung, die 32\-Bit\-Masken für Datei\-Capabilitys unterstützte. .TP \fBVFS_CAP_REVISION_2\fP (seit Linux 2.6.25) .\" commit e338d263a76af78fe8f38a72131188b58fceb591 Diese 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. .TP \fBVFS_CAP_REVISION_3\fP (seit Linux 4.14) .\" commit 8db6c34f1dbc8e06aa016a9b829b06902c3e1340 Version\-3\-Datei\-Capabilitys werden zur Unterstützung von (nachfolgend beschriebenen) namensraumbezogenen Datei\-Capabilitys bereitgestellt. .IP Wie 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 \fIsecurity.capability\fP kodiert. (Eine Namensraum\-Wurzelbenutzerkennung ist der Wert, auf den die Benutzerkennung 0 innerhalb dieses Namensraums in dem ursprünglichen Namensraum abgebildet wird.) .IP Version\-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. .PP Vor Linux 4.14 war die einzige Art des erweiterten Attributs für Datei\-Capabilitys, die an eine Datei angehängt werden konnten, ein \fBVFS_CAP_REVISION_2\fP\-Attribut. Seit Linux 4.14 hängt die Version des erweiterten Attributs \fIsecurity.capability\fP, die an eine Datei angehängt werden kann, von den Umständen ab, unter denen das Attribut erstellt wurde. .PP Seit Linux 4.14 wird ein erweitertes Attribut \fIsecurity.capability\fP automatisch als ein Version\-3\-(\fBVFS_CAP_REVISION_3\fP)\-Attribut erstellt (oder in ein solches umgewandelt), falls beide folgenden Punkte zutreffen: .IP (1) 4 Der Thread, der das Attribut schreibt, befindet sich in einem nichtinitialen Benutzernamensraum. (Genauer: Der Thread befindet sich in einem Benutzernamensraum, der sich von dem unterscheidet, unter dem das darunterliegende Dateisystem eingehängt wurde.) .IP (2) Der Thread hat die Capability \fBCAP_SETFCAP\fP über der Datei\-Inode, was bedeutet, dass (a) der Thread die Capability \fBCAP_SETFCAP\fP in seinem eigenen Benutzernamensraum hat und (b) die UID und GID der Datei\-Inode Abbildungen in den Namensraum des schreibenden Benutzers haben. .PP Wenn ein erweitertes Attribut \fBVFS_CAP_REVISION_3\fP \fIsecurity.capability\fP erstellt wird, wird die Wurzelbenutzerkennung des erstellenden Namensraums des Benutzers in dem erweiterten Attribut gespeichert. .PP Im Gegensatz dazu wird beim Erstellen oder Verändern eines erweiterten Attributs \fIsecurity.capability\fP aus einem privilegierten (\fBCAP_SETFCAP\fP) 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\-(\fBVFS_CAP_REVISION_2\fP)\-Attributs führen. .PP Beachten Sie, dass die Erstellung von erweiterten Version 3\-\fIsecurity.capability\fP\-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 \fIsecurity.capability\fP\-Attribut im Version\-2\-Format schreibt (\fBsetxattr\fP(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\-\fIsecurity.capability\fP\-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. \fBsetcap\fP(1) und \fBgetcap\fP(1)) keine Änderung vorgenommen werden muss, damit diese Werkzeuge zum Erstellen und Abfragen von Version\-3\-\fIsecurity.capability\fP\-Attributen verwandt werden können. .PP .\" Beachten Sie, dass der Datei entweder ein erweitertes Attribut \fIsecurity.capability\fP der Version 2 oder 3 zugeordnet werden kann, aber nicht beide: Erstellung oder Änderung des erweiterten Attributs \fIsecurity.capability\fP wird automatisch die Version abhängig von den Umständen, in denen das erweiterte Attribut erstellt oder verändert wird, anpassen. .SS "Umwandlungen von Capabilitys während execve()" Während eines \fBexecve\fP(2) berechnet der Kernel die neuen Capabilitys eines Prozesses mit dem folgenden Algorithmus: .PP .in +4n .EX P'(ambient) = (Datei ist privilegiert) ? 0 : P(ambient) P'(permitted) = (P(inheritable) & F(inheritable)) | (F(permitted) & P(bounding)) | P'(ambient) P'(effective) = F(effective) ? P'(permitted) : P'(ambient) P'(inheritable) = P(inheritable) [d.h. unverändert] P'(bounding) = P(bounding) [d.h. unverändert] .EE .in .PP wobei: .RS 4 .IP P() 6 bezeichnet den Wert einer Capability\-Menge des Threads vor dem \fBexecve\fP(2) .IP P'() bezeichnet den Wert einer Capability\-Menge des Threads nach dem \fBexecve\fP(2) .IP F() bezeichnet eine Datei\-Capability\-Menge .RE .PP Beachten Sie die nachfolgenden Details in Hinblick auf die obigen Capability\-Umwandlungsregeln: .IP * 3 Die Umgebungs\-Capability\-Menge ist erst seit Linux 4.3 vorhanden. Bei der Bestimmung der Übergänge der Umgebungsmenge während eines \fBexecve\fP(2) bezeichnet eine privilegierte Datei eine, die über Capabilitys verfügt oder das Bit »set\-user\-ID« oder »set\-group\-ID« gesetzt hat. .IP * Vor Linux 2.6.25 war die Begrenzungsmenge ein systemweites Attribut, das von allen Threads gemeinsam benutzt wurde. Dieser systemweite Wert wurde eingesetzt, um die neue erlaubte Menge während eines \fBexecve\fP(2) zu berechnen, auf die gleiche Art wie oben für \fIP(bounding)\fP gezeigt. .PP \fIHinweis:\fP 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 \fBexecve\fP(2). Ähnlich werden Datei\-Capabilitys ignoriert, falls der Kernel mit der Option \fIno_file_caps\fP gestartet wurde. .PP .\" \fIHinweis:\fP 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 \fBexecve\fP(2) durchführt. Für die Behandlung der Capabilitys, wenn ein Prozess mit der Benutzerkennung Null ein \fBexecve\fP(2) durchführt, siehe unten unter \fICapabilitys und Ausführung von Programmen durch root\fP. .SS "Sicherheitsprüfungen für Capability\-unfähige Programme" Ein Capability\-unfähiges Programm ist eine Anwendung, die für Datei\-Capabilitys markiert ist, aber noch nicht für die Verwendung des \fBlibcap\fP(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. .PP .\" Beim 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 \fInicht\fP 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 \fBexecve\fP(2) mit dem Fehler \fBEPERM\fP 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 \fBlibcap\fP(3)\-API einsetzt. .SS "Capabilitys und Ausführung von Programmen durch root" .\" See cap_bprm_set_creds(), bprm_caps_from_vfs_cap() and .\" handle_privileged_root() in security/commoncap.c (Linux 5.0 source) Um 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. .PP Nachdem alle Änderungen an der effektiven Kennung des Prozesses vorgenommen wurden, die durch das Modus\-Bit set\-user\-ID des Programmes ausgelöst wurden, z.B. Umschalten der effektiven Benutzerkennung auf 0 (root), da ein set\-user\-ID\-root\-Programm ausgeführt wurde, berechnet der Kernel die Datei\-Capability\-Menge wie folgt: .IP 1. 3 Falls die reale oder effektive Benutzerkennung des Prozesses 0 (root) ist, dann werden die vererbbaren und erlaubten Mengen ignoriert; stattdessen werden sie fiktiv als komplett Eins (d.h. alle Capabilitys aktiviert) betrachtet. (Es gibt für dieses Verhalten eine Ausnahme, die unten in \fISet\-user\-ID\-root\-Programme, die Datei\-Capabilitys haben\fP beschrieben ist.) .IP 2. Falls die effektive Benutzerkennung des Prozesses 0 (root) ist oder das effektive Bit der Datei tatsächlich aktiviert ist, dann wird das effektive Datei\-Bit fiktiv als Eins (aktiviert) definiert. .PP Diese 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 \fBexecve\fP(2) zu berechnen. .PP Daher 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 \fBexecve\fP(2) ausführt, oder wenn ein Prozess, dessen reale und effektive UIDs Null sind, ein Programm mit \fBexecve\fP(2) ausführt: .PP .in +4n .EX P'(permitted) = P(inheritable) | P(bounding) P'(effective) = P'(permitted) .EE .in .PP Konsequenterweise 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.) .PP .\" .\" Die in diesem Unterabschnitt beschriebene besondere Behandlung des Benutzers 0 (root) kann mittels des nachfolgend beschriebenen Securebits\-Mechanismus deaktiviert werden. .SS "Set\-user\-ID\-root\-Programme, die Datei\-Capabilitys haben" Es gibt zu dem unter \fICapabilitys und Ausführung von Programmen durch root\fP beschriebenen Verhalten eine Ausnahme. Falls (a) das ausgeführte Programm über Capabilitys verfügt und (b) die reale Benutzerkennung des Prozesses \fInicht\fP 0 (root) ist und (c) die effektive Benutzerkennung des Prozesses 0 (root) \fIist\fP, 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). .PP .\" Beachten Sie, dass einem Programm eine leere Capability\-Menge zugeordnet werden kann und es daher möglich ist, ein set\-user\-ID\-root\-Programm zu erstellen, das die effektive und die gespeicherte set\-user\-ID des Prozesses, der das Programm ausführt, auf 0 setzt, aber dem Prozess keine Capabilitys gewährt. .SS Capability\-Begrenzungsmenge Die Capability\-Begrenzungsmenge ist ein Sicherheitsmechanismus, der zur Begrenzung der Capabilitys, die während eines \fBexecve\fP(2) erlangt werden können, dienen kann. Die Begrenzungsmenge wird auf die folgende Art und Weise benutzt: .IP * 2 Während eines \fBexecve\fP(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. .IP * (Seit Linux 2.6.25) Die Capability\-Begrenzungsmenge agiert als begrenzende Übermenge für die Capabilitys, die ein Thread zu seiner vererbbaren Menge mittels \fBcapset\fP(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 \fBexecve\fP(2) ausführt, die diese Capability in seiner vererbbaren Menge hat. .PP Beachten 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. .PP Abhängig von der Kernelversion ist die Capability\-Begrenzungsmenge entweder ein systemweites Attribut oder ein prozessweises Attribut. .PP \fBCapability\-Begrenzungsmenge seit Linux 2.6.25\fP .PP Seit Linux 2.6.25 ist die \fICapability\-Begrenzungsmenge\fP ein pro\-Thread\-Attribut. (Die nachfolgend beschriebene systemweite Capability\-Begrenzungsmenge existiert nicht mehr.) .PP Die Begrenzungsmenge wird bei \fBfork\fP(2) von dem Elternprozess des Threads vererbt und bleibt über ein \fBexecve\fP(2) erhalten. .PP Ein Thread kann mittels der Aktion \fBprctl\fP(2) \fBPR_CAPBSET_DROP\fP Capabilitys aus seiner Begrenzungsmenge entfernen, vorausgesetzt, er verfügt über die Capability \fBCAP_SETPCAP\fP. 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 \fBprctl\fP(2) \fBPR_CAPBSET_READ\fP herausfinden, ob eine Capability in seiner Begrenzungsmenge liegt. .PP .\" commit b3a222e52e4d4be77cc4520a57af1a4a0d8222d1 Entfernen 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 \fBCONFIG_SECURITY_FILE_CAPABILITIES\fP 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 \fBinit\fP\-Prozess (der Urahn aller Prozesse) mit einer kompletten Begrenzungsmenge. Falls Datei\-Capabilitys nicht in den Kernel kompiliert sind, dann beginnt \fBinit\fP mit einer vollständigen Begrenzungsmenge ohne \fBCAP_SETPCAP\fP, da diese Capability eine andere Bedeutung hat, wenn es keine Datei\-Capabilitys gibt. .PP 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. .PP \fBCapability\-Begrenzungsmenge vor Linux 2.6.25\fP .PP 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 \fI/proc/sys/kernel/cap\-bound\fP zugegriffen werden. (Zur Erhöhung der Konfusion wird dieser Bitmaskenparameter als vorzeichenbehaftete Dezimalzahl in \fI/proc/sys/kernel/cap\-bound\fP ausgedrückt.) .PP Nur der \fBinit\fP\-Prozess darf Capabilitys in der Capability\-Begrenzungsmenge setzen; abgesehen davon kann der Superuser (oder genauer: ein Prozess mit der Capability \fBCAP_SYS_MODULE\fP) nur Capabilitys aus dieser Menge entfernen. .PP Auf einem Standardsystem maskiert die Capability\-Begrenzungsmenge immer die Capability \fBCAP_SETPCAP\fP. Um diese Einschränkung zu entfernen (gefährlich!), verändern Sie die Definition von \fBCAP_INIT_EFF_SET\fP in \fIinclude/linux/capability.h\fP und bauen Ihren Kernel neu. .PP .\" .\" .\" Die systemweite Capability\-Begrenzungsmengenfunktion wurde Linux in Version 2.2.11 hinzugefügt. .SS "Effekt von Benutzerkennungsänderungen auf Capabilitys" Um die traditionellen Semantiken für Übergänge zwischen 0 und von 0 verschiedenen Kennungen zu erhalten, führt der Kernel folgende Änderungen an den Capability\-Mengen eines Threads bei Änderung der realen, effektiven, gespeicherten und Dateisystem\-Benutzerkennung (unter Verwendung von \fBsetuid\fP(2), \fBsetresuid\fP(2) oder ähnlich) durch: .IP 1. 3 Falls einer der realen, effektiven oder gespeicherten Set\-User\-IDs vorher 0 war und als Ergebnis der UID\-Änderung alle dieser Kennungen eine von 0 verschiedenen Wert haben, dann werden alle Capabilitys aus den erlaubten, effektiven und Umgebungs\-Capability\-Mengen gelöscht. .IP 2. Falls die effektive Benutzerkennung von 0 auf einen von 0 verschiedenen Wert geändert wird, werden alle Capabilitys aus der effektiven Menge gelöscht. .IP 3. Falls die effektive Benutzerkennung von einem von 0 verschiedenen Wert auf 0 geändert wird, dann wird die erlaubte Menge in die effektive Menge kopiert. .IP 4. Falls die Dateisystem\-Benutzerkennung von 0 auf einen anderen Wert geändert wird (siehe \fBsetfsuid\fP(2)), dann werden die folgenden Capabilitys aus der effektiven Menge entfernt: \fBCAP_CHOWN\fP, \fBCAP_DAC_OVERRIDE\fP, \fBCAP_DAC_READ_SEARCH\fP, \fBCAP_FOWNER\fP, \fBCAP_FSETID\fP, \fBCAP_LINUX_IMMUTABLE\fP (seit Linux 2.6.30), \fBCAP_MAC_OVERRIDE\fP und \fBCAP_MKNOD\fP (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. .PP .\" Falls ein Thread, der einen Wert 0 für mindestens eine seiner Benutzerkennungen hat, verhindern möchte, dass seine erlaubte Capability\-Menge bereinigt wird, wenn er alle seine Benutzerkennungen auf einen von 0 verschiedenen Wert setzt, kann er dies mittels der unten beschriebenen \fBSECBIT_KEEP_CAPS\fP\-Securebits\-Schaltern erreichen. .SS "Programmatische Anpassung von Capability\-Mengen" Ein Thread kann seine erlaubten, effektiven und vererbbaren Capability\-Mengen mittels der Systemaufrufe \fBcapget\fP(2) und \fBcapset\fP(2) ermitteln und ändern. Allerdings werden für diesen Zweck die Verwendung von \fBcap_get_proc\fP(3) und \fBcap_set_proc\fP(3), beide im Paket \fIlibcap\fP bereitgestellt, empfohlen. Die folgenden Regeln bestimmen die Änderungen an den Capability\-Mengen des Threads: .IP 1. 3 Falls der Aufrufende nicht über die Capability \fBCAP_SETPCAP\fP verfügt, dann muss die neue vererbbare Menge eine Teilmenge der Kombination der bestehenden vererbbaren und erlaubten Menge sein. .IP 2. (Seit Linux 2.6.25) Die neue vererbbare Menge muss eine Teilmenge der Kombination der bestehenden vererbbaren Menge und der Capability\-Begrenzungsmenge sein. .IP 3. Die 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). .IP 4. Die neue effektive Menge muss eine Teilmenge der neuen erlaubten Menge sein. .SS "Der Schalter securebits: eine reine Capability\-Umgebung einrichten" .\" For some background: .\" see http://lwn.net/Articles/280279/ and .\" http://article.gmane.org/gmane.linux.kernel.lsm/5476/ Beginnend mit Kernel 2.6.26 und mit einem Kernel, in dem Datei\-Capabilitys aktiviert sind, implementiert Linux eine Menge von pro\-Thread\-\fIsecurebits\fP\-Schaltern, die zur Deaktivierung von spezieller Handhabung von Capabilitys für UID 0 (\fIroot\fP) verwandt werden können. Dies sind die folgenden Schalter: .TP \fBSECBIT_KEEP_CAPS\fP Durch 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 \fBexecve\fP(2) immer bereinigt. .IP Bachten Sie, dass selbst mit gesetztem Schalter \fBSECBIT_KEEP_CAPS\fP 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. .IP Die Einstellung des Schalters \fBSECBIT_KEEP_CAPS\fP wird ignoriert, falls der Schalter \fBSECBIT_NO_SETUID_FIXUP\fP gesetzt ist. (Letzterer Schalter stellt eine Übermenge des Effekts des ersteren Schalters bereit.) .IP Dieser Schalter stellt die gleiche Funktionalität wie die ältere Aktion \fBprctl\fP(2) \fBPR_SET_KEEPCAPS\fP bereit. .TP \fBSECBIT_NO_SETUID_FIXUP\fP 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 \fIEffekt von Benutzerkennungsänderungen auf Capabilitys\fP) .TP \fBSECBIT_NOROOT\fP Falls 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 \fBexecve\fP(2) aufruft. (Lesen Sie den Abschnitt \fICapabilitys und Ausführung von Programmen durch root\fP) .TP \fBSECBIT_NO_CAP_AMBIENT_RAISE\fP Durch Setzen dieses Schalters dürfen keine Umgebungs\-Capabilitys mit der \fBprctl\fP(2)\-Aktion \fBPR_CAP_AMBIENT_RAISE\fP gehoben werden. .PP 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: \fBSECBIT_KEEP_CAPS_LOCKED\fP, \fBSECBIT_NO_SETUID_FIXUP_LOCKED\fP, \fBSECBIT_NOROOT_LOCKED\fP und \fBSECBIT_NO_CAP_AMBIENT_RAISE_LOCKED\fP. .PP Die Schalter \fIsecurebits\fP können mit den Aktionen \fBprctl\fP(2) \fBPR_SET_SECUREBITS\fP und \fBPR_GET_SECUREBITS\fP geändert und abgefragt werden. Die Capability \fBCAP_SETPCAP\fP wird für die Veränderung der Schalter benötigt. Beachten Sie, dass die Konstanten \fBSECBIT_*\fP nur nachdem Sie die Header\-Datei \fI\fP eingebunden haben verfügbar sind. .PP Die Schalter \fIsecurebits\fP werden von Kindprozessen vererbt. Während eines \fBexecve\fP(2) werden alle Schalter beibehalten, außer \fBSECBIT_KEEP_CAPS\fP, das immer bereinigt wird. .PP 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, Capabilitys zu erlangen, darin besteht, ein Programm auzuführen, das über die zugeordneten Datei\-Capabilitys verfügt: .PP .in +4n .EX 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 */ .EE .in .\" .\" .SS "Namensraumbezogene »set\-user\-ID\-root«\-Programme" Ein 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. .PP .\" .\" Die obigen Regeln über die Umwandlung der Capabilitys des Prozesses während eines \fBexecve\fP(2) werden genau in den Unterabschnitten \fIUmwandlungen von Capabilitys während execve()\fP und \fICapabilitys und Ausführung von Programmen durch root\fP beschrieben, wobei im letzeren Unterabschnitt als Unterschied »root« die UID des Erstellers des Benutzernamensraums ist. .SS "Namensraumbezogene Datei\-Capabilitys" .\" commit 8db6c34f1dbc8e06aa016a9b829b06902c3e1340 Traditionelle (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. .PP Da 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 \fBCAP_SETFCAP\fP 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. .PP Linux 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. \fBVFS_CAP_REVISION_3\fP) erweiterte Attribute \fIsecurity.capability\fP 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 \fIsecurity.capability\fP erstellt wird, zeichnet der Kernel nicht nur die Capability\-Maske in dem erweiterten Attribut auf, sondern auch die Benutzerkennung von root in dem Namensraum. .PP .\" .\" Wie mit Programmen, die eine Datei\-Capability \fBVFS_CAP_REVISION_2\fP haben, verleiht ein Programm mit Datei\-Capability \fBVFS_CAP_REVISION_3\fP während eines \fBexecve\fP() 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. .SS "Interaktion mit Benutzernamensräumen" Für weitere Informationen über die Interaktion von Capabilitys und Benutzer\-Namensräumen lesen Sie \fBuser_namespaces\fP(7). .SH "KONFORM ZU" Keine Standards regeln Capabilitys; die Linux\-Capability\-Implementierung basiert aber auf dem zurückgezogenen POSIX.1e\-Entwurfsstandard; siehe .UR https://archive.org\:/details\:/posix_1003.1e\-990310 .UE . .SH ANMERKUNGEN Beim Versuch, \fBstrace\fP(1) auf Programme anzuwenden, die über Capabilitys verfügen (oder set\-user\-ID\-root\-Programme), könnten Sie die Option \fI\-u \fP nützlich finden. Etwas von der Art: .PP .in +4n .EX $ \fBsudo strace \-o trace.log \-u ceci ./meinprivprog\fP .EE .in .PP .\" commit 5915eb53861c5776cfec33ca4fcc1fd20d66dd27 removed .\" CONFIG_SECURITY_CAPABILITIES Von Kernel 2.5.27 bis Kernel 2.6.26 waren Capabilitys eine optionale Kernelkomponente, die über die Kernelkonfigurationsoption \fBCONFIG_SECURITY_CAPABILITIES\fP aktiviert/deaktiviert werden könnte. .PP .\" 7b9a7ec565505699f503b4fcf61500dceb36e744 Die Datei \fI/proc/[PID]/task/TID/status\fP kann zum Betrachten der Capability\-Mengen eines Threads verwandt werden. Die Datei \fI/proc/[PID]/status\fP 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 \fBCAP_LAST_CAP\fP) als deaktiviert (0) angezeigt. .PP Das Paket \fIlibcap\fP stellt eine Suite von Routinen zum Setzen und Abfragen von Capabilitys bereit, die komfortablere und änderungsstabilere Schnittstellen als die von \fBcapset\fP(2) und \fBcapget\fP(2) bereitstellen. Dieses Paket stellt auch die Programme \fBsetcap\fP(8) und \fBgetcap\fP(8) zur Verfügung. Es kann unter folgender Adresse gefunden werden: .br .UR https://git.kernel.org\:/pub\:/scm\:/libs\:/libcap\:/libcap.git\:/refs/ .UE . .PP Vor 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 \fBCAP_SETPCAP\fP die Capabilitys von anderen Threads manipulieren. Allerdings ist dies nur theoretisch möglich, da kein Thread jemals über \fBCAP_SETPCAP\fP in einem der folgenden Fälle verfügt: .IP * 2 In der pre\-2.6.25\-Implementierung maskiert die systemweite Capability\-Begrenzungsmenge \fI/proc/sys/kernel/cap\-bound\fP die Capability \fBCAP_SETPCAP\fP immer und dies kann ohne Veränderung der Kernelquellen und dem Neubau des Kernels nicht geändert werden. .IP * Falls Datei\-Capabilitys deaktiviert sind (d.h. die Kerneloption \fBCONFIG_SECURITY_FILE_CAPABILITIES\fP deaktiviert ist), dann startet \fBinit\fP derart, dass die Capability \fBCAP_SETPCAP\fP aus seiner prozessweisen Begrenzungsmenge entfernt ist und dass die Begrenzungsmenge von allen anderen im System erstellten Prozessen vererbt wird. .SH "SIEHE AUCH" .\" from libcap-ng .\" from libcap-ng .\" from libcap-ng .\" from libcap-ng \fBcapsh\fP(1), \fBsetpriv\fP(1), \fBprctl\fP(2), \fBsetfsuid\fP(2), \fBcap_clear\fP(3), \fBcap_copy_ext\fP(3), \fBcap_from_text\fP(3), \fBcap_get_file\fP(3), \fBcap_get_proc\fP(3), \fBcap_init\fP(3), \fBcapgetp\fP(3), \fBcapsetp\fP(3), \fBlibcap\fP(3), \fBproc\fP(5), \fBcredentials\fP(7), \fBpthreads\fP(7), \fBuser_namespaces\fP(7), \fBcaptest\fP(8), \fBfilecap\fP(8), \fBgetcap\fP(8), \fBgetpcaps\fP(8), \fBnetcap\fP(8), \fBpscap\fP(8), \fBsetcap\fP(8) .PP \fIinclude/linux/capability.h\fP in dem Linux\-Kernelquellbaum .SH KOLOPHON Diese Seite ist Teil der Veröffentlichung 5.10 des Projekts Linux\-\fIman\-pages\fP. 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/. .SH ÜBERSETZUNG Die deutsche Übersetzung dieser Handbuchseite wurde von Dr. Tobias Quathamer und Helge Kreutzmann erstellt. Diese Übersetzung ist Freie Dokumentation; lesen Sie die .UR https://www.gnu.org/licenses/gpl-3.0.html GNU General Public License Version 3 .UE 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 die .MT debian-l10n-german@\:lists.\:debian.\:org Mailingliste der Übersetzer .ME .