|
|
| (3 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) |
| Zeile 1: |
Zeile 1: |
| BEZEICHNUNG
| | *[[Was sind Capabilities]] |
| capabilities - Überblick über Linux-Capabilities
| | *[[Capabilities Manpage]] |
| | | *[[Capabilities Beispiele]] |
| BESCHREIBUNG
| | =Links= |
| Für den Zweck der Durchführung von Rechteprüfungen unterscheiden traditionelle
| | *https://www.linux-magazin.de/ausgaben/2008/06/gruenes-licht-fuer-pcaps/ |
| UNIX-Implementierungen zwei Arten von Prozessen: Privilegierte Prozesse (deren effektive
| |
| Benutzer-ID 0 ist, auch als Superuser oder Root benannt) und unprivilegierte Prozesse
| |
| (deren effektive UID von Null verschieden ist). Privilegierte Prozesse übergehen alle
| |
| Kernel-Rechteprüfungen, während unprivilegierte Prozesse der vollen Rechteprüfung,
| |
| basierend auf den Berechtigungsnachweisen des Prozesses (normalerweise: effektive UID,
| |
| effektive GID und ergänzende Gruppenliste), unterliegen.
| |
| | |
| Beginnend mit Kernel 2.2 unterteilt Linux die Privilegien, die traditionell mit dem
| |
| Superuser assoziiert sind, in getrennte Einheiten, die als Capabilities bekannt sind.
| |
| Diese können unabhängig voneinander aktiviert oder deaktiviert werden. Capabilities sind
| |
| ein Attribut pro Thread.
| |
| | |
| Liste der Capabilities
| |
| Die folgende Liste zeigt die in Linux implementierten Capabilities und die Aktionen oder
| |
| Verhalten, die jede Capability erlaubt:
| |
| | |
| CAP_AUDIT_CONTROL (seit Linux 2.6.11)
| |
| Kernel-Auditierung aktivieren und deaktivieren; die Auditierung-Filterregel ändern;
| |
| den Auditstatus und Filterregel abfragen.
| |
| | |
| CAP_AUDIT_READ (seit Linux 3.16)
| |
| Erlaubt das Schreiben des Audit-Protokolls über einen Multicast-Netlink-Socket
| |
| | |
| CAP_AUDIT_WRITE (seit Linux 2.6.11)
| |
| Datensätze in das Audit-Protokoll des Kernels schreiben
| |
| | |
| CAP_BLOCK_SUSPEND (seit Linux 3.5)
| |
| Funktionalitäten einsetzen, die die System-Supsendierung blockieren können
| |
| (epoll(7) EPOLLWAKEUP, /proc/sys/wake_lock).
| |
| | |
| CAP_CHOWN
| |
| beliebige Änderungen an Datei-UIDs und GIDs vornehmen (siehe chown(2))
| |
| | |
| CAP_DAC_OVERRIDE
| |
| Lese-, Schreibe und Ausführrechteprüfungen umgehen. (DAC ist die Abkürzung für
| |
| »discretionary access control«, benutzerbestimmbare Zugriffskontrolle)
| |
| | |
| CAP_DAC_READ_SEARCH
| |
| * Dateileserechteprüfungen und Verzeichnislese- und -ausführrechteprüfungen
| |
| umgehen.
| |
| * open_by_handle_at(2) aufrufen.
| |
| * Verwenden Sie den Schalter AT_EMPTY_PATH von linkat(2), um einen Link auf eine
| |
| Datei, auf die sich ein Dateideskriptor bezieht, zu erstellen.
| |
| | |
| CAP_FOWNER
| |
| * Rechteprüfungen umgehen, die normalerweise verlangen, dass die Dateisystem-UID
| |
| des Prozesses mit der UID der Datei übvereinstimmt (z.B. chmod(2), utime(2)),
| |
| hierbei sind Aktionen, die durch CAP_DAC_OVERRIDE und CAP_DAC_READ_SEARCH
| |
| abgedeckt sind, ausgeschlossen;
| |
| * Inode-Schalter für beliebige Dateien setzen (siehe ioctl_iflags(2));
| |
| * Zugriffskontrolllisten (»Access Control Lists«, ACLs) auf beliebige Dateien
| |
| setzen;
| |
| * »sticky«-Bit von Verzeichnissen beim Dateilöschen ignorieren;
| |
| * O_NOATIME für beliebige Dateien in open(2) und fcntl(2) setzen
| |
| | |
| CAP_FSETID
| |
| * Set-User-ID- und Set-Group-ID-Modus-Bits nicht zurücksetzen, wenn eine Datei
| |
| verändert wird;
| |
| * das Set-Group-ID-Bit für eine Datei setzen, deren GID nicht auf das Dateisystem-
| |
| oder eine der ergänzenden GIDs des aufrufenden Prozesses passt.
| |
| | |
| CAP_IPC_LOCK
| |
| Speicher sperren (mlock(2), mlockall(2), mmap(2), shmctl(2)).
| |
| | |
| CAP_IPC_OWNER
| |
| Rechteprüfungen für Aktionen mit System-V-IPC-Objekten umgehen
| |
| | |
| CAP_KILL
| |
| Rechteprüfungen beim Senden von Signalen umgehen (siehe kill(2)). Dies schließt die
| |
| ioctl(2)-KDSIGACCEPT-Aktion mit ein.
| |
| | |
| CAP_LEASE (seit Linux 2.4)
| |
| Etabliert Ausleihen für beliebige Dateien (siehe fcntl(2)).
| |
| | |
| CAP_LINUX_IMMUTABLE
| |
| Setzt die Inode-Schalter FS_APPEND_FL und FS_IMMUTABLE_FL (siehe ioctl_iflags(2)).
| |
| | |
| CAP_MAC_ADMIN (seit Linux 2.6.25)
| |
| MAC-Konfiguration oder Statusänderungen erlauben. Implementiert für das
| |
| Smack-Linux-Security-Modul (LSM).
| |
| | |
| CAP_MAC_OVERRIDE (seit Linux 2.6.25)
| |
| Mandatory Access Control (MAC) außer Kraft setzen. Für das Smack-LSM implementiert.
| |
| | |
| CAP_MKNOD (seit Linux 2.4)
| |
| Spezielle Dateien mittels mknod(2) erstellen.
| |
| | |
| CAP_NET_ADMIN
| |
| Verschiedene Netz-bezogene Aktionen durchführen:
| |
| * Schnittstellenkonfiguration;
| |
| * Administration von IP-Firewall, Masquerading und Abrechnung;
| |
| * Routing-Tabellen verändern;
| |
| * an beliebige Adresse für eine transparente Proxyfunktion binden;
| |
| * type-of-service (TOS) setzen
| |
| * Treiberstatistiken bereinigen;
| |
| * den »promiscuous«-Modus einschalten;
| |
| * Multicasting aktivieren;
| |
| * setsockopt(2) verwenden, um die folgenden Socket-Optionen zu setzen: SO_DEBUG,
| |
| SO_MARK, SO_PRIORITY (für eine Priorität außerhalb des Bereichs 0 bis 6),
| |
| SO_RCVBUFFORCE und SO_SNDBUFFORCE.
| |
| | |
| CAP_NET_BIND_SERVICE
| |
| Einen Socket an einen privilegierten Internet-Domain-Port binden (Portnummern
| |
| kleiner als 1024)
| |
| | |
| CAP_NET_BROADCAST
| |
| (Unbenutzt) Socket-Broadcasts durchführen und auf Multicasts warten
| |
| | |
| CAP_NET_RAW
| |
| * RAW- und PACKET-Sockets verwenden;
| |
| * an beliebige Adresse für eine transparente Proxyfunktion binden
| |
| | |
| CAP_SETGID
| |
| * Beliebige Manipulationen an den GIDs und der Liste der ergänzenden GIDs des
| |
| Prozesses vornehmen;
| |
| * GID fälschen, wenn Socket-Berechtigungsnachweise via UNIX-Domain-Sockets
| |
| weitergebeben werden;
| |
| * eine Gruppen-ID-Abbildung in einen Benutzernamensraum schreiben (siehe
| |
| user_namespaces(7)).
| |
| | |
| CAP_SETFCAP (seit Linux 2.6.24)
| |
| Setzt beliebige Capabilities auf einer Datei.
| |
| | |
| CAP_SETPCAP
| |
| Falls Datei-Capabilites unterstützt werden (d.h. seit Linux 2.6.24): Füge alle
| |
| Capabilities aus der Begrenzungsmenge des Threads zu der vererbbaren Menge hinzu;
| |
| entferne Capabilities aus der Begrenzungsmenge (via prctl(2) PR_CAPBSET_DROP);
| |
| nehme Änderungen an den securebits-Schaltern vor.
| |
| | |
| Falls Datei-Capabilites nicht unterstützt werden (d.h. Kernel vor Linux 2.6.24):
| |
| eine Capability in der erlaubten Capability-Menge oder von anderen Prozessen
| |
| entfernen oder dafür bewilligen. (Diese Eigenschaft von CAP_SETPCAP ist nicht
| |
| verfügbar, falls der Kernel für die Unterstützung von Datei-Capabilities
| |
| konfiguriert ist, da CAP_SETPCAP für diese Kernel eine komplett andere Semantik
| |
| aufweist.)
| |
| | |
| CAP_SETUID
| |
| * beliebige Manipulationen der Prozess-UIDs vornehmen (setuid(2), setreuid(2),
| |
| setresuid(2), setfsuid(2));
| |
| * UID fälschen, wenn Socket-Berechtigungsnachweise via UNIX-Domain-Sockets
| |
| weitergebeben werden;
| |
| * eine Benutzer-ID-Abbildung in einen Benutzernamensraum schreiben (siehe
| |
| user_namespaces(7)).
| |
| | |
| CAP_SYS_ADMIN
| |
| Hinweis: Diese Capability ist überladen, siehe Hinweise für Kernel-Entwickler
| |
| weiter unten.
| |
| | |
| * eine Reihe von Systemadministratoraktionen ausführen, darunter: quotactl(2),
| |
| mount(2), umount(2), swapon(2), swapoff(2), sethostname(2) und setdomainname(2);
| |
| * privilegierte syslog(2)-Aktion ausführen (seit Linux 2.6.37 sollte CAP_SYSLOG
| |
| verwandt werden, um diese Aktion zu erlauben);
| |
| * den VM86_REQUEST_IRQ-Befehl vm86(2) ausführen;
| |
| * IPC_SET- und IPC_RMID-Aktion auf beliebigen System-V-IPC-Objekten ausführen;
| |
| * RLIMIT_NPROC-Ressourcenbegrenzung außer Kraft setzen;
| |
| * Aktionen an den Erweiterten Attributen (»Extended Attributes«) trusted und
| |
| security durchführen (siehe attr(7));
| |
| * lookup_dcookie(2) verwenden;
| |
| * ioprio_set(2) verwenden, um IOPRIO_CLASS_RT und (vor Linux 2.6.25)
| |
| IOPRIO_CLASS_IDLE-E/A-Scheduling-Klassen zuzuweisen;
| |
| * PID fälschen, wenn Socket-Berechtigungsnachweise via UNIX-Domain-Sockets
| |
| weitergebeben werden;
| |
| * die systemweite Grenze der Anzahl der offenen Dateien (/proc/sys/fs/file-max) in
| |
| Systemaufrufen, die Dateien öffnen (z.B. accept(2), execve(2), open(2), pipe(2))
| |
| überschreiben;
| |
| * Schalter CLONE_* einsetzen, der neue Namensräume mit clone(2) und unshare(2)
| |
| erstellt (seit Linux 3.8 benötigt die Erzeugung von Benutzernamensräumen
| |
| allerdings keine Capability mehr);
| |
| * perf_event_open(2) aufrufen;
| |
| * auf privilegierte perf-Ereignisinformationen zugreifen;
| |
| * setns(2) aufrufen (benötigt CAP_SYS_ADMIN im Namensraum target);
| |
| * fanotify_init(2) aufrufen;
| |
| * bpf(2) aufrufen;
| |
| * privilegierte Aktionen KEYCTL_CHOWN und KEYCTL_SETPERM von keyctl(2) ausführen;
| |
| * ptrace(2) PTRACE_SECCOMP_GET_FILTER verwenden, um die Seccomp-Filter aller
| |
| verfolgten Prozesse auszugeben;
| |
| * madvise(2)-MADV_HWPOISON-Aktion ausführen;
| |
| * den TIOCSTI ioctl(2) verwenden, um Zeichen in die Eingabewarteschlange eines
| |
| Terminals, dass nicht das vom aufrufenden gesteuerte Terminal ist, einzufügen
| |
| * veralteten Systemaufruf nfsservctl(2) verwenden;
| |
| * veralteten Systemaufruf bdflush(2) verwenden;
| |
| * verschiedene privilegierte Blockgeräte-ioctl(2)-Aktion ausführen
| |
| * verschiedene privilegierte Dateisystem-ioctl(2)-Aktionen ausführen
| |
| * privilegierte ioctl(2)-Aktionen am Gerät /dev/random durchführen (siehe
| |
| random(4));
| |
| * einen seccomp(2)-Filter installieren, ohne zuerst das no_new_privs
| |
| Thread-Attribut setzen zu müssen;
| |
| * Erlauben-/Verweigern-Regeln für Gerätesteuergruppen setzen;
| |
| * ptrace(2) PTRACE_SECCOMP_GET_FILTER Aktionen einsetzen, um die Seccomp-Filter
| |
| verfolgter Prozesse auszugeben;
| |
| * die Aktion PTRACE_SETOPTIONS von ptrace(2) einsetzen, um den Seccomp-Schutz des
| |
| verfolgten Prozesses vorübergehend außer Kraft zu setzen (d.h. der Schalter
| |
| PTRACE_O_SUSPEND_SECCOMP).
| |
| * administrative Aktionen auf vielen Gerätetreibern ausführen
| |
| | |
| CAP_SYS_BOOT
| |
| reboot(2) und kexec_load(2) verwenden
| |
| | |
| CAP_SYS_CHROOT
| |
| chroot(2) verwenden
| |
| | |
| CAP_SYS_MODULE
| |
| * Kernelmodule laden und entladen (siehe init_module(2) und delete_module(2));
| |
| * in Kerneln vor 2.6.25: Capabilities aus der systemweiten
| |
| Capability-Begrenzungsmenge entfernen
| |
| | |
| CAP_SYS_NICE
| |
| * den Nice-Wert von Prozessen erhöhen (nice(2), setpriority(2)) und den Nice-Wert
| |
| von beliebigen Prozessen ändern;
| |
| * Echtzeit-Scheduling-Richtlinien zum Prozessaufruf und Scheduling-Richtlinien und
| |
| -Prioritäten für beliebige Prozesse setzen (sched_setscheduler(2),
| |
| sched_setparam(2), shed_setattr(2));
| |
| * CPU-Affinität für beliebige Prozesse setzen (sched_setaffinity(2));
| |
| * E/A-Scheduling-Klassen und -Prioritäten für beliebige Prozesse setzen
| |
| (ioprio_set(2));
| |
| * migrate_pages(2) auf beliebige Prozesse anwenden und Prozessen erlauben, auf
| |
| beliebige Knoten zu migrieren;
| |
| * move_pages(2) auf beliebige Prozesse anwenden;
| |
| * den Schalter MPOL_MF_MOVE_ALL mit mbind(2) und move_pages(2) verwenden
| |
| | |
| CAP_SYS_PACCT
| |
| acct(2) verwenden
| |
| | |
| CAP_SYS_PTRACE
| |
| * Nachverfolgen beliebiger Prozesse mittels ptrace(2)
| |
| * get_robust_list(2) auf beliebige Prozesse anwenden
| |
| * Daten vom oder zum Speicher beliebiger Prozesse mittels process_vm_readv(2) und
| |
| process_vm_writev(2) übertragen;
| |
| * Prozesse mittels kcmp(2) inspezieren
| |
| | |
| CAP_SYS_RAWIO
| |
| * E/A-Port-Aktionen ausführen (iopl(2) und ioperm(2));
| |
| * auf /proc/kcore zugreifen;
| |
| * die FIBMAP-Aktion ioctl(2) einsetzen;
| |
| * Geräte für den Zugriff auf x86-modellspezifische Register (MSRs, siehe msr(4))
| |
| öffnen;
| |
| * /proc/sys/vm/mmap_min_addr aktualisieren;
| |
| * Speichereinblendungen an Adressen unterhalb des durch /proc/sys/vm/mmap_min_addr
| |
| angegebenen Wertes erstellen;
| |
| * Dateien in /proc/bus/pci einblenden;
| |
| * /dev/mem und /dev/kmem öffnen;
| |
| * verschiedene SCSI-Geräte-Befehle ausführen;
| |
| * bestimmte Aktionen auf hpsa(4)- und cciss(4)-Geräten ausführen;
| |
| * eine Reihe von Geräte-spezifischen Aktionen auf anderen Geräten ausführen
| |
| | |
| CAP_SYS_RESOURCE
| |
| * reservierten Platz auf Ext2-Dateisystemen verwenden;
| |
| * ioctl(2)-Aufrufe ausführen, die das Journaling von Ext3 steuern;
| |
| * Platten-Quota-Begrenzungen außer Kraft setzen;
| |
| * Ressourcenbegrenzungen erhöhen (siehe setrlimit(2));
| |
| * RLIMIT_NPROC-Ressourcenbegrenzung außer Kraft setzen;
| |
| * maximale Anzahl von Konsolen bei der Konsolenzuteilung außer Kraft setzen;
| |
| * maximale Anzahl an Tastaturdefinitionen außer Kraft setzen;
| |
| * mehr als 64 Hz-Unterbrechungen von der Echtzeituhr erlauben;
| |
| * die msg_qbytes-Begrenzung für eine System-V-Nachrichtenwarteschlange über die
| |
| Grenze in /proc/sys/kernel/msgmnb anheben (siehe msgop(2) und msgctl(2));
| |
| * erlauben, die Ressourcenbegrenzung RLIMIT_NOFILE bezüglich der Anzahl der
| |
| »laufenden« Dateideskriptoren zu umgehen, wenn Dateideskriptoren an andere
| |
| Prozesse mittels UNIX-Domain-Sockets übergeben werden (siehe unix(7));
| |
| * die /proc/sys/fs/pipe-size-max-Begrenzung beim Setzen der Kapazität einer Pipe
| |
| mittels des F_SETPIPE_SZ-Befehls fcntl(2) außer Kraft setzen
| |
| * F_SETPIPE_SZ verwenden, um die Kapazität einer Pipe über die in
| |
| /proc/sys/fs/pipe-max-size angegebene Grenze erhöhen;
| |
| * die /proc/sys/fs/mqueue/queues_max-Begrenzung beim Erstellen von
| |
| POSIX-Nachrichtenwarteschlangen (siehe mq_overview(7)) außer Kraft setzen;
| |
| * die prctl(2)-Aktion PR_SET_MM einsetzen;
| |
| * /proc/[PID]/oom_score_adj auf einen Wert niedriger als den zuletzt durch einen
| |
| Prozess mit CAP_SYS_RESOURCE gesetzten Wert setzen
| |
| | |
| CAP_SYS_TIME
| |
| Systemuhr setzen (settimeofday(2), stime(2), adjtimex(2)); Echtzeit- (Hardware-)Uhr
| |
| setzen
| |
| | |
| CAP_SYS_TTY_CONFIG
| |
| vhangup(2) einsetzen; verschiedene privilegierte ioctl(2)-Aktionen auf virtuelle
| |
| Terminals einsetzen
| |
| | |
| CAP_SYSLOG (seit Linux 2.6.37)
| |
| * Privilegierte syslog(2)-Aktionen ausführen. Siehe syslog(2) für Informationen,
| |
| welche Aktionen Privilegien benötigen.
| |
| * Über /proc bereitgestellte Kernel-Adressen und andere Schnittstellen anschauen,
| |
| wenn /proc/sys/kernel/kptr_restrict den Wert 1 hat. (Lesen Sie die Diskussion
| |
| über kptr_restrict in proc(5).)
| |
| | |
| CAP_WAKE_ALARM (seit Linux 3.0)
| |
| Etwas auslösen, dass das System aufwecken wird (siehe die Zeitgeber
| |
| CLOCK_REALTIME_ALARM und CLOCK_BOOTTIME_ALARM)
| |
| | |
| Frühere und heutige Implementierungen
| |
| Eine komplette Implementierung von Capabilities verlangt folgendes:
| |
| | |
| 1. Für alle privilegierten Aktionen muss der Kernel prüfen, ob der Thread die benötigten
| |
| Capabilities in seiner effektiven Menge hat.
| |
| | |
| 2. Der Kernel muss Systemaufrufe bereitstellen, die es erlauben, dass die Capability-Menge
| |
| des Threads geändert und ermittelt wird.
| |
| | |
| 3. Das Dateisystem muss das Anhängen von Capabilities an ausführbare Dateien erlauben, so
| |
| dass ein Prozess solche Capabilities erhält, wenn die Datei ausgeführt wird.
| |
| | |
| Vor Kernel 2.6.24 waren nur die ersten zwei dieser Anforderungen erfüllt, seit Kernel
| |
| 2.6.24 sind alle drei Anforderungen erfüllt.
| |
| | |
| Hinweise für Kernel-Entwickler
| |
| Wenn Sie eine neue Kernel-Funktionalität hinzufügen, die über eine Capability geregelt
| |
| werden soll, beachten Sie die nachfolgenden Punkte.
| |
| | |
| * Das Ziel von Capabilitys besteht darin, die Macht des Systembenutzers in Teile zu
| |
| zerlegen. Wird dann ein Programm, das eine oder mehrere Capabilitys hat,
| |
| kompromittiert, dann kann weniger Schaden angerichtet werden, als wenn das Programm mit
| |
| Root-Rechten liefe.
| |
| | |
| * Sie haben die Wahl, entweder ein neues Capability für Ihre neue Funktionalität
| |
| hinzuzufügen, oder die Funktionalität einer bereits bestehenden Capability zuzuordnen.
| |
| Um die Menge der Capabilitys auf eine verwaltbare Größe zu begrenzen, wird die zweite
| |
| Variante bevorzugt, außer es gibt überzeugende Gründe, die erste Variante zu wählen.
| |
| (Es gibt auch eine technische Grenze: Die Größe der Capability-Menge ist derzeit auf 64
| |
| bit beschränkt.)
| |
| | |
| * Um zu bestimmen, zu welcher bestehenden Capability Ihre neue Funktionalität am besten
| |
| zugeordnet werden könnte, prüfen Sie die obige Liste der Capabilitys, um ein »Silo« zu
| |
| finden, in das Ihre neue Funktionalität am besten passt. Ein Vorgehen besteht darin, zu
| |
| bestimmen, ob es andere Funktionalitäten gibt, die Capabilitys benötigen, die immer
| |
| zusammen mit Ihrer neuen Funktionalität benötigt werden. Falls Ihre neue Funktionalität
| |
| ohne diese andere Funktionalität nutzlos ist, dann sollten Sie die gleiche Capability
| |
| wie die andere Funktionalität verwenden.
| |
| | |
| * Verwenden Sie nicht CAP_SYS_ADMIN, falls Sie es irgendwie vermeiden können. Ein
| |
| riesiger Anteil an bestehenden Capability-Überprüfungen ist dieser Capability
| |
| zugeordnet (siehe die Teilliste weiter oben). Sie kann glaubhaft als »der neue Root«
| |
| bezeichnet werden, da sie eine große Bandbreite an Rechten verleiht, und andererseits
| |
| bedeutet ihr großer Geltungsbereich, dass es eine Capability ist, die von vielen
| |
| privilegierten Programmen benötigt wird. Verschlimmern Sie das Problem nicht. Die
| |
| einzigen neuen Funktionalitäten, die CAP_SYS_ADMIN zugeordnet werden sollten, sind
| |
| diejenigen, die eng zu bestehenden Anwendungsfällen in diesem Silo passen.
| |
| | |
| * Falls Sie ermittelt haben, dass Sie wirklich eine neue Capability für Ihre
| |
| Funktionalität benötigen, führen Sie sie nicht als »Einzelverwendung«-Capability ein
| |
| (oder benennen Sie es so). Daher war beispielsweise die Ergänzung der hochspezifischen
| |
| CAP_SYS_PACCT wahrscheinlich ein Fehler. Versuchen Sie stattdessen, Ihre neue
| |
| Capability als ein breiteres Silo zu identifizieren und zu benennen, in das andere,
| |
| damit im Zusammenhang stehende zukünftige Anwendungsfälle passen könnten.
| |
| | |
| Capability-Mengen von Threads
| |
| Jeder Thread hat drei Capability-Mengen, die null oder mehr der oben aufgeführten
| |
| Capabilities enthalten:
| |
| | |
| Permitted (erlaubt):
| |
| Dies ist die begrenzende Übermenge für die effektiven Capabilities, die ein Thread
| |
| annehmen kann. Es ist auch die begrenzende Übermenge für die Capabilites, die zu
| |
| der vererbbaren Menge durch einen Thread hinzugefügt werden dürfen, der nicht die
| |
| Capability CAP_SETPCAP in seiner effektiven Menge hat.
| |
| | |
| Falls ein Thread eine Capability aus seiner erlaubten Menge entfernt, kann es diese
| |
| Capability niemals wiedererlangen (außer es führt ein Set-User-ID-Root-Programm mit
| |
| execve(2) aus oder ein Programm, dessen zugeordnete Datei-Capabilities diese
| |
| Capability wieder bewilligen).
| |
| | |
| Inheritable (vererbbar):
| |
| Dies ist eine Menge von Capabilities, die über execve(2) hinweg erhalten bleiben.
| |
| Vererbbare Capabilities bleiben bei der Ausführung jedes Programms vererbbar und
| |
| vererbbare Capbabilities werden zu der erlaubten Menge bei der Ausführung eines
| |
| Programms, das die entsprechenden Bits in der Datei-Vererbbaren-Menge gesetzt hat,
| |
| hinzugefügt.
| |
| | |
| Da vererbbare Capabilities im allgemeinen nicht über execve(2)-Aufrufe erhalten
| |
| werden, wenn dies nicht als Benutzer root erfolgt, sollten Anwendungen, die
| |
| Hilfsprogramme mit erhöhten Capabilities ausführen wollen, die Verwendung der unten
| |
| beschriebenen Umgebungs-Capabilities in Betracht ziehen.
| |
| | |
| Effective (effektiv):
| |
| Dies ist die Menge an Capabilities, der vom Kernel zur Durchführung von
| |
| Rechteprüfungen für den Thread verwandt wird.
| |
| | |
| Ambient (Umgebung) (seit Linux 4.3):
| |
| Dies ist eine Menge von Capabilities, die über execve(2) eines nicht privilegierten
| |
| Programms hinweg erhalten bleiben. Die Umgebungs-Capability-Menge folgt der
| |
| Invarianz, dass keine Capability jemals eine Umgebungs-Capability sein kann, falls
| |
| sie nicht sowohl erlaubt als auch vererbbar ist.
| |
| | |
| Die Umgebungs-Capability-Menge kann direkt mit prctl(2) verändert werden.
| |
| Umgebungs-Capabilities werden automatisch abgesenkt, falls entweder die
| |
| entsprechende erlaubte oder vererbbare Capability abgesenkt wird.
| |
| | |
| Wird ein Programm ausgeführt, das die UID oder GID aufgrund von set-user-ID- oder
| |
| set-group-ID-Bits ändert oder das über eine Menge an Datei-Capabilities verfügt,
| |
| dann wird die Umgebungsmenge geleert. Umgebungs-Capabilities werden zu der
| |
| erlaubten Menge hinzugefügt und der effektiven Menge zugewiesen, wenn execve(2)
| |
| aufgerufen wird.
| |
| | |
| Ein mittels fork(2) erstelltes Kind erbt Kopien der Eltern-Capability-Menge. Lesen Sie
| |
| weiter unten eine Diskussion der Behandlung von Capabilities während execve(2).
| |
| | |
| Mittels capset(2) kann ein Thread seine eigenen Capability-Mengen bearbeiten (siehe
| |
| unten).
| |
| | |
| Seit Linux 3.2 legt die Datei /proc/sys/kernel/cap_last_cap den numerischen Wert der
| |
| höchsten vom laufenden Kernel unterstützten Capability offen. Dies kann zur Bestimmung des
| |
| höchsten Bits, das in einer Capability-Gruppe gesetzt werden kann, genutzt werden.
| |
| | |
| Datei-Capabilities
| |
| Seit Kernel 2.6.24 unterstützt der Kernel die Zuordnung von Capability-Mengen zu einer
| |
| ausführbaren Datei mittels setcap(8). Die Datei-Capability-Mengen werden in erweiterten
| |
| Attributen namens security.capability gespeichert (siehe setxattr(2) und xattr(7)). Das
| |
| Schreiben in diese erweiterten Attribute benötigt die Capability CAP_SETFCAP. Die
| |
| Datei-Capability-Mengen bestimmen zusammen mit den Capability-Mengen des Threads die
| |
| Capabilities nach einem execve(2).
| |
| | |
| Die drei Datei-Capabilities-Mengen sind:
| |
| | |
| Permitted (erlaubt, früher als forced (erzwungen) bekannt):
| |
| Diese Capabilities werden dem Thread automatisch erlaubt, unabhängig von den
| |
| geerbten Capabilities des Threads.
| |
| | |
| Inheritable (vererbbar, früher als allowed (erlaubt) bekannt):
| |
| Diese Menge wird mittels AND mit der vererbbaren Menge des Threads verknüpft, um zu
| |
| bestimmen, welche vererbbaren Capabilities in der erlaubten Menge des Threads nach
| |
| einem execve(2) aktiviert werden.
| |
| | |
| Effective (effektiv):
| |
| Dies ist keine Menge, sondern eher ein einziges Bit. Falls dieses Bit gesetzt ist,
| |
| dann werden während eines execve(2) die gesamten erlaubten Capabilties für den
| |
| Thread in die effektive Menge hochgezogen. Falls dieses Bit nicht gesetzt ist, dann
| |
| wird nach einem execve(2) keine der erlaubten Capabilities in der neuen effektiven
| |
| Menge sein.
| |
| | |
| Aktivieren des effektiven Datei-Capability-Bits impliziert, dass jede erlaubte oder
| |
| vererbte Datei-Capability, die dazu führt, dass ein Thread die entsprechende
| |
| erlaubte Capability während eines execve(2) erlangt (siehe die oben beschriebenen
| |
| Transformationsregeln), auch dazu führt, dass er die Capability in seiner
| |
| effektiven Menge erlangt. Werden daher Capabilities zu einer Datei zugeweisen
| |
| ((setcap(8), cap_set_file(3), cap_set_fd(3)), falls der effektive Schalter für
| |
| irgendeine Capability aktiviert ist, dann muss der effektive Schalter auch als
| |
| aktiviert für alle anderen Capabilities, für die die entsprechenden erlaubten oder
| |
| vererbbaren Schalter aktiviert sind, spezifiziert werden.
| |
| | |
| Umwandlungen von Capabilities während execve()
| |
| Während eines execve(2) berechnet der Kernel die neuen Capabilities eines Prozesses mit
| |
| dem folgenden Algorithmus:
| |
| | |
| P'(ambient) = (Datei ist privilegiert) ? 0 : P(ambient)
| |
| | |
| P'(permitted) = (P(inheritable) & F(inheritable)) |
| |
| (F(permitted) & cap_bset) | P'(ambient)
| |
| | |
| P'(effective) = F(effective) ? P'(permitted) : P'(ambient)
| |
| | |
| P'(inheritable) = P(inheritable) [d.h. unverändert]
| |
| | |
| wobei:
| |
| | |
| P bezeichnet den Wert einer Capability-Menge des Threads vor dem execve(2)
| |
| | |
| P' bezeichnet den Wert einer Capability-Menge des Threads nach dem execve(2)
| |
| | |
| F bezeichnet eine Datei-Capability-Menge
| |
| | |
| cap_bset ist der Wert der Capability-Begrenzungsmenge (weiter unten beschrieben)
| |
| | |
| Eine privilegierte Datei verfügt über Capabilities oder hat das set-user-ID- oder
| |
| set-group-ID-Bit gesetzt.
| |
| | |
| Hinweis: Die oben beschriebenen Capability-Übergänge könnten aus den gleichen Gründen, aus
| |
| denen auch die Bits set-user-ID and set-group-ID ignorieert werden, nicht durchgeführt
| |
| werden (d.h. Datei-Capabilities könnten ignoriert werden); siehe execve(2).
| |
| | |
| Hinweis: Entsprechend den obigen Regeln werden alle Capabilities, die in der erlaubten und
| |
| effektiven Menge vorhanden sind, zurückgesetzt, falls ein Prozess mit einer von Null
| |
| verschiedenen Benutzerkennung ein execve(2) durchführt. Für die Behandlung der
| |
| Capabilities, wenn ein Prozess mit der Benutzerkennung Null ein execve(2) durchführt,
| |
| siehe unten unter Capabilities und Ausführung von Programmen durch root.
| |
| | |
| Sicherheitsprüfungen für Capability-unfähige Programme
| |
| Ein Capability-unfähiges Programm ist eine Anwendung, die für Datei-Capabilities markiert
| |
| ist, aber noch nicht für die Verwendung des libcap(3)-APIs zur Bearbeitung seiner
| |
| Capabilities konvertiert wurde. (Mit anderen Worten, dies ist ein traditionelles
| |
| »set-user-ID-root«-Programm, das auf Datei-Capabilities umgestellt wurde, aber dessen Code
| |
| nicht angepasst wurde, um mit Capabilities umzugehen.) Für solche Anwendungen wird das
| |
| effektive Capability-Bit auf die Datei gesetzt, so dass die erlaubten Capabilities
| |
| automatisch beim Ausführen der Datei in der effektiven Menge aktiviert werden. Der Kernel
| |
| erkennt für den hier beschriebenen Zweck eine Datei, die das effektive Capability-Bit
| |
| gesetzt hat, als Capability-unfähig.
| |
| | |
| Beim Ausführen eines Capability-unfähigen Programms prüft der Kernel nach den oben
| |
| beschriebenen Umwandlungen, ob der Prozess alle erlaubten Capabilities, die in der
| |
| Datei-erlaubten Menge angegeben wurden, erlangt hat. (Ein typischer Grund, warum dies
| |
| nicht passieren könnte, liegt darin, dass die Capability-Begrenzungsmenge einige der
| |
| Capabilities in der Datei-erlaubten Menge ausblenden könnte.) Falls der Prozess nicht die
| |
| komplette Menge der Datei-erlaubten Capabilities erlangte, schlägt execve(2) mit dem
| |
| Fehler EPERM fehl. Dies verhindert mögliche Sicherheitsrisiken, die daraus resultieren,
| |
| dass ein Capability-unfähiges Programm mit weniger als den benötigten Privilegien
| |
| ausgeführt wird. Beachten Sie, dass definitionsgemäß die Anwendung das Problem nicht
| |
| selbst erkennen könnte, da sie nicht das libcap(3)-API einsetzt.
| |
| | |
| Capabilities und Ausführung von Programmen durch root
| |
| Um während eines execve(2) ein allmächtigen root mit Capability-Mengen bereitzustellen:
| |
| | |
| 1. Falls ein Set-User-ID-Root-Programm ausgeführt wird oder die reale oder effektive
| |
| Benutzer-ID des Prozesses 0 (root) ist sind die vererbbaren und erlaubten Dateimengen
| |
| komplett auf nur Einsen definiert (d.h. alle Capabilities aktiviert).
| |
| | |
| 2. Falls ein Set-User-ID-Root-Programm ausgeführt wird oder die effektive Benutzer-ID des
| |
| Prozesses 0 ist (root), dann ist das effektive Datei-Bit als Eins (aktiviert)
| |
| definiert.
| |
| | |
| Das Fazit der obigen Regeln, kombiniert mit den oben beschriebenen
| |
| Capability-Umwandlungen, ist folgendes:
| |
| | |
| * Wenn ein Prozess ein Set-User-ID-Root-Programm mit execve(2) ausführt oder wenn ein
| |
| Prozess mit einer effektiven UID von 0 ein Programm mit execve ausführt, er alle
| |
| Capabilities in seinen erlaubten und effektiven Mengen erhält, außer denen, die durch
| |
| die Capability-Begrenzungsmenge maskiert sind.
| |
| | |
| * Wenn ein Prozess mit einer echten UID von 0 ein Programm mit execve(2) ausführt, erhält
| |
| es alle Capabilities in seiner erlaubten Capability-Menge, außer denen, die durch die
| |
| Capability-Begrenzungsmenge maskiert sind.
| |
| | |
| Die obigen Schritte ergeben eine Semantik, die identisch zu der von traditionellen
| |
| UNIX-Systemen ist.
| |
| | |
| Set-user-ID-root-Programme die Datei-Capabilities haben
| |
| Wird ein Programm ausgeführt, das sowohl set-user-ID-Root ist als auch über
| |
| Datei-Capabilities verfügt, führt dies dazu, dass der Prozess nur die durch das Programm
| |
| eingeräumten Capabilities erlangt (d.h. nicht alle Capabilities, was passierte, wenn ein
| |
| set-user-ID-Root-Programm ausgeführt würde, das keine zugeordneten Datei-Capabilities
| |
| hat). Beachten Sie, dass einem Programm eine leere Capability-Menge zugeordnet werden kann
| |
| und es daher möglich ist, ein set-user-ID-root-Programm zu erstellen, das die effektive
| |
| und die gespeicherte set-user-ID des Progresses, der das Programm ausführt, auf 0 setzt,
| |
| aber dem Prozess keine Capabilities gewährt.
| |
| | |
| Capability-Begrenzungsmenge
| |
| Die Capability-Begrenzungsmenge ist ein Sicherheitsmechanismus, der zur Begrenzung der
| |
| Capabilities, die während eines execve(2) erlangt werden können, dienen kann. Die
| |
| Begrenzungsmenge wird auf die folgende Art und Weise benutzt:
| |
| | |
| * Während eines execve(2) wird die Capability-Begrenzungsmenge mittels AND mit der
| |
| erlaubten Datei-Capability-Menge verknüpft und das Ergebnis dieser Aktion wird der
| |
| erlaubten Capability-Menge des Threads zugewiesen. Die Capability-Begrenzungsmenge
| |
| stellt daher eine Grenze für die erlaubten Capabilities dar, die einer ausführbaren
| |
| Datei erlaubt werden dürfen.
| |
| | |
| * (Seit Linux 2.6.25) Die Capability-Begrenzungsmenge agiert als begrenzende Übermenge für
| |
| die Capabilities, die ein Thread zu seiner vererbbaren Menge mittels capset(2)
| |
| hinzufügen kann. Das bedeutet, dass ein Thread eine Capability nicht zu seiner
| |
| vererbbaren Menge hinzufügen kann, falls es nicht in der Begrenzungsmenge enthalten ist,
| |
| selbst falls es in seinen erlaubten Capabilities vorhanden ist, wenn er eine Datei mit
| |
| execve(2) ausführt, die diese Capability in seiner vererbbaren Menge hat.
| |
| | |
| Beachten Sie, dass die Begrenzungsmenge die erlaubten Datei-Capabilities maskiert, aber
| |
| nicht die vererbbaren Capabilities. Falls ein Thread eine Capability in seiner vererbbaren
| |
| Menge betreut, die nicht in seiner Begrenzungsmenge ist, dann kann er weiterhin die
| |
| Capability in seiner erlaubten Menge erlangen, indem er eine Datei ausführt, die diese
| |
| Capability in seiner vererbbaren Menge enthält.
| |
| | |
| Abhängig von der Kernelversion ist die Capability-Begrenzungsmenge entweder ein
| |
| systemweites Attribut oder ein prozessweises Attribut.
| |
| | |
| Capability-Begrenzungsmenge vor Linux 2.6.25
| |
| | |
| In Kerneln vor 2.6.25 ist die Capability-Begrenzungsmenge ein systemweites Attribut, das
| |
| alle Threads auf dem System betrifft. Auf die Begrenzungsmenge kann über die Datei
| |
| /proc/sys/kernel/cap-bound zugegriffen werden. (Zur Erhöhung der Konfusion wird dieser
| |
| Bitmaskenparameter als vorzeichenbehaftete Dezimalzahl in /proc/sys/kernel/cap-bound
| |
| ausgedrückt.)
| |
| | |
| Nur der init-Prozess darf Capabilities in der Capability-Begrenzungsmenge setzen;
| |
| abgesehen davon kann der Superuser (oder genauer: ein Prozess mit der Capability
| |
| CAP_SYS_MODULE) nur Capabilities aus dieser Menge entfernen.
| |
| | |
| Auf einem Standardsystem maskiert die Capability-Begrenzungsmenge immer die Capability
| |
| CAP_SETPCAP. Um diese Einschränkung zu entfernen (gefährlich!), verändern Sie die
| |
| Definition von CAP_INIT_EFF_SET in include/linux/capability.h und bauen Ihren Kernel neu.
| |
| | |
| Die systemweite Capability-Begrenzungsmengenfunktion wurde Linux in Version 2.2.11
| |
| hinzugefügt.
| |
| | |
| Capability-Begrenzungsmenge seit Linux 2.6.25
| |
| | |
| Seit Linux 2.6.25 ist die Capability-Begrenzungsmenge ein pro-Thread-Attribut. (Es gibt
| |
| keine systemweite Capability-Begrenzungsmenge mehr.)
| |
| | |
| Die Begrenzungsmenge wird bei fork(2) von dem Elternprozess des Threads vererbt und bleibt
| |
| über ein execve(2) erhalten.
| |
| | |
| Ein Thread kann mittels der Aktion prctl(2) PR_CAPBSET_DROP Capabilities aus seiner
| |
| Begrenzungsmenge entfernen, vorausgesetzt er verfügt über die Capability CAP_SETPCAP.
| |
| Sobald eine Capability aus der Begrenzungsmenge entfernt wurde, kann sie nicht mehr zu der
| |
| Menge wieder hinzugefügt werden. Ein Thread kann mittels der Aktion prctl(2)
| |
| PR_CAPBSET_READ herausfinden, ob eine Capability in seiner Begrenzungsmenge liegt.
| |
| | |
| Entfernen von Capabilities aus der Begrenzungsmenge ist nur möglich, falls
| |
| Datei-Capabilities in den Kernel kompiliert wurden. In Kerneln vor Linux 2.6.33 waren
| |
| Datei-Capabilities eine optionale Funktionalität, die mittels der Option
| |
| CONFIG_SECURITY_FILE_CAPABILITIES konfigurierbar war. Seit Linux 2.6.33 ist die
| |
| Konfigurationsoption entfernt und Datei-Capabilities sind immer Teil des Kernels. Wenn
| |
| Datei-Capabilities in den Kernel kompiliert sind, beginnt der init-Prozess (der Urahn
| |
| aller Prozesse) mit einer kompletten Begrenzungsmenge. Falls Datei-Capabilities nicht in
| |
| den Kernel kompiliert sind, dann beginnt init mit einer vollständigen Begrenzungsmenge
| |
| ohne CAP_SETPCAP, da diese Capability eine andere Bedeutung hat, wenn es keine
| |
| Datei-Capabilities gibt.
| |
| | |
| Die Entfernung einer Capability aus der Begrenzungsmenge entfernt sie nicht aus der
| |
| vererbbaren Menge des Threads. Allerdings verhindert es das Zurückfügen in die vererbbare
| |
| Menge des Threads in der Zukunft.
| |
| | |
| Effekt von Benutzer-ID-Änderungen auf Capabilities
| |
| Um die traditionellen Semantiken für Übergänge zwischen 0 und von 0 verschiedenen IDs zu
| |
| erhalten, führt der Kernel folgende Änderungen an den Capability-Mengen eines Threads bei
| |
| Änderung der echten, effektiven, gespeicherten und Dateisystem-Benutzer-ID (unter
| |
| Verwendung von setuid(2), setresuid(2) oder ähnlich) durch:
| |
| | |
| 1. Falls einer der realen, effektiven oder gespeicherten Set-User-IDs vorher 0 war und als
| |
| Ergebnis der UID-Änderung alle dieser IDs eine von 0 verschiedenen Wert haben, dann
| |
| werden alle Capabilities aus den erlaubten, effektiven und Umgebungs-Capability-Mengen
| |
| gelöscht.
| |
| | |
| 2. Falls die effektive Benutzer-ID von 0 auf einen von 0 verschiedenen Wert geändert wird,
| |
| werden alle Capabilities aus der effektiven Menge gelöscht.
| |
| | |
| 3. Falls die effektive Benutzer-ID von einem von 0 verschiedenen Wert auf 0 geändert wird,
| |
| dann wird die erlaubte Menge in die effektive Menge kopiert.
| |
| | |
| 4. Falls die Dateisystem-Benutzer-ID von 0 auf einen anderen Wert geändert wird (siehe
| |
| setfsuid(2)), dann werden die folgenden Capabilities aus der effektiven Menge entfernt:
| |
| CAP_CHOWN, CAP_DAC_OVERRIDE, CAP_DAC_READ_SEARCH, CAP_FOWNER, CAP_FSETID,
| |
| CAP_LINUX_IMMUTABLE (seit Linux 2.6.30), CAP_MAC_OVERRIDE und CAP_MKNOD (seit Linux
| |
| 2.6.30). Falls die Dateisystem-UID von einem von 0 verschiedenen Wert auf 0 geändert
| |
| wird, dann werden alle dieser Capabilities, die in der erlaubten Menge aktiviert waren,
| |
| in der effektiven Menge aktiviert.
| |
| | |
| Falls ein Thread, der einen Wert 0 für mindestens eine seiner Benutzer-IDs hat, verhindern
| |
| möchte, dass seine erlaubte Capability-Menge bereinigt wird, wenn er alle seine
| |
| Benutzer-IDs auf einen von 0 verschiedenen Wert setzt, kann er dies mittels der unten
| |
| beschriebenen SECBIT_KEEP_CAPS-Securebits-Schaltern erreichen.
| |
| | |
| Programmatische Anpassung von Capability-Mengen
| |
| Ein Thread kann seine Capability-Mengen mittels der Systemaufrufe capget(2) und capset(2)
| |
| ermitteln und ändern. Allerdings werden für diesen Zweck die Verwendung von
| |
| cap_get_proc(3) und cap_set_proc(3), beide im Paket libcap bereitgestellt, empfohlen. Die
| |
| folgenden Regeln bestimmen die Änderungen an den Capability-Mengen des Threads:
| |
| | |
| 1. Falls der Aufrufende nicht über die Capability CAP_SETPCAP verfügt, dann muss die neue
| |
| vererbbare Menge eine Teilmenge der Kombination der bestehenden vererbbaren und
| |
| erlaubten Menge sein.
| |
| | |
| 2. (Seit Linux 2.6.25) Die neue vererbbare Menge muss eine Teilmenge der Kombination der
| |
| bestehenden vererbbaren Menge und der Capability-Begrenzungsmenge sein.
| |
| | |
| 3. Die neue erlaubte Menge muss eine Teilmenge der bestehenden erlaubten Menge sein (d.h.
| |
| es ist nicht möglich, erlaubte Capabilities zu erlangen, die der Thread derzeit nicht
| |
| hat).
| |
| | |
| 4. Die neue effektive Menge muss eine Teilmenge der neuen erlaubten Menge sein.
| |
| | |
| Der Schalter securebits: eine reine Capability-Umgebung einrichten
| |
| Beginnend mit Kernel 2.6.26 und mit einem Kernel, in dem Datei-Capabilities aktiviert
| |
| sind, implementiert Linux eine Menge von pro-Thread-securebits-Schaltern, die zur
| |
| Deaktivierung von spezieller Handhabung von Capabilities für UID 0 (root) verwandt werden
| |
| können. Dies sind die folgenden Schalter:
| |
| | |
| SECBIT_KEEP_CAPS
| |
| Durch Setzen dieses Schalters darf ein Thread, der mindestens eine 0 UID hat,
| |
| Capabilities in seiner erlaubten und effektiven Menge behalten, wenn er alle UIDs
| |
| auf von 0 verschiedene Werte umschaltet. Falls dieser Schalter nicht gesetzt ist,
| |
| dann führt das Umschalten der UIDs dazu, dass er alle Capabilities in diesen Mengen
| |
| verliert. Dieser Schalter wird bei execve(2) immer bereinigt.
| |
| | |
| Die Einstellung des Schalters SECBIT_KEEP_CAPS wird ignoriert, falls der Schalter
| |
| SECBIT_NO_SETUID_FIXUP gesetzt ist. (Letzterer Schalter stellt eine Übermenge des
| |
| Effekts des ersteren Schalters bereit.)
| |
| | |
| Dieser Schalter stellt die gleiche Funktionalität wie die ältere Aktion prctl(2)
| |
| PR_SET_KEEPCAPS bereit.
| |
| | |
| SECBIT_NO_SETUID_FIXUP
| |
| Setzen dieses Schalters hindert den Kernel daran, die erlaubten, effektiven und
| |
| Umgebungs-Capability-Mengen des Prozesses anzupassen, wenn die effektive und die
| |
| Dateisystem-UID eines Threads zwischen null und von null verschiedenen Werten
| |
| umgeschaltet werden. (Lesen Sie den Abschnitt Effekt von Benutzer-ID-Änderungen auf
| |
| Capabilities)
| |
| | |
| SECBIT_NOROOT
| |
| Falls dieses Bit gesetzt ist, dann verleiht der Kernel keine Capabilities, wenn ein
| |
| Set-User-ID-Root-Programm ausgeführt wird oder wenn ein Prozess mit einer
| |
| effektiven oder realen UID von 0 execve(2) aufruft. (Lesen Sie den Abschnitt
| |
| Capabilities und Ausführung von Programmen durch root)
| |
| | |
| SECBIT_NO_CAP_AMBIENT_RAISE
| |
| Durch Setzen dieses Schalters dürfen keine Umgebungs-Capabilities mit der
| |
| prctl(2)-Aktion PR_CAP_AMBIENT_RAISE gehoben werden.
| |
| | |
| Jeder der obigen »basis«-Schalter hat einen begleitenden »gesperrten« Schalter. Das Setzen
| |
| eines »gesperrten« Schalters ist unumkehrbar und hat den Effekt, dass weitere Änderungen
| |
| an dem entsprechenden Basisschalter nicht mehr möglich sind. Die gesperrten Schalter sind:
| |
| SECBIT_KEEP_CAPS_LOCKED, SECBIT_NO_SETUID_FIXUP_LOCKED, SECBIT_NOROOT_LOCKED und
| |
| SECBIT_NO_CAP_AMBIENT_RAISE_LOCKED.
| |
| | |
| Die Schalter securebits können mit den Aktionen prctl(2) PR_SET_SECUREBITS und
| |
| PR_GET_SECUREBITS geändert und abgefragt werden. Die Capability CAP_SETPCAP wird für die
| |
| Veränderung der Schalter benötigt.
| |
| | |
| Die Schalter securebits werden von Kindprozessen vererbt. Während eines execve(2) werden
| |
| alle Schalter beibehalten, außer SECBIT_KEEP_CAPS, das immer bereinigt wird.
| |
| | |
| Eine Anwendung kann den folgenden Aufruf verwenden, um sich selbst und alle seine
| |
| Abkömmlinge in eine Umgebung zu sperren, in der die einzige Möglichkeit, Capabilities zu
| |
| erlangen, darin besteht, ein Programm auzuführen, das über die zugeordneten
| |
| Datei-Capabilities verfügt:
| |
| | |
| prctl(PR_SET_SECUREBITS,
| |
| /* SECBIT_KEEP_CAPS off */
| |
| SECBIT_KEEP_CAPS_LOCKED |
| |
| SECBIT_NO_SETUID_FIXUP |
| |
| SECBIT_NO_SETUID_FIXUP_LOCKED |
| |
| SECBIT_NOROOT |
| |
| SECBIT_NOROOT_LOCKED);
| |
| /* Setzen/Sperren von SECBIT_NO_CAP_AMBIENT_RAISE
| |
| ist nicht erforderlich */
| |
| | |
| Interaktion mit Benutzer-Namensräumen
| |
| Für eine Diskussion der Interaktion von Capabilities und Benutzer-Namensräumen lesen Sie
| |
| user_namespaces(7).
| |
| | |
| KONFORM ZU
| |
| Keine Standards regeln Capabilities; die Linux-Capability-Implementierung basiert aber auf
| |
| dem zurückgezogenen POSIX.1e-Entwurfsstandard; siehe ⟨http://wt.tuxomania.net/publications
| |
| /posix.1e/⟩
| |
| | |
| ANMERKUNGEN
| |
| Von Kernel 2.5.27 bis Kernel 2.6.26 waren Capabilities eine optionale Kernelkomponente,
| |
| die über die Kernelkonfigurationsoption CONFIG_SECURITY_CAPABILITIES aktiviert/deaktiviert
| |
| werden könnte.
| |
| | |
| Die Datei /proc/[PID]/task/TID/status kann zum Betrachten der Capability-Mengen eines
| |
| Threads verwandt werden. Die Datei /proc/[PID]/status zeigt die Capability-Mengen des
| |
| Haupt-Threads eines Prozesses. Vor Linux 3.8 wurden nicht existierende Capabilities in
| |
| diesen Mengen als aktiviert (1) angezeigt. Seit Linux 3.8 werden alle nicht existierenden
| |
| Capabilities (über CAP_LAST_CAP) als deaktiviert (0) angezeigt.
| |
| | |
| Das Paket libcap stellt eine Suite von Routinen zum Setzen und Abfragen von Capabilities
| |
| bereit, die komfortablere und änderungsstabilere Schnittstellen als die von capset(2) und
| |
| capget(2) bereitstellen. Dieses Paket stellt auch die Programme setcap(8) und getcap(8)
| |
| zur Verfügung. Es kann unter folgender Adresse gefunden werden:
| |
| ⟨http://www.kernel.org/pub/linux/libs/security/linux-privs⟩
| |
| | |
| Vor Kernel 2.6.24 und von Kernel 2.6.24 bis Kernel 2.6.32, falls Datei-Capabilities nicht
| |
| aktiviert sind, kann ein Thread mit der Capability CAP_SETPCAP die Capabilities von
| |
| anderen Threads manipulieren. Allerdings ist dies nur theoretisch möglich, da kein Thread
| |
| jemals über CAP_SETPCAP in einem der folgenden Fälle verfügt:
| |
| | |
| * In der pre-2.6.25-Implementierung maskiert die systemweite Capability-Begrenzungsmenge
| |
| /proc/sys/kernel/cap-bound diese Capability immer und dies kann ohne Veränderung der
| |
| Kernelquellen und dessen Neubau nicht geändert werden.
| |
| | |
| * Falls Datei-Capabilities in der aktuellen Implementierung deaktiviert sind, dann startet
| |
| init derart, dass diese Capability aus seiner prozessweisen Begrenzungsmenge entfernt
| |
| ist und dass die Begrenzungsmenge von allen anderen im System erstellten Prozessen
| |
| vererbt wird.
| |
| | |
| SIEHE AUCH
| |
| capsh(1), setpriv(1), prctl(2), setfsuid(2), cap_clear(3), cap_copy_ext(3),
| |
| cap_from_text(3), cap_get_file(3), cap_get_proc(3), cap_init(3), capgetp(3), capsetp(3),
| |
| libcap(3), proc(5), credentials(7), pthreads(7), user_namespaces(7), captest(8),
| |
| filecap(8), getcap(8), netcap(8), pscap(8), setcap(8)
| |
| | |
| include/linux/capability.h in dem Linux-Kernelquellbaum
| |
| | |
| KOLOPHON
| |
| Diese Seite ist Teil der Veröffentlichung 4.15 des Projekts Linux-man-pages. Eine
| |
| Beschreibung des Projekts, Informationen, wie Fehler gemeldet werden können sowie die
| |
| aktuelle Version dieser Seite finden sich unter https://www.kernel.org/doc/man-pages/.
| |
| | |
| ÜBERSETZUNG
| |
| Die deutsche Übersetzung dieser Handbuchseite wurde von FIXME: Einheitliche Übersetzung
| |
| von Transformation, Helge Kreutzmann <debian@helgefjell.de> und Dr. Tobias Quathamer
| |
| <toddy@debian.org> erstellt.
| |
| | |
| Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License
| |
| Version 3 oder neuer bezüglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG
| |
| übernommen.
| |
| | |
| Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-
| |
| Mail an <debian-l10n-german@lists.debian.org>.
| |