Zu viel Root tut nicht gut. Aus diesem Grund führten die Kernel-Entwickler mit Version 2.6.24 die Posix-File-Capabilities ein. Dieser Artikel erklärt, wozu diese gut sind.
Ich bin Root, ich darf das! So lautet einer der Lieblingssprüche von Linux-Nutzern auf T-Shirts, Kaffeetassen und anderen Fanartikeln. In der Tat verfügt Linux über ein relativ einfaches Rechtemanagement: Es gibt Root, den Benutzer und “die Anderen” sowie Rechte zum Lesen, Schreiben und Ausführen. Zugriffe kontrolliert das System über eine relativ einfache Matrix dieser Berechtigungen, und root darf immer alles.
Das Setuid-Bit
Es gibt allerdings Programme, die weitergehende Rechte benötigen, als sie einem durchschnittlichen Benutzer zustehen. Dazu zählen etwa der passwd-Befehl, der die Passwörter in der Datei /etc/shadow (oder /etc/passwd) ändert, oder der ping-Befehl, mit dem man die Netzwerkkarte eines anderen Rechners anspricht. Traditionellerweise verleiht der Systemadministrator solchen Tools über chmod u+s das Setuid-Bit. Das führt dazu, dass das Programm mit den Rechten des Benutzers arbeitet, dem die Datei gehört – normalerweise arbeiten Programme mit den Rechten des Ausführenden. Manche Programme kommen von Haus aus mit gesetztem S-Bit, je nach Distribution.
Die Wirkungsweise des S-Bits lässt sich an einem kleinen Beispiel leicht nachvollziehen. Geben Sie dazu in einem Terminal den Befehl su - Benutzername ein:
marcel@kim:~ $ su - marcel Passwort:
Rufen Sie nun in einem zweiten Terminalfenster den Befehl ps -au | grep su auf, so sehen Sie, dass der su-Befehl vom Benutzer root ausgeführt wurde. Während es beim su-Befehl noch relativ offensichtlich erscheint, warum er spezielle oder gar Root-Rechte benötigt, sieht es zum Beispiel bei ping ganz anders aus. Eigentlich würde es genügen, dem Ping-Befehl den Zugriff auf die entsprechenden Netzwerk-Socket zu gewähren – das ist aber mit traditionellen Unix-Rechten nicht möglich. Abhilfe schaffen die Posix-File-Capabilities.
Rechte minimieren
Die Posix-File-Capabilities bilden einen Teil der allgemeinen Posix-Capabilities [1]. Sie teilen die möglichen Berechtigungen in verschiedene Rechtebereiche (Capabilities) auf, die zusammen die Rechte des Administrators Root ergeben. Zurzeit gibt es 33 solcher Rechtebereiche, die Tabelle “Posix-Capabilities” gibt einen kurzen Überblick. Während die grundlegenden Capabilities bereits seit Kernel 2.2 Bestandteil von Linux sind, beherrscht Linux die File-Capabilities erst seit Version 2.6.24. Detaillierte Informationen zu den einzelnen Fähigkeiten finden sich in der Datei /usr/include/linux/capability.h
Auch bei den Posix-Access-Control-Listen (ACLs), die eine feingliedrige Rechteverteilung auf Verzeichnisse und Dateien ermöglichen, handelt es sich im weiteren Sinn um Posix-Capabilities; sie werden als erweiterte Attribute im Dateisystem abgelegt. Für den Einsatz von Posix-ACLs und File-Capabilities muss das Dateisystem deshalb mit der Option user_xattr eingehängt sein.
Posix-Capabilities
| Nummer | Name | Erklärung |
|---|---|---|
| 0 | CAP_CHOWN |
Eigentümer von Files beliebig setzen |
| 1 | CAP_DAC_OVERRIDE |
Sich über Dateizugriffsrechte hinwegsetzen (DAC, Discretionary Access Control), nur das Immutable-Flag ist davon nicht betroffen |
| 2 | CAP_DAC_READ_SEARCH |
In allen Files und Verzeichnissen lesen |
| 3 | CAP_FOWNER |
Auf alle Files die Funktionen ausüben, die üblicherweise nur deren Eigentümern gestattet sind (etwa chmod() und utime()) |
| 4 | CAP_FSETID |
Set-UID-Flag auch für fremde Files setzen |
| 5 | CAP_KILL |
Beliebigen Prozessen Signale senden |
| 6 | CAP_SETGID |
Beliebige Gruppen-ID annehmen |
| 7 | CAP_SETUID |
Beliebige User-ID annehmen |
| 8 | CAP_SETPCAP |
Eigene Capabilities an fremde Prozesse übertragen oder dort entfernen |
| 9 | CAP_LINUX_IMMUTABLE |
Immutable- und Append-Only-Attribute ändern |
| 10 | CAP_NET_BIND_SERVICE |
Privilegierte Ports verwenden |
| 11 | CAP_NET_BROADCAST |
Broadcast-Nachrichten senden und empfangen |
| 12 | CAP_NET_ADMIN |
Sammlung vieler Netzwerk-Konfigurationen (Interface, Firewall, Routing, Sockets, Promiscuous Mode setzen u.a.m..) |
| 13 | CAP_NET_RAW |
Sockets vom Typ Raw (IPv4-Pakete) und Packet (Ethernet-Frames) verwenden |
| 14 | CAP_IPC_LOCK |
Shared-Memory-Segmente sperren |
| 15 | CAP_IPC_OWNER |
Nachrichten per IPC (Interprozesskommunikation) an beliebige Prozesse senden |
| 16 | CAP_SYS_MODULE |
Kernel-Module laden und entladen, den Kernel beliebig ändern sowie Capabilities-Bounding-Sets ändern |
| 17 | CAP_SYS_RAWIO |
Verwenden von ioperm() und iopl() sowie beliebige USB-Kommunikation |
| 18 | CAP_SYS_CHROOT |
chroot()-Kommando absetzen |
| 19 | CAP_SYS_PTRACE |
Beliebige Prozesse mit ptrace() überwachen und kontrollieren |
| 20 | CAP_SYS_PACCT |
Prozess-Accounting konfigurieren |
| 21 | CAP_SYS_ADMIN |
Viele administrative Aufgaben, etwa Domain- und Hostnamen ändern, Dateisysteme ein- und aushängen, Swapping ein/<0x200B>ausschalten, Semaphore löschen uvm. |
| 22 | CAP_SYS_BOOT |
Das System per reboot() neu starten |
| 23 | CAP_SYS_NICE |
Die Priorität per nice() hochsetzen, Realtime-Scheduling verwenden und die CPU-Affinität fremder Prozesse ändern |
| 24 | CAP_SYS_RESOURCE |
Ressourcenlimits überschreiten, etwa Quota, reservierter Filesystemraum, Größenbeschränkungen bei IPC-Nachrichten etc.. |
| 25 | CAP_SYS_TIME |
Die Systemzeit stellen |
| 26 | CAP_SYS_TTY_CONFIG |
TTY-Geräte konfigurieren |
| 27 | CAP_MKNOD |
Alle Funktionen von mknod() beim Anlegen von Gerätedateien nutzen |
| 28 | CAP_LEASE |
Dateien leasen (siehe fcntl()-Leases) |
| 29 | CAP_AUDIT_WRITE |
Meldungen an das Audit-Subsystem senden |
| 30 | CAP_AUDIT_CONTROL |
Audit-Subsystem per auditctl() konfigurieren |
| 31 | CAP_SETFCAP |
Posix-Capabilities im Extended Attribute capability speichern, also File Posix-Capabilities setzen |
| 32 | CAP_MAC_OVERRIDE |
Erlaubt es, zwingende Zugriffskontrollen (Mandatory Access Control, MAC) des Linux-Sicherheitsmoduls (LSM) zu überschreiben |
| 33 | CAP_MAC_ADMIN |
Erlaubt administrativen Zugriff auf die zwingenden Zugriffskontrollen |
Wie erwähnt verfügt ping unter den meisten Distributionen von Haus aus über das Setuid-Bit. Um einem normalen Nutzer den Ping-Befehl zu ermöglichen, könnte man entweder den Zugriff auf die Netzwerk-Geräte über die typischen Unix-Dateirechte freigeben oder über die File-Capabilities genau das Feature freischalten, das der Ping-Befehl benötigt – in diesem Fall CAP_NET_RAW. Danach lässt sich das Setuid-Bit ausschalten.
Woher nehmen?
Aktuelle Distributionen bringen den Support für die Posix-File-Capabilities bereits mit, allerdings gehören in der Regel nur die entsprechenden Libraries zur Standardinstallation, die nötigen Tools hingegen nicht. Den Quellcode [2] hostet die Kernel.org-Seite, aktuell ist Version 2.16 vom Dezember 2008. Bei der Installation muss man zudem zwischen Version 1 und 2 unterscheiden, wobei Version 1 keine File-Capabilities unterstützt und mit Version 2 in Konflikt steht. Dokumentation zu den Posix-File-Capabilities gibt es auf der Homepage des Entwicklers Chris Friedhoff zu Hauf [3].
OpenSuse-Nutzer installieren das Paket libcap-progs, bei Ubuntu und Debian heißt das entsprechende Paket libcap2-bin. Fedora 10 liefert Bibliotheken und Benutzerprogramme im Paket libcap mit. Ubuntu 9.04 und die aktuellen Fedora-Versionen bringen mit der Datei /lib/security/pam_cap.so zudem ein passendes PAM-Modul mit. Über die zum PAM-Modul gehörende Konfigurationsdatei /etc/security/capabilities.conf lassen sich so auch komplizierte Setups verwirklichen, die die passenden Rechte benutzerdefiniert bereits beim Login setzen.
Capabilities nutzen
Die Ausgabe von ls -l zu einem Programm zeigt zwar an, ob für dieses das S-Bit gesetzt ist, verrät aber nichts über die erweiterten Attribute der Datei. Um die Posix-File-Capabilities auszulesen, starten Sie man das Programm getcap mit dem gewünschten Dateinamen, zum Beispiel
# getcap /bin/ping
Zeigt der Befehl eine leere Ausgabe an, sind keine Capabilities gesetzt. Es besteht auch noch die Möglichkeit, sich über attr -l die erweiterten Attribute einer Datei anzeigen zu lassen. Die Ausgabe von attr -l signalisiert allerdings nur, ob Capabilities für eine Datei gesetzt sind, nicht welche.
Um die für den Ping-Befehl benötigte CAP_NET_RAW-Fähigkeit einzuschalten, genügt der Befehl
# setcap cap_net_raw=ep /bin/ping
Danach entfernt der Administrator über sudo chmod -s /bin/ping das Setuid-Bit und alle Nutzer können den Ping-Befehl wie gehabt nutzen. Um zum alten Verhalten über das Setuid-Bit zurückzukehren, entziehen Sie zunächst über sudo setcap -r /bin/ping dem Ping-Programm wieder alle Rechte und richten danach per sudo chmod +s /bin/ping das S-Bit wieder ein.
Caps für Fortgeschrittene
Die traditionellen Linux-Programme und -Dateien kennen die Rechte r,w und x. Auch bei den File-Capabilities gibt es drei verschiedene Rechte, Flags genannt:
- erlaubt (“permitted”,
p) - aktiv (“effective”,
e) - vererbbar (“inheritable”,
i)
Der Befehl setcap cap_net_raw=ep Programm setzt somit für das Recht cap_net_raw die Flags “erlaubt” und “aktiv” (=ep). Die einzelnen Rechte lassen sich zu so genannten Sets zusammensetzen, die Dokumentation dazu ist aber veraltet. Anstelle von Namen dürfen Sie dem setcap-Befehl auch Nummern als Parameter übergeben. Die Befehle setcap cap_net_raw=ep und setcap 13=ep bewirken somit das selbe.
Für die einschlägigen Programme passwd, und ping finden sich im Internet reichlich Beispiele, welche Fähigkeiten das Programm benötigt und welche nicht. Was tun jedoch, wenn man zum Beispiel das Sticky-Bit des mount-Befehls loswerden möchte? Eine Möglichkeit besteht darin, sich per strace Programmaufruf die komplette Ausgabe des Programms anzuschauen und nach EPERM-Meldungen zu suchen:
$ strace ping kde.org | grep EPERM
Aus der Ausgabe der EPERM-Fehlermeldungen lässt sich dann mit etwas Kombinationsgabe die benötigte Capability aus der Datei /usr/include/linux/capability.h herausfinden. Dieser Weg ist allerdings alles andere als benutzerfreundlich.
Als praktische Lösung bietet sich ein Kernelmodul des IBM-Entwicklers Serge E. Hallyn an, das Chris Friedhoff auf seiner Seite in einen praktischen Tarball gepackt hat [4]. Einmal geladen, zeigt das Modul im Systemlog sämtliche Anforderungen an die Posix-Capabilities an.
Nach der Installation über make und sudo make install laden Sie das Modul über den Befehl modprobe capable_probe und schauen sich dann über tail -f /var/log/messages die Systemmeldungen an (Abbildung 1).

