Capabilitys(7) Miscellaneous Information Manual Capabilitys(7) BEZEICHNUNG capabilities - Uberblick uber Linux-Capabilitys BESCHREIBUNG Fur den Zweck der Durchfuhrung von Rechteprufungen 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 ubergehen alle Kernel-Rechteprufungen, wahrend unprivilegierte Prozesse der vollen Rechteprufung, basierend auf den Berechtigungsnachweisen des Prozesses (normalerweise: effektive UID, effektive GID und erganzende Gruppenliste), unterliegen. Beginnend mit Linux 2.2 unterteilt Linux die Privilegien, die traditionell mit dem Superuser assoziiert sind, in getrennte Einheiten, die als Capabilitys bekannt sind. Diese konnen unabhangig voneinander aktiviert oder deaktiviert werden. Capabilitys sind ein Attribut pro Thread. Liste der Capabilitys Die folgende Liste zeigt die in Linux implementierten Capabilitys und die Aktionen oder Verhalten, die jede Capability erlaubt: CAP_AUDIT_CONTROL (seit Linux 2.6.11) Kernel-Auditierung aktivieren und deaktivieren; die Auditierung-Filterregel andern; den Auditstatus und Filterregel abfragen. CAP_AUDIT_READ (seit Linux 3.16) Erlaubt das Schreiben des Audit-Protokolls uber einen Multicast-Netlink-Socket. CAP_AUDIT_WRITE (seit Linux 2.6.11) Datensatze in das Audit-Protokoll des Kernels schreiben. CAP_BLOCK_SUSPEND (seit Linux 3.5) Funktionalitaten einsetzen, die die System-Supsendierung blockieren konnen (epoll(7) EPOLLWAKEUP, /proc/sys/wake_lock). CAP_BPF (seit Linux 5.8) privilegierte BPF-Aktionen einsetzen; siehe bpf(2) und bpf-helpers(7). Diese Capability wurde in Linux 5.8 hinzugefugt, um die BPF-Funktionalitat aus der uberladenen Capability CAP_SYS_ADMIN auszugliedern. CAP_CHECKPOINT_RESTORE (seit Linux 5.9) o Aktualisiert /proc/sys/kernel/ns_last_pid (siehe pid_namespaces(7)); o verwendet die Funktionalitat set_tid von clone3(2); o liest die Inhalte der symbolischen Links in /proc/PID/map_files fur andere Prozesse. Diese Capability wurde in Linux 5.9 hinzugefugt, um die Prufpunkt-/Wiederherstellungs-Funktionalitat aus der uberladenen Capability CAP_SYS_ADMIN auszugliedern. CAP_CHOWN beliebige Anderungen an Datei-UIDs und GIDs vornehmen (siehe chown(2)). CAP_DAC_OVERRIDE Lese-, Schreibe und Ausfuhrrechteprufungen umgehen. (DAC ist die Abkurzung fur >>discretionary access control<<, benutzerbestimmbare Zugriffssteuerung) CAP_DAC_READ_SEARCH o Dateileserechteprufungen und Verzeichnislese- und -ausfuhrrechteprufungen umgehen. o open_by_handle_at(2) aufrufen. o Verwenden Sie den Schalter AT_EMPTY_PATH von linkat(2), um einen Link auf eine Datei, auf die sich ein Dateideskriptor bezieht, zu erstellen. CAP_FOWNER o Rechteprufungen umgehen, die normalerweise verlangen, dass die Dateisystem-UID des Prozesses mit der UID der Datei ubvereinstimmt (z.B. chmod(2), utime(2)), hierbei sind Aktionen, die durch CAP_DAC_OVERRIDE und CAP_DAC_READ_SEARCH abgedeckt sind, ausgeschlossen; o Inode-Schalter fur beliebige Dateien setzen (siehe ioctl_iflags(2)); o Zugriffssteuerlisten (>>Access Control Lists<<, ACLs) auf beliebige Dateien setzen; o >>sticky<<-Bit von Verzeichnissen beim Dateiloschen ignorieren; o verandert Benutzer-erweiterte Attribute bei >>sticky<<-Verzeichnissen, die irgendeinem Benutzer gehoren; o O_NOATIME fur beliebige Dateien in open(2) und fcntl(2) setzen. CAP_FSETID o Set-User-ID- und Set-Group-ID-Modus-Bits nicht zurucksetzen, wenn eine Datei verandert wird; o das Set-Group-ID-Bit fur eine Datei setzen, deren GID nicht auf das Dateisystem- oder eine der erganzenden GIDs des aufrufenden Prozesses passt. CAP_IPC_LOCK o Speicher sperren (mlock(2), mlockall(2), mmap(2), shmctl(2)), o Speicher mittels grossen Speicherseiten reservieren (memfd_create(2), mmap(2), shmctl(2)). CAP_IPC_OWNER Rechteprufungen fur Aktionen mit System-V-IPC-Objekten umgehen. CAP_KILL Rechteprufungen beim Senden von Signalen umgehen (siehe kill(2)). Dies schliesst die ioctl(2)-KDSIGACCEPT-Aktion mit ein. CAP_LEASE (seit Linux 2.4) Etabliert Ausleihen fur beliebige Dateien (siehe fcntl(2)). CAP_LINUX_IMMUTABLE Setzt die Inode-Schalter FS_APPEND_FL und FS_IMMUTABLE_FL (siehe ioctl_iflags(2)). CAP_MAC_ADMIN (seit Linux 2.6.25) MAC-Konfiguration oder Statusanderungen erlauben. Implementiert fur das Smack-Linux-Security-Modul (LSM). CAP_MAC_OVERRIDE (seit Linux 2.6.25) Mandatory Access Control (MAC) ausser Kraft setzen. Fur das Smack-LSM implementiert. CAP_MKNOD (seit Linux 2.4) Spezielle Dateien mittels mknod(2) erstellen. CAP_NET_ADMIN Verschiedene Netz-bezogene Aktionen durchfuhren: o Schnittstellenkonfiguration; o Administration von IP-Firewall, Masquerading und Abrechnung; o Routing-Tabellen verandern; o an beliebige Adresse fur eine transparente Proxyfunktion binden; o type-of-service (TOS) setzen; o Treiberstatistiken bereinigen; o den >>promiscuous<<-Modus einschalten; o Multicasting aktivieren; o setsockopt(2) verwenden, um die folgenden Socket-Optionen zu setzen: SO_DEBUG, SO_MARK, SO_PRIORITY (fur eine Prioritat ausserhalb des Bereichs 0 bis 6), SO_RCVBUFFORCE und SO_SNDBUFFORCE. CAP_NET_BIND_SERVICE Einen Socket an einen privilegierten Internet-Domain-Port binden (Portnummern kleiner als 1024). CAP_NET_BROADCAST (Unbenutzt) Socket-Broadcasts durchfuhren und auf Multicasts warten. CAP_NET_RAW o RAW- und PACKET-Sockets verwenden; o an beliebige Adresse fur eine transparente Proxyfunktion binden. CAP_PERFMON (seit Linux 5.8) verschiedene Leistungsuberwachungsmechanismen einzusetzen, einschliesslich: o perf_event_open(2) aufrufen; o verschiedene BPF-Aktionen einzusetzen, die Leistungsauswirkungen haben. Diese Capability wurde in Linux 5.8 hinzugefugt, um die Uberwachungsfunktionalitat aus der uberladenen Capability CAP_SYS_ADMIN auszugliedern. Siehe auch die Kernelquelldatei Documentation/admin-guide/perf-security.rst. CAP_SETGID o Beliebige Manipulationen an den GIDs und der Liste der erganzenden GIDs des Prozesses vornehmen; o GID falschen, wenn Socket-Berechtigungsnachweise via UNIX-Domain-Sockets weitergebeben werden; o eine Gruppenkennungs-Abbildung in einen Benutzernamensraum schreiben (siehe user_namespaces(7)). CAP_SETFCAP (seit Linux 2.6.24) Setzt beliebige Capabilitys auf einer Datei. Seit Linux 5.12 muss diese Capability auch auf eine Benutzerkennung 0 in einem neuen Benutzernamensraum abgebildet sein; siehe user_namespaces(7) fur Details. CAP_SETPCAP Falls Datei-Capabilitys unterstutzt werden (d.h. seit Linux 2.6.24): Fuge alle Capabilitys aus der Begrenzungsmenge des Threads zu der vererbbaren Menge hinzu; entferne Capabilitys aus der Begrenzungsmenge (via prctl(2) PR_CAPBSET_DROP); nehme Anderungen an den securebits-Schaltern vor. Falls Datei-Capabilites nicht unterstutzt werden (d.h. vor Linux 2.6.24): eine Capability in der erlaubten Capability-Menge oder von anderen Prozessen entfernen oder dafur bewilligen. (Diese Eigenschaft von CAP_SETPCAP ist nicht verfugbar, falls der Kernel fur die Unterstutzung von Datei-Capabilitys konfiguriert ist, da CAP_SETPCAP fur diese Kernel eine komplett andere Semantik aufweist.) CAP_SETUID o beliebige Manipulationen der Prozess-UIDs vornehmen (setuid(2), setreuid(2), setresuid(2), setfsuid(2)); o UID falschen, wenn Socket-Berechtigungsnachweise via UNIX-Domain-Sockets weitergebeben werden; o eine Benutzerkennung-Abbildung in einen Benutzernamensraum schreiben (siehe user_namespaces(7)). CAP_SYS_ADMIN Hinweis: Diese Capability ist uberladen, siehe Hinweise fur Kernel-Entwickler weiter unten. o eine Reihe von Systemadministratoraktionen ausfuhren, darunter: quotactl(2), mount(2), umount(2), pivot_root(2), swapon(2), swapoff(2), sethostname(2) und setdomainname(2); o privilegierte syslog(2)-Aktion ausfuhren (seit Linux 2.6.37 sollte CAP_SYSLOG verwandt werden, um diese Aktion zu erlauben); o den VM86_REQUEST_IRQ-Befehl vm86(2) ausfuhren; o auf die gleiche Prufpunkt-/Wiederherstellungsfunktionalitat zugreifen, die durch CAP_CHECKPOINT_RESTORE gelenkt wird (die letztere, aber schwachere Capability wird fur den Zugriff auf dieses Funktionalitat bevorzugt). o die gleichen BPF-Aktionen durchfuhren, die durch CAP_BPF gelenkt werden (die letztere, aber schwachere Capability wird fur den Zugriff auf dieses Funktionalitat bevorzugt). o die gleichen Leistungsuberwachungsmechanismen einsetzen, die durch CAP_PERFMON gelenkt werden (die letztere, aber schwachere Capability wird fur den Zugriff auf dieses Funktionalitat bevorzugt). o IPC_SET- und IPC_RMID-Aktion auf beliebigen System-V-IPC-Objekten ausfuhren; o RLIMIT_NPROC-Ressourcenbegrenzung ausser Kraft setzen; o Aktionen an den erweiterten Attributen trusted und security durchfuhren (siehe xattr(7)); o lookup_dcookie(2) verwenden; o ioprio_set(2) verwenden, um IOPRIO_CLASS_RT und (vor Linux 2.6.25) IOPRIO_CLASS_IDLE-E/A-Scheduling-Klassen zuzuweisen; o PID falschen, wenn Socket-Berechtigungsnachweise via UNIX-Domain-Sockets weitergebeben werden; o die systemweite Grenze der Anzahl der offenen Dateien (/proc/sys/fs/file-max) in Systemaufrufen, die Dateien offnen (z.B. accept(2), execve(2), open(2), pipe(2)) uberschreiben; o Schalter CLONE_* einsetzen, der neue Namensraume mit clone(2) und unshare(2) erstellt (seit Linux 3.8 benotigt die Erzeugung von Benutzernamensraumen allerdings keine Capability mehr); o auf privilegierte perf-Ereignisinformationen zugreifen; o setns(2) aufrufen (benotigt CAP_SYS_ADMIN im Namensraum target); o fanotify_init(2) aufrufen; o privilegierte Aktionen KEYCTL_CHOWN und KEYCTL_SETPERM von keyctl(2) ausfuhren; o madvise(2)-MADV_HWPOISON-Aktion ausfuhren; o den TIOCSTI ioctl(2) verwenden, um Zeichen in die Eingabewarteschlange eines Terminals, dass nicht das vom aufrufenden gesteuerte Terminal ist, einzufugen; o veralteten Systemaufruf nfsservctl(2) verwenden; o veralteten Systemaufruf bdflush(2) verwenden; o verschiedene privilegierte Blockgerate-ioctl(2)-Aktion ausfuhren; o verschiedene privilegierte Dateisystem-ioctl(2)-Aktionen ausfuhren; o privilegierte ioctl(2)-Aktionen am Gerat /dev/random durchfuhren (siehe random(4)); o einen seccomp(2)-Filter installieren, ohne zuerst das no_new_privs Thread-Attribut setzen zu mussen; o Erlauben-/Verweigern-Regeln fur Geratesteuergruppen verandern; o ptrace(2) PTRACE_SECCOMP_GET_FILTER Aktionen einsetzen, um die Seccomp-Filter verfolgter Prozesse auszugeben; o die Aktion PTRACE_SETOPTIONS von ptrace(2) einsetzen, um den Seccomp-Schutz des verfolgten Prozesses vorubergehend ausser Kraft zu setzen (d.h. der Schalter PTRACE_O_SUSPEND_SECCOMP); o administrative Aktionen auf vielen Geratetreibern ausfuhren; o Autogroup-Nice-Werte durch Schreiben von /proc/PID/autogroup (siehe sched(7)) verandern. CAP_SYS_BOOT reboot(2) und kexec_load(2) verwenden. CAP_SYS_CHROOT o chroot(2) verwenden; o Einhangenamensraume mittels setns(2) andern. CAP_SYS_MODULE o Kernelmodule laden und entladen (siehe init_module(2) und delete_module(2)); o vor Linux 2.6.25: Capabilitys aus der systemweiten Capability-Begrenzungsmenge entfernen. CAP_SYS_NICE o den Nice-Wert von Prozessen absenken (nice(2), setpriority(2)) und den Nice-Wert von beliebigen Prozessen andern; o Echtzeit-Scheduling-Richtlinien zum Prozessaufruf und Scheduling-Richtlinien und -Prioritaten fur beliebige Prozesse setzen (sched_setscheduler(2), sched_setparam(2), sched_setattr(2)); o CPU-Affinitat fur beliebige Prozesse setzen (sched_setaffinity(2)); o E/A-Scheduling-Klassen und -Prioritaten fur beliebige Prozesse setzen (ioprio_set(2)); o migrate_pages(2) auf beliebige Prozesse anwenden und Prozessen erlauben, auf beliebige Knoten zu migrieren; o move_pages(2) auf beliebige Prozesse anwenden; o den Schalter MPOL_MF_MOVE_ALL mit mbind(2) und move_pages(2) verwenden. CAP_SYS_PACCT acct(2) verwenden. CAP_SYS_PTRACE o Nachverfolgen beliebiger Prozesse mittels ptrace(2); o get_robust_list(2) auf beliebige Prozesse anwenden; o Daten vom oder zum Speicher beliebiger Prozesse mittels process_vm_readv(2) und process_vm_writev(2) ubertragen; o Prozesse mittels kcmp(2) inspizieren. CAP_SYS_RAWIO o E/A-Port-Aktionen ausfuhren (iopl(2) und ioperm(2)); o auf /proc/kcore zugreifen; o die FIBMAP-Aktion ioctl(2) einsetzen; o Gerate fur den Zugriff auf x86-modellspezifische Register (MSRs, siehe msr(4)) offnen; o /proc/sys/vm/mmap_min_addr aktualisieren; o Speichereinblendungen an Adressen unterhalb des durch /proc/sys/vm/mmap_min_addr angegebenen Wertes erstellen; o Dateien in /proc/bus/pci einblenden; o /dev/mem und /dev/kmem offnen; o verschiedene SCSI-Gerate-Befehle ausfuhren; o bestimmte Aktionen auf hpsa(4)- und cciss(4)-Geraten ausfuhren; o eine Reihe von Gerate-spezifischen Aktionen auf anderen Geraten ausfuhren. CAP_SYS_RESOURCE o reservierten Platz auf Ext2-Dateisystemen verwenden; o ioctl(2)-Aufrufe ausfuhren, die das Journaling von Ext3 steuern; o Platten-Kontingent-Begrenzungen ausser Kraft setzen; o Ressourcenbegrenzungen erhohen (siehe setrlimit(2)); o RLIMIT_NPROC-Ressourcenbegrenzung ausser Kraft setzen; o maximale Anzahl von Konsolen bei der Konsolenzuteilung ausser Kraft setzen; o maximale Anzahl an Tastaturdefinitionen ausser Kraft setzen; o mehr als 64 Hz-Unterbrechungen von der Echtzeituhr erlauben; o die msg_qbytes-Begrenzung fur eine System-V-Nachrichtenwarteschlange uber die Grenze in /proc/sys/kernel/msgmnb anheben (siehe msgop(2) und msgctl(2)); o erlauben, die Ressourcenbegrenzung RLIMIT_NOFILE bezuglich der Anzahl der >>laufenden<< Dateideskriptoren zu umgehen, wenn Dateideskriptoren an andere Prozesse mittels UNIX-Domain-Sockets ubergeben werden (siehe unix(7)); o die /proc/sys/fs/pipe-size-max-Begrenzung beim Setzen der Kapazitat einer Pipe mittels des F_SETPIPE_SZ-Befehls fcntl(2) ausser Kraft setzen; o F_SETPIPE_SZ verwenden, um die Kapazitat einer Pipe uber die in /proc/sys/fs/pipe-max-size angegebene Grenze erhohen; o die /proc/sys/fs/mqueue/queues_max, /proc/sys/fs/mqueue/msg_max, und /proc/sys/fs/mqueue/msgsize_max-Begrenzungen beim Erstellen von POSIX-Nachrichtenwarteschlangen (siehe mq_overview(7)) ausser Kraft setzen; o die prctl(2)-Aktion PR_SET_MM einsetzen; o /proc/PID/oom_score_adj auf einen Wert niedriger als den zuletzt durch einen Prozess mit CAP_SYS_RESOURCE gesetzten Wert setzen. CAP_SYS_TIME Systemuhr setzen (settimeofday(2), stime(2), adjtimex(2)); Echtzeit- (Hardware-)Uhr setzen. CAP_SYS_TTY_CONFIG vhangup(2) einsetzen; verschiedene privilegierte ioctl(2)-Aktionen auf virtuelle Terminals einsetzen. CAP_SYSLOG (seit Linux 2.6.37) o Privilegierte syslog(2)-Aktionen ausfuhren. Siehe syslog(2) fur Informationen, welche Aktionen Privilegien benotigen. o Uber /proc bereitgestellte Kernel-Adressen und andere Schnittstellen anschauen, wenn /proc/sys/kernel/kptr_restrict den Wert 1 hat. (Lesen Sie die Diskussion uber kptr_restrict in proc(5).) CAP_WAKE_ALARM (seit Linux 3.0) Etwas auslosen, dass das System aufwecken wird (siehe die Timer CLOCK_REALTIME_ALARM und CLOCK_BOOTTIME_ALARM). Fruhere und heutige Implementierungen Eine komplette Implementierung von Capabilitys verlangt folgendes: o Fur alle privilegierten Aktionen muss der Kernel prufen, ob der Thread die benotigten Capabilitys in seiner effektiven Menge hat. o Der Kernel muss Systemaufrufe bereitstellen, die es erlauben, dass die Capability-Menge des Threads geandert und ermittelt wird. o Das Dateisystem muss das Anhangen von Capabilitys an ausfuhrbare Dateien erlauben, so dass ein Prozess solche Capabilitys erhalt, wenn die Datei ausgefuhrt wird. Vor Linux 2.6.24 waren nur die ersten zwei dieser Anforderungen erfullt, seit Linux 2.6.24 sind alle drei Anforderungen erfullt. Hinweise fur Kernel-Entwickler Wenn Sie eine neue Kernel-Funktionalitat hinzufugen, die uber eine Capability geregelt werden soll, beachten Sie die nachfolgenden Punkte. o 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. o Sie haben die Wahl, entweder ein neues Capability fur Ihre neue Funktionalitat hinzuzufugen, oder die Funktionalitat einer bereits bestehenden Capability zuzuordnen. Um die Menge der Capabilitys auf eine verwaltbare Grosse zu begrenzen, wird die zweite Variante bevorzugt, ausser es gibt uberzeugende Grunde, die erste Variante zu wahlen. (Es gibt auch eine technische Grenze: Die Grosse der Capability-Menge ist derzeit auf 64 bit beschrankt.) o Um zu bestimmen, zu welcher bestehenden Capability Ihre neue Funktionalitat am besten zugeordnet werden konnte, prufen Sie die obige Liste der Capabilitys, um ein >>Silo<< zu finden, in das Ihre neue Funktionalitat am besten passt. Ein Vorgehen besteht darin, zu bestimmen, ob es andere Funktionalitaten gibt, die Capabilitys benotigen, die immer zusammen mit Ihrer neuen Funktionalitat benotigt werden. Falls Ihre neue Funktionalitat ohne diese andere Funktionalitat nutzlos ist, dann sollten Sie die gleiche Capability wie die andere Funktionalitat verwenden. o Verwenden Sie nicht CAP_SYS_ADMIN, falls Sie es irgendwie vermeiden konnen. Ein riesiger Anteil an bestehenden Capability-Uberprufungen ist dieser Capability zugeordnet (siehe die Teilliste weiter oben). Sie kann glaubhaft als >>der neue Root<< bezeichnet werden, da sie eine grosse Bandbreite an Rechten verleiht, und andererseits bedeutet ihr grosser Geltungsbereich, dass es eine Capability ist, die von vielen privilegierten Programmen benotigt wird. Verschlimmern Sie das Problem nicht. Die einzigen neuen Funktionalitaten, die CAP_SYS_ADMIN zugeordnet werden sollten, sind diejenigen, die eng zu bestehenden Anwendungsfallen in diesem Silo passen. o Falls Sie ermittelt haben, dass Sie wirklich eine neue Capability fur Ihre Funktionalitat benotigen, fuhren Sie sie nicht als >>Einzelverwendung<<-Capability ein (oder benennen Sie es so). Daher war beispielsweise die Erganzung 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 zukunftige Anwendungsfalle passen konnten. Capability-Mengen von Threads Jeder Thread hat die folgenden Capability-Mengen, die null oder mehr der oben aufgefuhrten Capabilitys enthalten: Permitted (erlaubt) Dies ist die begrenzende Ubermenge fur die effektiven Capabilitys, die ein Thread annehmen kann. Es ist auch die begrenzende Ubermenge fur die Capabilites, die zu der vererbbaren Menge durch einen Thread hinzugefugt werden durfen, der nicht die Capability CAP_SETPCAP in seiner effektiven Menge hat. Falls ein Thread eine Capability aus seiner erlaubten Menge entfernt, kann es diese Capability niemals wiedererlangen (ausser es fuhrt ein Set-User-ID-Root-Programm mit execve(2) aus oder ein Programm, dessen zugeordnete Datei-Capabilitys diese Capability wieder bewilligen). Inheritable (vererbbar) Dies ist eine Menge von Capabilitys, die uber execve(2) hinweg erhalten bleiben. Vererbbare Capabilitys bleiben bei der Ausfuhrung jedes Programms vererbbar und vererbbare Capbabilities werden zu der erlaubten Menge bei der Ausfuhrung eines Programms, das die entsprechenden Bits in der Datei-Vererbbaren-Menge gesetzt hat, hinzugefugt. Da vererbbare Capabilitys im allgemeinen nicht uber execve(2)-Aufrufe erhalten werden, wenn dies nicht als Benutzer root erfolgt, sollten Anwendungen, die Hilfsprogramme mit erhohten Capabilitys ausfuhren wollen, die Verwendung der unten beschriebenen Umgebungs-Capabilitys in Betracht ziehen. Effective (effektiv) Dies ist die Menge an Capabilitys, der vom Kernel zur Durchfuhrung von Rechteprufungen fur den Thread verwandt wird. Bounding (pro-Thread seit Linux 2.6.25) Die Capability-Begrenzungsmenge ist ein Mechanismus, der zur Begrenzung der Capabilitys, die wahrend eines execve(2) erlangt werden, dienen kann. Seit Linux 2.6.25 ist dies eine pro-Thread-Capability-Menge. In alteren Kerneln war die Capability-Begrenzungsmenge ein systemweites Attribut, das von allen Threads des Systems gemeinsam benutzt wurde. Fur weitere Details, siehe Capability-Begrenzungsmenge unten. Ambient (Umgebung) (seit Linux 4.3) Dies ist eine Menge von Capabilitys, die uber execve(2) eines nicht privilegierten Programms hinweg erhalten bleiben. Die Umgebungs-Capability-Menge folgt der Invarianz, dass keine Capability jemals eine Umgebungs-Capability sein kann, falls sie nicht sowohl erlaubt als auch vererbbar ist. Die Umgebungs-Capability-Menge kann direkt mit prctl(2) verandert werden. Umgebungs-Capabilitys werden automatisch abgesenkt, falls entweder die entsprechende erlaubte oder vererbbare Capability abgesenkt wird. Wird ein Programm ausgefuhrt, das die UID oder GID aufgrund von set-user-ID- oder set-group-ID-Bits andert oder das uber eine Menge an Datei-Capabilitys verfugt, dann wird die Umgebungsmenge geleert. Umgebungs-Capabilitys werden zu der erlaubten Menge hinzugefugt und der effektiven Menge zugewiesen, wenn execve(2) aufgerufen wird. Falls Umgebungs-Capabilitys dazu fuhren, dass die erlaubten und effektiven Capabilitys wahrend eines execve(2) anwachsen, lost dies keinen sicheren Ausfuhrmodus, wie in ld.so(8) beschrieben, aus. Ein mittels fork(2) erstelltes Kind erbt Kopien der Eltern-Capability-Menge. Fur Details, wie execve(2) Capabilitys beeinflusst, siehe nachfolgenden Abschnitt Umwandlungen von Capabilitys wahrend execve(). Mittels capset(2) kann ein Thread seine eigenen Capability-Mengen bearbeiten; siehe nachfolgenden Abschnitt Programmatische Anpassung von Capability-Mengen. Seit Linux 3.2 legt die Datei /proc/sys/kernel/cap_last_cap den numerischen Wert der hochsten vom laufenden Kernel unterstutzten Capability offen. Dies kann zur Bestimmung des hochsten Bits, das in einer Capability-Gruppe gesetzt werden kann, genutzt werden. Datei-Capabilitys Seit Linux 2.6.24 unterstutzt der Kernel die Zuordnung von Capability-Mengen zu einer ausfuhrbaren 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 benotigt die Capability CAP_SETFCAP. Die Datei-Capability-Mengen bestimmen zusammen mit den Capability-Mengen des Threads die Capabilitys nach einem execve(2). Die drei Datei-Capability-Mengen sind: Permitted (erlaubt, fruher als forced (erzwungen) bekannt): Diese Capabilitys werden dem Thread automatisch erlaubt, unabhangig von den geerbten Capabilitys des Threads. Inheritable (vererbbar, fruher als allowed (erlaubt) bekannt): Diese Menge wird mittels AND mit der vererbbaren Menge des Threads verknupft, um zu bestimmen, welche vererbbaren Capabilitys in der erlaubten Menge des Threads nach einem execve(2) aktiviert werden. Effective (effektiv): Dies ist keine Menge, sondern eher ein einziges Bit. Falls dieses Bit gesetzt ist, dann werden wahrend eines execve(2) die gesamten erlaubten Capabilties fur 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. Aktivieren des effektiven Datei-Capability-Bits impliziert, dass jede erlaubte oder vererbte Datei-Capability, die dazu fuhrt, dass ein Thread die entsprechende erlaubte Capability wahrend eines execve(2) erlangt (siehe den nachfolgenden Abschnitt Umwandlungen von Capabilitys wahrend execve()), auch dazu fuhrt, 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 fur irgendeine Capability aktiviert ist, dann muss der effektive Schalter auch als aktiviert fur alle anderen Capabilitys, fur die die entsprechenden erlaubten oder vererbbaren Schalter aktiviert sind, spezifiziert werden. Erweiterte Attributversionierung von Datei-Capabilitys Um Erweiterbarkeit zu erlauben, unterstutzt 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 fur Benutzerraum-Anwendungen nicht direkt sichtbar. Derzeit werden die folgenden Versionen unterstutzt: VFS_CAP_REVISION_1 Dies war die ursprungliche Datei-Capability-Implementierung, die 32-Bit-Masken fur Datei-Capabilitys unterstutzte. VFS_CAP_REVISION_2 (seit Linux 2.6.25) Diese Version erlaubt Datei-Capability-Masken in der Grosse von 64 Bit und wurde notwendig, da die Anzahl an unterstutzen Capabilitys 32 uberstieg. Der Kernel unterstutzt weiterhin transparent die Ausfuhrung von Dateien mit 32-Bit-Version-1-Capability-Masken, aber wenn Capabilitys zu Dateien hinzugefugt werden, die bisher keine Capabilitys hatten, oder Capabilitys von bestehenden Dateien geandert werden, wird automatisch das Version-2-Schema (oder moglicherweise das unten beschriebene Version-3-Schema) verwandt. VFS_CAP_REVISION_3 (seit Linux 4.14) Version-3-Datei-Capabilitys werden zur Unterstutzung von (nachfolgend beschriebenen) namensraumbezogenen Datei-Capabilitys bereitgestellt. Wie bei Version-2-Datei-Capabilitys sind die Version-3-Capability Masken 64 Bit gross. Aber zusatzlich 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 ursprunglichen Namensraum abgebildet wird.) Version-3-Datei-Capabilitys sind so entwickelt worden, dass sie mit Version-2-Capabilitys koexistieren konnen, d.h. auf einem modernen Linux-System konnen einige Dateien Version-2-Capabilitys tragen, wahrend andere Version-3-Capabilitys haben. Vor Linux 4.14 war die einzige Art des erweiterten Attributs fur Datei-Capabilitys, die an eine Datei angehangt werden konnten, ein VFS_CAP_REVISION_2-Attribut. Seit Linux 4.14 hangt die Version des erweiterten Attributs security.capability, die an eine Datei angehangt werden kann, von den Umstanden ab, unter denen das Attribut erstellt wurde. Seit Linux 4.14 wird ein erweitertes Attribut security.capability automatisch als ein Version-3-(VFS_CAP_REVISION_3)-Attribut erstellt (oder in ein solches umgewandelt), falls beide folgenden Punkte zutreffen: o 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 eingehangt wurde.) o Der Thread hat die Capability CAP_SETFCAP uber der Datei-Inode, was bedeutet, dass (a) der Thread die Capability CAP_SETFCAP in seinem eigenen Benutzernamensraum hat und (b) die UID und GID der Datei-Inode Abbildungen in den Namensraum des schreibenden Benutzers haben. Wenn ein erweitertes Attribut VFS_CAP_REVISION_3 security.capability erstellt wird, wird die Wurzelbenutzerkennung des erstellenden Namensraums des Benutzers in dem erweiterten Attribut gespeichert. Im Gegensatz dazu wird beim Erstellen oder Verandern eines erweiterten Attributs security.capability aus einem privilegierten (CAP_SETFCAP) Thread, der sich in dem Namensraum befindet, unter dem das darunterliegende Dateisystem eingehangt wurde (dies bedeutet normalerweise den anfanglichen Benutzernamensraum), automatisch zu der Erstellung eines Version-2-(VFS_CAP_REVISION_2)-Attributs fuhren. Beachten 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 Umstanden erstellt wird, wenn eine Anwendung im Benutzerraum ein security.capability-Attribut im Version-2-Format schreibt (setxattr(2)). Entsprechend wird das zuruckgelieferte Attribut (automatisch) vereinfacht, um als Version-2-Attribut zu erscheinen (d.h. der Ruckgabewert ist die Grosse eines Version-2-Attrbutes und enthalt 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 Abkomling dieses Namensraums) erstellt wurde, abgefragt wird. Diese automatische Ubersetzung bedeutet, dass an den Werkzeugen im Benutzerraum (z.B. setcap(1) und getcap(1)) keine Anderung vorgenommen werden muss, damit diese Werkzeuge zum Erstellen und Abfragen von Version-3-security.capability-Attributen verwandt werden konnen. Beachten Sie, dass der Datei entweder ein erweitertes Attribut security.capability der Version 2 oder 3 zugeordnet werden kann, aber nicht beide: Erstellung oder Anderung des erweiterten Attributs security.capability wird automatisch die Version abhangig von den Umstanden, in denen das erweiterte Attribut erstellt oder verandert wird, anpassen. Umwandlungen von Capabilitys wahrend execve() Wahrend eines execve(2) berechnet der Kernel die neuen Capabilitys eines Prozesses mit dem folgenden Algorithmus: P'(ambient) = (Datei ist privilegiert) ? 0 : P(ambient) P'(permitted) = (P(inheritable) & F(inheritable)) | (F(permitted) & P(bounding)) | P'(ambient) P'(effective) = F(effective) ? P'(permitted) : P'(ambient) P'(inheritable) = P(inheritable) [d.h. unverandert] P'(bounding) = P(bounding) [d.h. unverandert] wobei: P() bezeichnet den Wert einer Capability-Menge des Threads vor dem execve(2) P'() bezeichnet den Wert einer Capability-Menge des Threads nach dem execve(2) F() bezeichnet eine Datei-Capability-Menge Beachten Sie die nachfolgenden Details in Hinblick auf die obigen Capability-Umwandlungsregeln: o Die Umgebungs-Capability-Menge ist erst seit Linux 4.3 vorhanden. Bei der Bestimmung der Ubergange der Umgebungsmenge wahrend eines execve(2) bezeichnet eine privilegierte Datei eine, die uber Capabilitys verfugt oder das Bit >>set-user-ID<< oder >>set-group-ID<< gesetzt hat. o 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 wahrend eines execve(2) zu berechnen, auf die gleiche Art wie oben fur P(bounding) gezeigt. Hinweis: Wahrend der oben beschriebenen Capability-Ubergange konnten aus den gleichen Grunden, aus denen auch die Bits set-user-ID and set-group-ID ignoriert werden, Datei-Capabilitys ignoriert (als leer betrachtet) werden; siehe execve(2). Ahnlich werden Datei-Capabilitys ignoriert, falls der Kernel mit der Option no_file_caps gestartet wurde. Hinweis: Entsprechend den obigen Regeln werden alle Capabilitys, die in der erlaubten und effektiven Menge vorhanden sind, zuruckgesetzt, falls ein Prozess mit von Null verschiedenen Benutzerkennungen ein execve(2) durchfuhrt. Fur die Behandlung der Capabilitys, wenn ein Prozess mit der Benutzerkennung Null ein execve(2) durchfuhrt, siehe unten Capabilitys und Ausfuhrung von Programmen durch root. Sicherheitsprufungen fur Capability-unfahige Programme Ein Capability-unfahiges Programm ist eine Anwendung, die fur Datei-Capabilitys markiert ist, aber noch nicht fur 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.) Fur solche Anwendungen wird das effektive Capability-Bit auf die Datei gesetzt, so dass die erlaubten Capabilitys automatisch beim Ausfuhren der Datei in der effektiven Menge aktiviert werden. Der Kernel erkennt fur den hier beschriebenen Zweck eine Datei, die das effektive Capability-Bit gesetzt hat, als Capability-unfahig. Beim Ausfuhren eines Capability-unfahigen Programms pruft 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 konnte, liegt darin, dass die Capability-Begrenzungsmenge einige der Capabilitys in der Datei-erlaubten Menge ausblenden konnte.) Falls der Prozess nicht die komplette Menge der Datei-erlaubten Capabilitys erlangte, schlagt execve(2) mit dem Fehler EPERM fehl. Dies verhindert mogliche Sicherheitsrisiken, die daraus resultieren, dass ein Capability-unfahiges Programm mit weniger als den benotigten Privilegien ausgefuhrt wird. Beachten Sie, dass definitionsgemass die Anwendung das Problem nicht selbst erkennen konnte, da sie nicht das libcap(3)-API einsetzt. Capabilitys und Ausfuhrung von Programmen durch root Um die traditionellen UNIX-Semantiken abzubilden, fuhrt der Kernel eine besondere Behandlung der Datei-Capabilitys durch, wenn ein Prozess mit UID 0 (root) ein Programm ausfuhrt und wenn ein set-user-ID-root-Programm ausgefuhrt wird. Nachdem alle Anderungen an der effektiven Kennung des Prozesses vorgenommen wurden, die durch das Modus-Bit set-user-ID des Programmes ausgelost wurden, z.B. Umschalten der effektiven Benutzerkennung auf 0 (root), da ein set-user-ID-root-Programm ausgefuhrt wurde, berechnet der Kernel die Datei-Capability-Menge wie folgt: (1) Falls die reale oder effektive Benutzerkennung des Prozesses 0 (root) ist, dann werden die vererbbaren und erlaubten Mengen ignoriert; stattdessen werden sie fiktiv als komplett Eins (d.h. alle Capabilitys aktiviert) betrachtet. (Es gibt fur dieses Verhalten eine Ausnahme, die unten in Set-user-ID-root-Programme, die Datei-Capabilitys haben beschrieben ist.) (2) Falls die effektive Benutzerkennung des Prozesses 0 (root) ist oder das effektive Bit der Datei tatsachlich aktiviert ist, dann wird das effektive Datei-Bit fiktiv als Eins (aktiviert) definiert. Diese fiktiven Werte fur die Capability-Menge der Datei werden dann verwandt, um wie oben beschrieben den Ubergang der Capabilitys des Prozesses wahrend eines execve(2) zu berechnen. 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 uber keine Capabilitys verfugt, mit execve(2) ausfuhrt, oder wenn ein Prozess, dessen reale und effektive UIDs Null sind, ein Programm mit execve(2) ausfuhrt: P'(permitted) = P(inheritable) | P(bounding) P'(effective) = P'(permitted) Konsequenterweise erlangt der Prozess alle Capabilitys in seiner erlaubten und effektiven Capability-Menge, ausser denen, die in seiner Capability-Begrenzungsmenge ausmaskiert sind. (In der Berechnung von P'(permitted) kann der Ausdruck fur P'(ambient) wegvereinfacht werden, da er per Definition eine gultige Untermenge von P(inheritable) ist.) Die in diesem Unterabschnitt beschriebene besondere Behandlung des Benutzers 0 (root) kann mittels des nachfolgend beschriebenen Securebits-Mechanismus deaktiviert werden. Set-user-ID-root-Programme, die Datei-Capabilitys haben Es gibt zu dem oben in Capabilitys und Ausfuhrung von Programmen durch root beschriebenen Verhalten eine Ausnahme. Falls (a) das ausgefuhrte Programm uber Capabilitys verfugt 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 berucksichtigt (d.h. sie werden nicht fiktiv als komplett Einsen angenommen). Der normale Weg, bei dem diese Situation auftreten kann, ist die Ausfuhrung eines set-UID-root-Programms, das auch uber Datei-Capabilitys verfugt. Wenn ein solches Programm ausgefuhrt wird, erlangt der Prozess nur die durch das Programm eingeraumten Capabilitys (d.h. nicht alle Capabilitys, was passierte, wenn ein set-user-ID-Root-Programm ausgefuhrt wurde, das keine zugeordneten Datei-Capabilitys hat). Beachten Sie, dass einem Programm eine leere Capability-Menge zugeordnet werden kann und es daher moglich ist, ein set-user-ID-root-Programm zu erstellen, das die effektive und die gespeicherte set-user-ID des Prozesses, der das Programm ausfuhrt, auf 0 setzt, aber dem Prozess keine Capabilitys gewahrt. Capability-Begrenzungsmenge Die Capability-Begrenzungsmenge ist ein Sicherheitsmechanismus, der zur Begrenzung der Capabilitys, die wahrend eines execve(2) erlangt werden konnen, dienen kann. Die Begrenzungsmenge wird auf die folgende Art und Weise benutzt: o Wahrend eines execve(2) wird die Capability-Begrenzungsmenge mittels AND mit der erlaubten Datei-Capability-Menge verknupft und das Ergebnis dieser Aktion wird der erlaubten Capability-Menge des Threads zugewiesen. Die Capability-Begrenzungsmenge stellt daher eine Grenze fur die erlaubten Capabilitys dar, die einer ausfuhrbaren Datei erlaubt werden durfen. o (Seit Linux 2.6.25) Die Capability-Begrenzungsmenge agiert als begrenzende Ubermenge fur die Capabilitys, die ein Thread zu seiner vererbbaren Menge mittels capset(2) hinzufugen kann. Das bedeutet, dass ein Thread eine Capability nicht zu seiner vererbbaren Menge hinzufugen 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) ausfuhrt, die diese Capability in seiner vererbbaren Menge hat. 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 ausfuhrt, die diese Capability in seiner vererbbaren Menge enthalt. Abhangig von der Kernelversion ist die Capability-Begrenzungsmenge entweder ein systemweites Attribut oder ein prozessweises Attribut. Capability-Begrenzungsmenge seit Linux 2.6.25 Seit Linux 2.6.25 ist die Capability-Begrenzungsmenge ein pro-Thread-Attribut. (Die nachfolgend beschriebene systemweite Capability-Begrenzungsmenge existiert nicht mehr.) Die Begrenzungsmenge wird bei fork(2) von dem Elternprozess des Threads vererbt und bleibt uber ein execve(2) erhalten. Ein Thread kann mittels der Aktion prctl(2) PR_CAPBSET_DROP Capabilitys aus seiner Begrenzungsmenge entfernen, vorausgesetzt, er verfugt uber die Capability CAP_SETPCAP. Sobald eine Capability aus der Begrenzungsmenge entfernt wurde, kann sie nicht mehr zu der Menge wieder hinzugefugt werden. Ein Thread kann mittels der Aktion prctl(2) PR_CAPBSET_READ herausfinden, ob eine Capability in seiner Begrenzungsmenge liegt. Entfernen von Capabilitys aus der Begrenzungsmenge ist nur moglich, falls Datei-Capabilitys in den Kernel kompiliert wurden. Vor Linux 2.6.33 waren Datei-Capabilitys eine optionale Funktionalitat, 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 vollstandigen Begrenzungsmenge ohne CAP_SETPCAP, da diese Capability eine andere Bedeutung hat, wenn es keine Datei-Capabilitys gibt. Die Entfernung einer Capability aus der Begrenzungsmenge entfernt sie nicht aus der vererbbaren Menge des Threads. Allerdings verhindert es das Zuruckfugen in die vererbbare Menge des Threads in der Zukunft. Capability-Begrenzungsmenge vor Linux 2.6.25 Vor Linux 2.6.25 ist die Capability-Begrenzungsmenge ein systemweites Attribut, das alle Threads auf dem System betrifft. Auf die Begrenzungsmenge kann uber die Datei /proc/sys/kernel/cap-bound zugegriffen werden. (Zur Erhohung der Konfusion wird dieser Bitmaskenparameter als vorzeichenbehaftete Dezimalzahl in /proc/sys/kernel/cap-bound ausgedruckt.) Nur 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. Auf einem Standardsystem maskiert die Capability-Begrenzungsmenge immer die Capability CAP_SETPCAP. Um diese Einschrankung zu entfernen (gefahrlich!), verandern Sie die Definition von CAP_INIT_EFF_SET in include/linux/capability.h und bauen Ihren Kernel neu. Die systemweite Capability-Begrenzungsmengenfunktion wurde zu Linux 2.2.11 hinzugefugt. Effekt von Benutzerkennungsanderungen auf Capabilitys Um die traditionellen Semantiken fur Ubergange zwischen 0 und von 0 verschiedenen Kennungen zu erhalten, fuhrt der Kernel folgende Anderungen an den Capability-Mengen eines Threads bei Anderung der realen, effektiven, gespeicherten und Dateisystem-Benutzerkennung (unter Verwendung von setuid(2), setresuid(2) oder ahnlich) durch: o Falls einer der realen, effektiven oder gespeicherten Set-User-IDs vorher 0 war und als Ergebnis der UID-Anderung alle dieser Kennungen eine von 0 verschiedenen Wert haben, dann werden alle Capabilitys aus den erlaubten, effektiven und Umgebungs-Capability-Mengen geloscht. o Falls die effektive Benutzerkennung von 0 auf einen von 0 verschiedenen Wert geandert wird, werden alle Capabilitys aus der effektiven Menge geloscht. o Falls die effektive Benutzerkennung von einem von 0 verschiedenen Wert auf 0 geandert wird, dann wird die erlaubte Menge in die effektive Menge kopiert. o Falls die Dateisystem-Benutzerkennung von 0 auf einen anderen Wert geandert 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 geandert wird, dann werden alle dieser Capabilitys, die in der erlaubten Menge aktiviert waren, in der effektiven Menge aktiviert. Falls ein Thread, der einen Wert 0 fur mindestens eine seiner Benutzerkennungen hat, verhindern mochte, dass seine erlaubte Capability-Menge bereinigt wird, wenn er alle seine Benutzerkennungen auf einen von 0 verschiedenen Wert setzt, kann er dies mittels der unten beschriebenen SECBIT_KEEP_CAPS-Securebits-Schaltern erreichen. Programmatische Anpassung von Capability-Mengen Ein Thread kann seine erlaubten, effektiven und vererbbaren Capability-Mengen mittels der Systemaufrufe capget(2) und capset(2) ermitteln und andern. Allerdings werden fur 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 Anderungen an den Capability-Mengen des Threads: o Falls der Aufrufende nicht uber die Capability CAP_SETPCAP verfugt, dann muss die neue vererbbare Menge eine Teilmenge der Kombination der bestehenden vererbbaren und erlaubten Menge sein. o (Seit Linux 2.6.25) Die neue vererbbare Menge muss eine Teilmenge der Kombination der bestehenden vererbbaren Menge und der Capability-Begrenzungsmenge sein. o Die neue erlaubte Menge muss eine Teilmenge der bestehenden erlaubten Menge sein (d.h. es ist nicht moglich, erlaubte Capabilitys zu erlangen, die der Thread derzeit nicht hat). o Die neue effektive Menge muss eine Teilmenge der neuen erlaubten Menge sein. Der Schalter securebits: eine reine Capability-Umgebung einrichten Beginnend mit Linux 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 fur UID 0 (root) verwandt werden konnen. Dies sind die folgenden Schalter: SECBIT_KEEP_CAPS 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 fuhrt das Umschalten der UIDs dazu, dass er alle erlaubten Capabilitys verliert. Dieser Schalter wird bei execve(2) immer bereinigt. Bachten 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 uber diesen Schalter verfugt und seine effektive UID bereits von Null verschieden ist und der Thread anschliessend alle anderen UIDs auf einen von Null verschiedenen Wert umschaltet, dann werden die effektiven Capabilitys nicht bereinigt. Die Einstellung des Schalters SECBIT_KEEP_CAPS wird ignoriert, falls der Schalter SECBIT_NO_SETUID_FIXUP gesetzt ist. (Letzterer Schalter stellt eine Ubermenge des Effekts des ersteren Schalters bereit.) Dieser Schalter stellt die gleiche Funktionalitat wie die altere Aktion prctl(2) PR_SET_KEEPCAPS bereit. SECBIT_NO_SETUID_FIXUP Setzen dieses Schalters hindert den Kernel daran, die erlaubten, effektiven und Umgebungs-Capability-Mengen des Prozesses anzupassen, wenn die effektive und die Dateisystem-UID eines Threads zwischen null und von null verschiedenen Werten umgeschaltet werden. Siehe oben Effekt von Benutzerkennungsanderungen auf Capabilitys. SECBIT_NOROOT Falls dieses Bit gesetzt ist, dann verleiht der Kernel keine Capabilitys, wenn ein Set-User-ID-Root-Programm ausgefuhrt wird oder wenn ein Prozess mit einer effektiven oder realen UID von 0 execve(2) aufruft. (Siehe oben Capabilitys und Ausfuhrung von Programmen durch root.) SECBIT_NO_CAP_AMBIENT_RAISE Durch Setzen dieses Schalters durfen keine Umgebungs-Capabilitys mit der prctl(2)-Aktion PR_CAP_AMBIENT_RAISE gehoben werden. Jeder der obigen >>basis<<-Schalter hat einen begleitenden >>gesperrten<< Schalter. Das Setzen eines >>gesperrten<< Schalters ist unumkehrbar und hat den Effekt, dass weitere Anderungen an dem entsprechenden Basisschalter nicht mehr moglich sind. Die gesperrten Schalter sind: SECBIT_KEEP_CAPS_LOCKED, SECBIT_NO_SETUID_FIXUP_LOCKED, SECBIT_NOROOT_LOCKED und SECBIT_NO_CAP_AMBIENT_RAISE_LOCKED. Die Schalter securebits konnen mit den Aktionen prctl(2) PR_SET_SECUREBITS und PR_GET_SECUREBITS geandert und abgefragt werden. Die Capability CAP_SETPCAP wird fur die Veranderung der Schalter benotigt. Beachten Sie, dass die Konstanten SECBIT_* nur nachdem Sie die Header-Datei eingebunden haben verfugbar sind. Die Schalter securebits werden von Kindprozessen vererbt. Wahrend eines execve(2) werden alle Schalter beibehalten, ausser SECBIT_KEEP_CAPS, das immer bereinigt wird. Eine Anwendung kann den folgenden Aufruf verwenden, um sich selbst und alle seine Abkommlinge in eine Umgebung zu sperren, in der die einzige Moglichkeit, Capabilitys zu erlangen, darin besteht, ein Programm auzufuhren, das uber die zugeordneten Datei-Capabilitys verfugt: prctl(PR_SET_SECUREBITS, /* SECBIT_KEEP_CAPS off */ SECBIT_KEEP_CAPS_LOCKED | SECBIT_NO_SETUID_FIXUP | SECBIT_NO_SETUID_FIXUP_LOCKED | SECBIT_NOROOT | SECBIT_NOROOT_LOCKED); /* Setzen/Sperren von SECBIT_NO_CAP_AMBIENT_RAISE ist nicht erforderlich */ Namensraumbezogene >>set-user-ID-root<<-Programme Ein set-user-ID-Programm, dessen UID auf die UID passt, die einen Benutzernamensraum erstellte, wird die Capabilitys in den erlaubten und effektiven Mengen ubertragen, wenn es durch irgendeinen Prozess innerhalb dieses Namensraums (oder einen Benutzernamensraum, der davon abstammt) ausgefuhrt wird. Die obigen Regeln uber die Umwandlung der Capabilitys des Prozesses wahrend eines execve(2) sind genau wie oben in Umwandlungen von Capabilitys wahrend execve() und Capabilitys und Ausfuhrung von Programmen durch root beschrieben, wobei im letzeren Unterabschnitt als Unterschied >>root<< die UID des Erstellers des Benutzernamensraums ist. Namensraumbezogene Datei-Capabilitys Traditionelle (d.h. Version 2-)Datei-Capabilitys ordnen nur eine Menge von Capability-Masken einem binaren Programm zu. Wenn ein Prozess ein Programm mit solchen Capabilitys ausfuhrt, erlangt es die zugeordneten Capabilitys (innerhalb seines Benutzernamensraums) wie in den oben beschriebenen Regeln Umwandlungen von Capabilitys wahrend execve() beschrieben. Da Version-2-Datei-Capabilitys dem ausfuhrenden Prozess unabhangig davon, in welchem Namensraum er sich befindet, Capabilitys verleiht, durfen nur privilegierte Prozesse Capabilitys einer Datei zuordnen. Hier bedeutet >>privilegiert<<, dass ein Prozess uber die Capability CAP_SETFCAP in dem Benutzernamensraum, in dem das Dateisystem eingehangt wurde (normalerweise dem initialen Namensraum), verfugt. Diese Einschrankung fuhrt dazu, dass in bestimmten Einsatzfallen Datei-Capabilitys nutzlos sind. Es kann zum Beispiel in namensraumbezogenen Containern wunschenswert sein, in der Lage zu sein, ein Programm zu erstellen, das Capabilitys nur an Prozesse, die innerhalb dieses Containers ausgefuhrt werden, zu verleihen, aber nicht an Prozesse, die ausserhalb des Containers ausgefuhrt werden. Linux 4.14 fugte sogenannte namensraumbezogene Datei-Capabilitys hinzu, um solche Falle zu unterstutzen. 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 Umstanden erstellt. Wenn ein erweitertes Version-3-Attribut security.capability erstellt wird, zeichnet der Kernel nicht nur die Capability-Maske in dem erweiterten Attribut auf, sondern auch die Benutzerkennung von root in dem Namensraum. Wie mit Programmen, die eine Datei-Capability VFS_CAP_REVISION_2 haben, verleiht ein Programm mit Datei-Capability VFS_CAP_REVISION_3 wahrend eines execve() Capabilitys an einen Prozess. Allerdings werden Capabilitys nur verliehen, falls das Programm von einem Prozess ausgefuhrt 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 ausgefuhrt wird, der in einem Nachkommen solch eines Namensraums liegt. Interaktion mit Benutzernamensraumen Fur weitere Informationen uber die Interaktion von Capabilitys und Benutzer-Namensraumen lesen Sie user_namespaces(7). STANDARDS Keine Standards regeln Capabilitys; die Linux-Capability-Implementierung basiert aber auf dem zuruckgezogenen POSIX.1e-Entwurfsstandard . ANMERKUNGEN Beim Versuch, strace(1) auf Programme anzuwenden, die uber Capabilitys verfugen (oder set-user-ID-root-Programme), konnten Sie die Option -u nutzlich finden. Etwas von der Art: $ sudo strace -o trace.log -u ceci ./meinprivprog Von Linux 2.5.27 bis 2.6.26 waren Capabilitys eine optionale Kernelkomponente, die uber die Kernelkonfigurationsoption CONFIG_SECURITY_CAPABILITIES aktiviert/deaktiviert werden konnte. Die Datei /proc/PID/task/TID/status kann zum Betrachten der Capability-Mengen eines Threads verwandt werden. Die Datei /proc/PID/status zeigt die Capability-Mengen des Haupt-Threads eines Prozesses. Vor Linux 3.8 wurden nicht existierende Capabilitys in diesen Mengen als aktiviert (1) angezeigt. Seit Linux 3.8 werden alle nicht existierenden Capabilitys (uber CAP_LAST_CAP) als deaktiviert (0) angezeigt. Das Paket libcap stellt eine Suite von Routinen zum Setzen und Abfragen von Capabilitys bereit, die komfortablere und anderungsstabilere Schnittstellen als die von capset(2) und capget(2) bereitstellen. Dieses Paket stellt auch die Programme setcap(8) und getcap(8) zur Verfugung. Es kann unter folgender Adresse gefunden werden: . Vor Linux 2.6.24 und von Linux 2.6.24 bis 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 moglich, da kein Thread jemals uber CAP_SETPCAP in einem der folgenden Falle verfugt: o In der pre-2.6.25-Implementierung maskiert die systemweite Capability-Begrenzungsmenge /proc/sys/kernel/cap-bound die Capability CAP_SETPCAP immer und dies kann ohne Veranderung der Kernelquellen und dem Neubau des Kernels nicht geandert werden. o Falls Datei-Capabilitys deaktiviert sind (d.h. die Kerneloption CONFIG_SECURITY_FILE_CAPABILITIES deaktiviert ist), dann startet init derart, dass die Capability CAP_SETPCAP aus seiner prozessweisen Begrenzungsmenge entfernt ist und dass die Begrenzungsmenge von allen anderen im System erstellten Prozessen vererbt wird. SIEHE AUCH capsh(1), setpriv(1), prctl(2), setfsuid(2), cap_clear(3), cap_copy_ext(3), cap_from_text(3), cap_get_file(3), cap_get_proc(3), cap_init(3), capgetp(3), capsetp(3), libcap(3), proc(5), credentials(7), pthreads(7), user_namespaces(7), captest(8), filecap(8), getcap(8), getpcaps(8), netcap(8), pscap(8), setcap(8) include/linux/capability.h in dem Linux-Kernelquellbaum UBERSETZUNG Die deutsche Ubersetzung dieser Handbuchseite wurde von Dr. Tobias Quathamer und Helge Kreutzmann erstellt. Diese Ubersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer bezuglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG ubernommen. Wenn Sie Fehler in der Ubersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die Mailingliste der Ubersetzer . Linux man-pages 6.06 31. Oktober 2023 Capabilitys(7)