POSIX File Capabilities ● Chemnitzer Linux-Tage – ● Chris Friedhoff c

Überblick ● Motivation ● POSIX File Capabilities vs POSIX Capabilities ● POSIX Capabilities ● POSIX Capability Rules ● POSIX File Capabilities ● Vorteil ● Konfiguration ● Vorführung ● Nachteil ● Last word / Fragen

Motivation ● Einführung mit verursacht / begleitet ● Qemu hatte bis mit dem TunTap Interface als unprivilegierter Nutzer kein Problem ● verlangte CAP_NET_ADMIN Capability zum Erstellen des TunTap Interfaces ● Patch zum Löschen der Zeilen ● Qemu Nutzer waren aber nicht begeistert ● „man kann doch nicht einfach den Kernel patchen“ ● es war keine optimale Lösung auf Dauer

diff -ruN linux orig/drivers/net/tun.c linux /drivers/net/tun.c --- linux orig/drivers/net/tun.c :42: linux /drivers/net/tun.c :21: ,9 +489,6 err = -EINVAL; - if (!capable(CAP_NET_ADMIN)) - return -EPERM; - /* Set dev type */ if (ifr->ifr_flags & IFF_TUN) { /* TUN device */

Motivation 2 ● Suche nach Lösung – 3 Patches – Olaf Dietsche's Capability Patch – David A. Madore's Capability Patch – Serge E. Hallyn's "introduce fs caps" Patch LKML ● Patch war der aktuellste (post ) ● Reaktion auf LKML war freundlich aber nicht überwältigen

Motivation 3 ● Kontakt mit Serge am – I haven't really gotten feedback on the last submission. ● gepatcht – Qemu Problem mit CAP_NET_ADMIN gelöst ● LKML – Dokumentation online – Feedback von B. O'Donnell SGI

Motivation 4 ● weiterentwickelte Patch geht in Andrew Morton's -mm Kernel rc5-mm2 ● – gereifter Patch geht in rc2

POSIX File Capabilities vs POSIX Capabilities ● POSIX File Capabilities sind der File Teil der POSIX Capabilities ● POSIX Caps blinde Anwendungen können per POSIX File Capabilities PCaps bekommen/nutzen ● 3 Sets an Capabilities für Prozesse und Files ● POSIX Caps seit 2.2 im Kernel (sendmail bug) ● POSIX File Caps seit im Kernel

POSIX Capabilities 1 ● beschrieben im zurückgezogenen POSIX e Draft ● Privilegien / Rechte ● Aufteilung des Root Allmacht in separate Teilrechte ● Summe bildet Root-Recht

POSIX Capabilities 2 ● /usr/include/linux/capability.h (2.6.24) – 8 POSIX Capabilities ● CAP_CHOWN, CAP_DAC_OVERRIDE, CAP_DAC_READ_SEARCH, CAP_FOWNER, CAP_FSETID, CAP_KILL, CAP_SETGID, CAP_SETUID – 24 Linux spezifische Capabilities ● CAP_SETPCAP, CAP_LINUX_IMMUTABLE, CAP_NET_BIND_SERVICE, CAP_NET_BROADCAST, CAP_NET_ADMIN, CAP_NET_RAW, CAP_IPC_LOCK, CAP_IPC_OWNER, CAP_SYS_MODULE, CAP_SYS_RAWIO, CAP_SYS_CHROOT, CAP_SYS_PTRACE, CAP_SYS_PACCT, CAP_SYS_ADMIN, CAP_SYS_BOOT, CAP_SYS_NICE, CAP_SYS_RESOURCE, CAP_SYS_TIME, CAP_SYS_TTY_CONFIG, CAP_MKNOD, CAP_LEASE, CAP_AUDIT_WRITE, CAP_AUDIT_CONTROL, CAP_SETFCAP

POSIX Capabilities 3 ● Eigenschaften – assoziiert mit Prozessen und Executables – eine oder mehrere PCaps können assoziiert werden – Privilegieren Prozess Aktion auszuführen / zu verlangen – Permitted, Effective & Inheritable Set – auf Codebereich beschränkt werden – per fork() / clone() entstandene Prozesse haben gleichen PCap Sets

POSIX Capabilities 4 ● Permitted Set – alle gewährten, nutzbaren Pcaps – kann vom Prozess abgegeben werden (endgültig) – für Files auch forced Set ● d.h. Admin kann sicherstellen, daß der Prozess diese PCaps hat – kann vom Prozess selbst nicht erweitert werden

POSIX Capabilities 5 ● Effective Set – aktive Pcaps / aktive jetzt nutzbare Rechte – Prozess kann enablen / disablen – Teilbereich des Prozess Permitted Sets – Files: fP = fE

POSIX Capabilities 6 ● Inheritable Set – NICHT wirksam für reine POSIX File Capabilies Anwendung -> legacy support – Prozess aktiviert aus pP in den pI – Erweiterbarkeit des Permitted Sets des neuen Prozesses, wenn aufrufender Prozess vererbt und aufgerufener Prozess das Erbe annimmt fI

POSIX Capability Rules pI' = pI (ie., unchanged by exec()) pP' = (X & fP) | (pI & fI) pE' = fE & pP' ● fP = permitted PCaps des Executable, minimum forces set of permitted PCaps of the resulting process ● fE = effective PCaps of the executable, effective PCaps of the resulting process ● fI = per inheritance accepted Pcaps ● pP = permitted PCaps of a process ● pE = effective PCaps of a process ● pI = inherritable PCaps of a process ● & --> bitweises AND (Schnittmenge / junction ) ● | --> bitweises OR (Vereinigungsmenge / union) ● X = cap_bset (under Linux) (... where X denotes possible additional implementation-defined restrictions, (p18 Posix1003.1e)

POSIX File Capabilities 1 pP' = (X & fP) | (pI & fI) --> pP' = fP pE' = fE & pP' --> pE' = fE & fP ● File Effective & File Permitted Set sind gleich ● minimales notwendiges Set an PCap sichergestellt ● Anwendung muß keine Ahnung von PCaps haben ● aber hoffentlich keine Abfrage nach uid==0/root

POSIX File Capabilities 2 ● Vorteile – Ersetzen des SUID-0 durch die nur notwendigen POSIX Capabilities Rechte ● ping, passwd, traceroute, qemu – weniger unter Root laufende Prozesse und Programme ● single user system (statt sudo / su -c) – kill, killall, modprobe, ntpdate ● Server unter speziellen unprivilegierten User – httpd, samba, dhcpd, bind, cupsd – accountability – POSIX Caps Nutzung weg vom Entwickler & hin zum Admin

POSIX File Capabilities 3 ● Kernel Configuration – General setup ● Prompt for development and/or incomplete code/drivers – Security options ● File POSIX Capabilities (EXPERIMENTAL) ● make, make modules_install, cp bzImage, edit Bootloader (grub, lilo), restart

POSIX File Capabilities 4 ● Userland Tools - libcap2 – download – build & install ● tar xjf libcap-2.07.tar.bz2 ● cd libcap-2.07 ● make ● sudo make install – use ● sudo setcap cap_setfcap=ep /sbin/setcap ● setcap cap_net_raw=pe /bin/ping

POSIX File Capabilities 5 ● Vorführung – setcap, ping, attr -l, attr -S -r, – find {,/usr}/{,s}bin -user root -perm exec ls -l {} \; – modprobe capable_probe – tail -f /varlog/message | grep ping – strace -e trace=file /bin/ping -c 1 localhost – strace -e trace=network /bin/ping -c 1 localhost

POSIX File Capabilities 6 ● Nachteile – keine Distributionunterstützung – tiefer Eingriff ins System – eigener Kernel & User tools zu kompilieren – man kann sich auch hier in den Fuß schießen – noch am Anfang – POSIX File Capabilities werden im xattr capability gespeichert & sind nicht mit dem Standardverwaltungstool ls zu sehen

Last words 1 ● Casey Schaufler - – Getting the capability settings correct on all setuid programs is a tough nut. Training people out of the root model isn't easy, either. – The work underway for SELinux is different from that of capabilities. POSIX capabilities offer substantial benefits without the high cost of SELinux. – Sure, SELinux and POSIX capabilities are different. No arguement. POSIX capabilities predate SELinux in the community and in the Linux kernel. To date they have been limited by the lack of xattr support, but now that that is available there is every reason to complete the implementation. – Irix, which has supported POSIX capabilities for years...

Last words 2 ● Casey Schaufler - – I maintain that the real value in the POSIX capability model derives from seperating the permission to violate policy from the UID. – Granularity of such privilege is a bonus, and a matter of considerable debate. DGUX ended up with over 330 distinct capabilities, while Irix had (last I looked) 24, and Solaris came in somewhere between. All these systems work. ● Seth Arnold - – Still, I agree, complementary, and hopefully a mechanism such as this proposed mechanism would help drag capabilities out of the dark ages. ● Ismail Dönmez - – FWIW in Pardus 2008 we'll enable Posix file capabilities by default so people could "harden" their setups.