cap_net_admin).” width=”300″ height=”156″ />
Abbildung 1: Für jede angeforderte Fähigkeit zeigt das Systemprotokoll die zugehörige Nummer an, der WPA-Supplicant verlangt zum Beispiel nach der Fähigkeit 12 (cap_net_admin). Da das Kernelmodul sehr viele Meldungen in die Logdatei schreibt, sollten Sie nicht vergessen, das Modul über modprobe -r capable_probe wieder zu entladen, sobald es seinen Dienst erfüllt hat.
Vor- und Nachteile
Aktuell benutzt keine Distribution die Posix-File-Capabilities zur Rechteverwaltung. Das hat verschiedene Gründe: Zum einen haben sich viele Nutzer und Distributoren an die Root-Rechte und an das Setuid-Bit gewöhnt. Das Dutzend Anwendungen, die das Setuid-Bit benötigt, unterliegt in der Regel strengen Sicherheitskontrollen seitens der Distributoren, so dass es in der Vergangenheit hier kaum zu Sicherheitsproblemen kam.
Auf der anderen Seite gibt es auch Programme, die trotz entsprechender Capabilities überprüfen, ob sie mit Root-Rechten laufen oder nicht. Dazu kontrollieren sie einfach die Nutzer-ID des Ausführenden. So lässt sich zum Beispiel auch nach der Zuordnung sämtlicher File-Capabilities der Zeitserverdienst ntpd nicht als normaler Benutzer starten, da das Binary überprüft, ob der aufrufende Nutzer die UID Null besitzt (Abbildung 2).

