BEZEICHNUNG¶
capabilities - Überblick über Linux-Capabilities
BESCHREIBUNG¶
Für den Zweck der Durchführung von Rechteprüfungen unterscheiden
traditionelle UNIX-Implementierungen zwei Arten von Prozessen:
Privilegierte Prozesse (deren effektive Benutzer-ID 0 ist, auch als
Superuser oder Root benannt) und
unprivilegierte Prozesse (deren
effektive UID von Null verschieden ist). Privilegierte Prozesse übergehen
alle Kernel-Rechteprüfungen, während unprivilegierte Prozesse der
vollen Rechteprüfung, basierend auf den Berechtigungsnachweisen des
Prozesses (normalerweise: effektive UID, effektive GID und ergänzende
Gruppenliste), unterliegen.
Beginnend mit Kernel 2.2 unterteilt Linux die Privilegien, die traditionell mit
dem Superuser assoziiert sind, in getrennte Einheiten, die als
Capabilities bekannt sind. Diese können unabhängig
voneinander aktiviert oder deaktiviert werden. Capabilities sind ein Attribut
pro Thread.
Liste der Capabilities¶
Die folgende Liste zeigt die in Linux implementierten Capabilities und die
Operationen 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_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.
- 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
Operationen, die durch CAP_DAC_OVERRIDE und
CAP_DAC_READ_SEARCH abgedeckt sind, ausgeschlossen;
- *
- erweiterte Dateiattribute für beliebige Dateien setzen
(siehe chattr(1));
- *
- 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-Rechte-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 Operationen 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-Operation mit ein.
- CAP_LEASE (seit Linux 2.4)
- Etabliert ein Leasing für beliebige Dateien (siehe
fcntl(2)).
- CAP_LINUX_IMMUTABLE
- Setzt die i-node-Schalter FS_APPEND_FL und
FS_IMMUTABLE_FL (siehe chattr(1)).
- CAP_MAC_ADMIN (seit Linux 2.6.25)
- Mandatory Access Control (MAC) außer Kraft setzen.
Für das Smack-Linux-Sicherheitsmodul (LSM) implementiert.
- CAP_MAC_OVERRIDE (seit Linux 2.6.25)
- MAC-Konfiguration oder Statusänderungen erlauben.
Implementiert für das Smack-LSM
- CAP_MKNOD (seit Linux 2.4)
- Spezielle Dateien mittels mknod(2) erstellen.
- CAP_NET_ADMIN
- Verschiedene Netz-bezogene Operationen
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 Änderungen an Prozess-GIDs und der
ergänzenden GID-Liste vornehmen; GID fälschen, wenn
Socket-Berechtigungsnachweise via UNIX-Domain-Sockets weitergegeben
werden
- CAP_SETFCAP (seit Linux 2.6.24)
- Datei-Capabilities setzen
- CAP_SETPCAP
- Falls Datei-Capabilites nicht unterstützt werden: 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.)
Falls Datei-Capabilites unterstützt werden: 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.
- CAP_SETUID
- beliebige Manipulationen der Prozess-UIDs vornehmen
(setuid(2), setreuid(2), setresuid(2),
setfsuid(2)); gefälschte UIDs erstellen, wenn
Socket-Berechtigungsnachweise via UNIX-Domain-Sockets weitergegeben
werden
- CAP_SYS_ADMIN
- *
- eine Reihe von Systemadministratoroperationen
ausführen, darunter: quotactl(2), mount(2),
umount(2), swapon(2), swapoff(2),
sethostname(2) und setdomainname(2);
- *
- privilegierte syslog(2)-Operationen ausführen
(seit Linux 2.6.37 sollte CAP_SYSLOG verwandt werden, um diese
Operationen zu erlauben);
- *
- den VM86_REQUEST_IRQ-Befehl vm86(2)
ausführen;
- *
- IPC_SET- und IPC_RMID-Operationen auf
beliebigen System-V-IPC-Objekten ausführen;
- *
- Operationen an den Erweiterten Attributen (»Extended
Attributes«) trusted und security durchführen
(siehe attr(5));
- *
- 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;
- *
- UID fälschen, wenn Socket-Berechtigungsnachweise
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;
- *
- perf_event_open(2) aufrufen;
- *
- auf privilegierte perf-Ereignisinformationen
zugreifen;
- *
- setns(2) aufrufen;
- *
- fanotify_init(2) aufrufen;
- *
- KEYCTL_CHOWN- und
KEYCTL_SETPERM-keyctl(2)-Operationen ausführen;
- *
- madvise(2)-MADV_HWPOISON-Operationen
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)-Operationen ausführen
- *
- verschiedene privilegierte
Dateisystem-ioctl(2)-Operationen ausführen
- *
- administrative Operationen 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
- CAP_SYS_PACCT
- acct(2) verwenden
- CAP_SYS_PTRACE
- Beliebige Prozesse mittels ptrace(2) verfolgen;
get_robust_list(2) auf beliebige Prozesse anwenden
- CAP_SYS_RAWIO
- E/A-Port-Operationen ausführen (iopl(2) und
ioperm(2)); auf /proc/kcore zugreifen; die
FIBMAP-Operation ioctl(2) einsetzen
- 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));
- *
- 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;
- *
- prctl(2)-Operation PR_SET_MM einsetzen.
- 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)-Operationen auf virtuelle Terminals einsetzen
- CAP_SYSLOG (seit Linux 2.6.37)
- Privilegierte syslog(2)-Operationen ausführen.
Siehe syslog(2) für Informationen, welche Operationen
Privilegien benötigen.
- 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 privilegierte Operationen 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.
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. Es stellt ein Mechanismus
für Prozesse dar, Capabilities zur erlaubten Menge von neuen
Programmen während eines execve(2) zuzuweisen.
- Effective (effektiv):
- Dies ist die Menge an Capabilities, der vom Kernel zur
Durchführung von Rechteprüfungen für den Thread verwandt
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).
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)). 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'(permitted) = (P(inheritable) & F(inheritable)) |
(F(permitted) & cap_bset)
P'(effective) = F(effective) ? P'(permitted) : 0
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 nach dem
execve(2)
- F
- bezeichnet einen Datei-Capability-Menge
- cap_bset
- ist der Wert der Capability-Begrenzungsmenge (weiter unten
beschrieben)
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 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,
dann ist das effektive Datei-Bit als Eins (aktiviert) definiert.
Das Fazit der oben aufgeführten Regeln, kombiniert mit den beschriebenen
Capabilities-Umwandlungen, ist, dass 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. Damit wird eine Semantik bereitgestellt, die identisch zu der
von traditionellen UNIX-Sytemen ist.
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 Operation
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 vererbten Capabilities. Falls ein Thread eine
Capability in seiner vererbten 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 vererbten 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: Programme 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) vom Vater des Threads vererbt und
über ein
execve(2) erhalten.
Ein Thread kann mittels der Operation
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 Operation
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 vererbten Menge des Threads. Allerdings verhindert es das
Zurückfügen in die vererbte 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 und effektiven 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.2.30), CAP_MAC_OVERRIDE und CAP_MKNOD (seit Linux
2.2.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 Operation
prctl(2)
PR_SET_KEEPCAPS 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 Kernel 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, seine Capabilities behalten, wenn er alle UIDs
auf einen von 0 verschiedenen Wert umschaltet. Falls dieser Schalter nicht
gesetzt ist, dann führt das Umschalten der UIDs dazu, dass er alle
Capabilities verliert. Dieser Schalter wird bei execve(2) immer
bereinigt. (Dieser Schalter stellt die gleiche Funktionalität wie die
ältere Operation prctl(2) PR_SET_KEEPCAPS bereit.)
- SECBIT_NO_SETUID_FIXUP
- Setzen dieses Schalters hindert den Kernel daran, die
Capability-Mengen 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)
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 und
SECBIT_NOROOT_LOCKED.
Die Schalter
securebits können mit den Operationen
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_LOCKED |
SECBIT_NO_SETUID_FIXUP |
SECBIT_NO_SETUID_FIXUP_LOCKED |
SECBIT_NOROOT |
SECBIT_NOROOT_LOCKED);
Keine Standards regeln Capabilities; die Linux-Capability-Implementierung
basiert aber auf dem zurückgezogenen POSIX.1e-Entwurfsstandard; siehe
http://wt.xpilot.org/publications/posix.1e/
ANMERKUNGEN¶
Seit Kernel 2.5.27 sind Capabilities eine optionale Kernelkomponente, die
über die Kernelkonfigurationsoption CONFIG_SECURITY_CAPABILITIES
aktiviert/deaktiviert werden kann.
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.
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 seit Kernel 2.6.24, 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¶
capget(2),
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),
credentials(7),
pthreads(7),
getcap(8),
setcap(8)
Kommentare zum Zweck verschiedener Capabilities in
include/linux/capability.h in den Kernelquellen
KOLOPHON¶
Diese Seite ist Teil der Veröffentlichung 3.42 des Projekts Linux-
man-pages. Eine Beschreibung des Projekts und Informationen, wie Fehler
gemeldet werden können, finden sich unter
http://www.kernel.org/doc/man-pages/.
ÜBERSETZUNG¶
Die deutsche Übersetzung dieser Handbuchseite wurde von Helge Kreutzmann
<debian@helgefjell.de> 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>.