ntpd-Binary kann der Benutzer marcel den Dienst nicht starten.” width=”300″ height=”86″ />
ntpd-Binary kann der Benutzer marcel den Dienst nicht starten. Die Posix-File-Capabilities unterteilen die Rechte auf nur 33 Fähigkeiten. Das hört sich zwar auf den ersten Blick nach ziemlich viel an, genügt aber in der Praxis kaum. So erlaubt zum Beispiel das Ping-Programm mit dem Capability-Recht cap_net_raw auch das anpingen der Broadcast-Adresse – ein Feature, das bei der Setuid-Bit-Version immer noch dem Benutzer Root vorbehalten ist.
Fazit
Die meiste Literatur zum Thema Posix-File-Capabilities befasst sich mit dem Thema, wie man normalen Nutzern beziehungsweise einzelnen Programmen mehr Rechte einräumen kann, ohne ihnen gleich die kompletten Root-Rechte zu überlassen.
In der Praxis setzen sich aber mit AppArmor [5] und vor allem mit SELinux [6] zwei Tools durch, die genau den umgekehrten Weg beschreiten: Sie entschärfen den Root-Account so weit, dass man im Idealfall auf einem Rechner selbst als Root keinen Schaden mehr anrichten kann.
So hat zum Beispiel der Australier Russell Coker einen mit SELinux abgesicherten Rechner ins Netz gestellt, für den der Root-Account per SSH für jedermann zugänglich ist [7]. Dennoch kann man auf dem Rechner praktisch nichts verändern. Über Capabilities jedoch den Root-Account zu entschärfen, ist nicht möglich.
Glossar
-
PAM-Modul
-
Pluggable Authentication Module. Schnittstelle, um Nutzer mit anderen Mitteln als der bloßen Passworteingabe zu authentifizieren.
[1] Posix-Erweiterungen: http://wt.xpilot.org/publications/posix.1e/
[2] Libcap2: http://www.kernel.org/pub/linux/libs/security/linux-privs/libcap2/
[3] Dokumentation: http://www.friedhoff.org/posixfilecaps.html
[4] Capabilities-Testmodul: http://www.friedhoff.org/downloads/capable_probe.tar.bz2
[5] Apparmor: http://de.opensuse.org/Apparmor
[6] SELinux: http://www.fedorawiki.de/index.php/SELinux
[7] SELinux-Testrechner: http://www.coker.com.au/selinux/play.html





