PRAXIS SELinux-Tutorial II Policy-Erweiterungen in Eigenarbeit Gut geschützt avr.selinux.tut2_id13947_ unterschiedliche Dateien aufgeteilt, die der Makroprozessor m 4 über ein Makefile gesteuert nacheinander zu einer Datei policy.conf zusammensetzt, bevor daraus per checkpolicy die Binär-Version policy.18 entsteht. Dabei expandiert m4 die in den einzelnen Policy-Dateien v e rwendeten Makros; Abbildung 1 zeigt den Ablauf. Type-Enforcement und Zugriffsregeln T h o rsten Scherf Per Default schützt die SELinux-targeted - Policy nur eine Re i h e von exponierten Diensten und Dateien. Will man den Schutzschirm auf eigene Anwendungen ausdehnen, muss man sich intensiver mit den Strukturen innerhalb der Policy und den dazugehörigen Werkzeugen befassen. S chon der erste Teil des Tutorials behandelte einige Sprach-Elemente der SELinux-Policy, dieser zweite Artikel wird das vertiefen. Er erörtert die einzelnen Policy-Dateien und deren Aufgabe. Am Ende soll er anhand einer neuen Anwendung die bestehende Policy um eigene Regelsätze erweitern helfen. Wie im ersten Teil basieren alle Beispiele auf Red Hats Enterprise Linux 4 (RHEL4), sollten sich aber auf anderen Distributionen mit aktiviertem SELinux nachvollziehen lassen. Wie dort [1] erklärt, seien Benutzer von Fedora Core 5 auf den dritten Teil ver2 wiesen, da es schon die nächste SELinux-Generation verwendet. Die Arbeit an dem Regelwerk erinnert den einen oder anderen Leser eventuell an das Arbeiten an einem Programm, da auch hier eine Sourceund eine Binär-Version existiert. Sobald eine Änderung an den Quellen stattgefunden hat, muss der Systemverwalter mit dem Compiler checkpolicy eine neue Binär-Version erzeugen, die er anschließend per load_policy in den Security-Server des Kernel lädt. Auf Grund der Komplexität des Regelwerks haben es die Entwickler in Daher empfiehlt sich an dieser Stelle zunächst ein genauerer Blick auf das Quellverzeichnis unterhalb von /etc/se linux/targeted/src/policy. Die wohl wichtigsten Dateien, aus denen das Regelwerk entsteht, sind die so genannten Type-Enforcement- und File-ContextDateien. Jedes innerhalb der SELinuxTargted-Policy in einen Käfig eingesperrte Programm hat unterhalb von domains/program/ eine eigene TypeEnforcement-Datei üblicherweise mit der Dateiendung. t e. Will man ein neues Programm durch SELinux schützen, ist hier eine neue Datei für das Programm anzulegen. Bestehende Dateien lassen sich natürlich auch modifizieren, allerdings würde ein Update des PolicySource-RPMs die Änderungen wieder überschreiben. Deshalb nimmt man Modifikationen besser über die Datei do mains/misc/misc.te vor. Der dazugehörige Ordner ist per Default leer und wird somit auch bei einem Update nicht überschrieben. Type-Enforcement-Dateien definieren die Typen, die das System später an Objekten vergibt, Zugriffsvektoren also beispielsweise allow- A nweisungen und Booleans. Listing 1 zeigt ein Beispiel aus der a p a c h e. t e. Als erstes definiert dieses einen FileType httpd_config_t. Diesen verwenden die File-Context-Dateien später dazu, die Konfigurationsdateien des Webservers mit einem Label zu versehen. Eine Datei lässt sich nur dann mit einem Type labeln, wenn dieser vorher definiert wurde. Hinter dem Namen Tutorialinhalt Teil I: Einführung, Architektur und Administration Teil II: Policies anpassen beziehungsweise schreiben Teil III: Frontends, Reference Policy, Binärmodule ix 9/2006
des Types kann man Attribute angeben dazu später mehr. In der zweiten Zeile steht der Aufruf des Makros d a e - m o n _ d o m a i n mit dem Argument h t t p d. Auch hier lassen sich wieder Attribute ü b e r g e b en. Zur Definition des Makros später mehr. Die Zeilen drei bis sieben definieren ein Boolean h t t p d _ e n a b l e _ homedirs mit Default-Wert false (bool httpd_enable_homedirs false;). s e t - sebool httpd_enable_homedirs=1 aktiviert die allow-anweisung. Sie gestattet Programmen aus den Domänen h t t p d _ t, h t t p d _ s y s _ s c r i p t _ t und h t t p d _ s u e x e c _ t, Zugriff auf Ordner mit dem Type u s e r _ h o m e _ d i r _ t. Die Targeted- Policy versieht das Verzeichnis ~/pub - lic_html mit diesem Label. Es gestattet durch das Aktivieren also den Zugang zu benutzerspezifischen Webseiten. Wie im ersten Teil beschrieben, stehen die Access-Vektoren allow, audit - a l l o w und d o n t a u d i t zur Verfügung. Hier je ein Beispiel für deren Anwendung: auditallow unconfined_t security_t:security { load_ \ policy setenforce setbool }; Üblicherweise protokolliert SELinux lediglich unerlaubte Aktionen. Manchmal ist es aber auch sinnvoll, erlaubte Aktionen im Log festzuhalten. Dazu dient a u d i t a l l o w, es protokolliert durch a l l o w-anweisungen gestattete Aktionen. Im obigen Beispiel landen also das Laden einer neuen Policy, der Wechsel des SELinux-Modus (p e r m i s s i v e o d e r e n f o r c i n g) und das Setzen eines Booleans im Syslog so eine passende al - low-anweisung existiert. d o n t a u d i t verhält sich genau andersrum: Dank dieses Access-Vektors protokolliert das System verbotene Aktionen nicht. Das kann das Überlaufen der Logs durch häufig auftretende, unautorisierte Aktionen vermeiden. Beispielsweise verhindert dontaudit httpd_t console_device_t:chr_file { ioctl \ read getattr lock write append }; das Logging jedes Webserver-Zugriffs auf die Konsole. x-t RAC T Beim Schreiben von Type-Enforcement-Regeln lassen sich einige spezielle Notationen verwenden. allow httpd_t self:process ~{ ptrace setexec \ setfscreate setrlimit }; s e l f als Target bezieht sich hier auf Prozesse, die ebenfalls in der Domäne h t t p d laufen. ~ gestattet kompletten Zugriff mit Ausnahme der aufgeführten Rechte. allow unconfined_t security_t:security *; Das Sternchen bezieht sich auf alle für diese Objektklasse (s e c u r i t y) zur Verfügung stehenden Berechtigungen. allow {domain -httpd_t} etc_t:file r_file_perms; gestattet allen in einer Domäne mit dem Attribut d o m a i n laufenden Prozessen den Zugriff auf Objekte vom Type e t c _ t. h t t p d _ t generiert hier für die Webserver-Domäne eine Ausnahme. Individueller Date i ko n te x t Die Arbeit am SELinux-Re ge l werk erinnert an Pro gra m m i e rung: Es exist i e ren Q u e l l d a teien und eine binäre Po l i c y, die im Ke rnel die Syste m s i cherheit sich e rste l l t. Mit einem ite ra t i ven Pro z e d e re kann man eigene Anwe n d u n gen unter den Sch u t z von SELinux ste l l e n. Per a u d i t 2 a l l o w kann der Ad m i n i st ra tor zwar aus Fe h l e rm e l d u n gen passende a c c e s s- Re geln ge n e r i e ren, allerdings lassen diese meist mehr zu als unbedingt nötig. B evor man eine neue binäre Policy in den Ke rn e l laden kann, muss diese dive rse Ve ra r b e i t u n g s- st u fen über sich ergehen lassen (Abb. 1). Listing 1: Auszug aus a p a c h e. t e type httpd_config_t, file_type, sysadmfile; daemon_domain(httpd, `, privmail, nscd_client_domain') bool httpd_enable_homedirs false; if (httpd_enable_homedirs) { allow { httpd_t httpd_sys_script_t httpd_suexec_t } user_home_dir_t:dir { getattr search }; } Listing 2: Auszüge aus d a e m o n _ d o m a i n define(`daemon_domain', ` type $1_t, domain, privlog $2; type $1_exec_t, file_type, sysadmfile, exec_type; uses_shlib($1_t) domain_auto_trans(initrc_t, $1_exec_t, $1_t) ') Unterhalb von f i l e _ c o n t e x t s / p r o g r a m / verfügt jedes, durch SELinux geschützte Programm, über eine File-Context-Datei. Diese endet üblicherweise auf. f c. Auch hier gilt, um ein neues Programm durch eine eigene Policy zu schützen, legt man eine eigene File-Context- D atei in diesem Order an. Änderungen an bestehenden Dateien lassen sich über eine angepasste Datei im Ordner file_contexts/misc/ erledigen. Die File- Context-Dateien basieren auf den erweiterten regulären Ausdrücken. Hier ein Beispiel aus der apache.fc: /var/www(/.*)? system_u:object_r: \ h t t p d _ s y s _ c o n t e n t _ t /etc/httpd -d system_u:object_r:httpd_config_t Gemäß der ersten Zeile erhalten der Ordner / v a r / w w w / und alle eventuell darin vorhandenen Dateien ein Label. Die letzte Zeile verknüpft explizit nur den Ordner /etc/httpd mit einem Label. Alle File-Context-Dateien werden beim Kompilieren der Policy zur Datei f i l e _ c o n t e x t s / f i l e _ c o n t e x t s z u s a m m e n- gesetzt und sind nicht Bestandteil der p o l i c y. c o n f. Verantwortlich hierfür ist wieder der Makroprozessor m 4. Ist eine Datei in einer der File-Context-Dateien mit einem Label verknüpft worden, lässt sich diese sehr leicht über das Tool r e s t o r e c o n mit dem korrekten Label versehen, ohne dass man es hier per chcon explizit angeben muss. Ü b e rs i ch t l i ch keit mit Makro s Im Verzeichnis macros/ finden sich Definitionen von globalen und programmspezifischen Makros. So fasst ix 9/2006 3
P R A X I S SELinux-Tutorial II avr.selinux.tut2_id13947_ beispielsweise c o r e _ m a c r o s. t e v e r- schiedene Berechtigungen zusammen. Statt innerhalb einer allow-anweisung die nötigen Rechte zum Lesen und Schreiben an einer Datei einzeln aufzulisten, kann man hier einfach das Makro r w _ f i l e _ p e r m s verwenden. Die Definition sieht folgendermaßen aus: define(`rw_file_perms', `{ ioctl read getattr \ lock write append }') und der entsprechende Aufruf in apache.te allow httpd_t crypt_device_t:chr_file \ r w _ f i l e _ p e r m s ; gestattet lesenden und schreibenden Zugriff von Prozessen aus der Domäne h t t p d _ t auf Character-Dateien v o m Type crypt_device_t. Auch g l o b a l _ m a c r o s. t e n i m m t wichtige Festlegungen vor. So bestimmt beispielsweise das darin enthaltende Makro d a e m o n _ d o m a i n e i n e Reihe wichtiger Anweisungen, die beinahe jedes Programm benötigt. Ein Aufruf des Makros definiert unter anderem Types und gestattet den Zugriff auf Bibliotheken. Darüber hinaus bestimmt es die Domäne, in der das Programm laufen soll. List i n g 2 zeigt einige Ausschnitte aus dem Makro daemon_domain. Wie man sieht, lassen sich innerhalb von einer Makro-Definition andere Makros aufrufen. Beispiele sind das Makro u s e s _ s h l i b, das den Zugriff auf Shared-Libraries gestattet, oder der Aufruf von d o m a i n _ a u t o _ trans, der festlegt, in welcher Domäne das zu startende Programm laufen soll. Der Aufruf in apache.te sieht folgendermaßen aus: daemon_domain(httpd, `, privmail, \ n s c d _ c l i e n t _ d o m a i n ' ) Der Makroprozessor m 4 expandiert das Makro in policy.conf und generiert aus dem oben genannten Beispiel die in L i s t i n g 3 gedruckten Anweisungen. Wobei er u s e s _ s h l i b ( h t t p d _ t ) n a t ü r l i c h auch expandiert. Die Definition von u s e s _ s h l i b findet sich in g l o b a l _ m a - cros.te (siehe Listing 4). Auch d o m a i n _ a u t o _ t r a n s ( i n i t r c _ t, httpd_exec_t, httpd_t) expandiert m 4 anhand folgender Festlegung: # domain_auto_trans(parent_domain, # program_type, child_domain) d e f i n e ( ` d o m a i n _ a u t o _ t r a n s ', ` d o m a i n _ t r a n s ( $ 1, $ 2, $ 3 ) type_transition $1 $2:process $3; ) Listing 3: expandierte Makros type httpd_t, domain, privlog, privmail, nscd_client domain; type httpd_exec_t, file_type, sysadmfile, exec_type; uses_shlib(httpd_t) domain_auto_trans(initrc_t, httpd_exec_t, httpd_t) Listing 4: Makrodefinition u s e s _ s h l i b # uses_shlib(domain) # # Permissions for using shared libraries. # define(`uses_shlib',` allow $1 { root_t usr_t lib_t etc_t }:dir r_dir_perms; allow $1 lib_t:lnk_file r_file_perms; allow $1 ld_so_t:file rx_file_perms; allow $1 ld_so_t:lnk_file r_file_perms; allow $1 shlib_t:file { rx_file_perms execmod }; allow $1 shlib_t:lnk_file r_file_perms; allow $1 ld_so_cache_t:file r_file_perms; allow $1 { lib_t zero_device_t ld_so_t ld_so_cache_t shlib_t }:file execmod; allow $1 device_t:dir search; allow $1 null_device_t:chr_file rw_file_perms; ') Listing 5: Auswirkungen von n e w r o l e id -Z root:staff_r:staff_t getenforce Enforcing setenforce 0 setenforce: setenforce() failed newrole -r sysadm_r Authenticating root. Password: id -Z root:sysadm_r:sysadm_t setenforce 0 getenforce Permissive [root@grobi ~] Wie man sieht, erzeugt der Aufruf eines Makros wie d a e m o n _ d o m a i n d u t- zende von Anweisungen in p o l i c y. c o n f. Zum Schreiben eigener Regelsätze sollte man regen Gebrauch von den zur Verfügung stehenden Makros machen. Das spart nicht nur eine Menge Tipparbeit, sondern verbessert deutlich die Lesbarkeit der Regeln. Es kann nicht schaden, ein wenig im Verzeichnis m a - c r o s zu schmökern und sich mit den Definitionen vertraut zu machen. Objektklassen und B e re ch t i g u n ge n Im Unterverzeichnis f l a s k sind zwei Dateien von besonderem Interesse s e - c u r i t y _ c l a s s e s und a c c e s s _ v e c t o r s. Erstere definiert mehrere Dutzend Objektklassen. Die Objektklassen sind Teil der Kernel-Sources und finden sich dort im Verzeichnis s e c u r i t y / s e l i n u x / i n c l u d e / wieder. Bisher waren m i t Objekten meistens Dateien oder Verzeichnisse gemeint. SELinux kennt jedoch wesentlich mehr Objekte eben die in der Datei s e c u r i - t y _ c l a s s e s definierten. Benutzer können also durchaus unterscheiden zwischen an einer regulären D a t e i (f i l e), einem Link (l n k _ f i l e), e i n e m Block-Device (b l k _ f i l e) oder an anderen Datei-Objekten vergebenen Berechtigungen. Darüber h i n a u s kennt SELinux Interface-O b j e k t e (n e t i f), Netzwerk-Sockets (t c p _ socket, udp_socket) oder Shared-Memory-Segment-Objekte (s h m) und noch viele andere. a c c e s s _ v e c t o r s weist diesen Objekten potenzielle Berechtigungen zu. Wie im ersten Teil beschrieben, bestimmt das Type- Enforcement, welche Berechtigungen ein Subjekt auf ein Objekt hat. So lassen sich Dateiobjekten circa 20 verschiedene Berechtigungen zuweisen (r e a d, w r i t e, c r e a t e, g e t a t t r, ). Beim Schreiben eigener Regelsätze sollte man daran denken, dass sich viele dieser Berechtigungen über Makros zusammenfassen lassen gerade bei Datei- oder Verzeichnisobjekten. Die Datei f l a s k / i n i t i a l _ s i d s dient zum Zuweisen von Datei-Labeln während des Bootvorgangs. Sie ähnelt der früheren Linux-Vorgehensweise, die Security- Context-Informationen von Dateien nicht in den erweiterten Attributen des Filesystems, sondern lediglich in einer Datei zu speichern. Alle drei der genannten Dateien dienen lediglich dem Verständnis von SELinux man sollte sie unter keinen Umständen ä n d e r n. Mehr Ko m fo rt mit At t r i b u te n In attrib.te befinden sich die Definitionen von Attributen. Diese folgen der Notation attribute <Attributname>;. Zwei wichtige Vertreter sind die Attribute d o m a i n und f i l e _ t y p e. Ersteres identifiziert Typen, die sich einem Prozess zuordnen lassen. Domänen sollten grundsätzlich damit ausgestattet sein, beispielsweise um i n i t zu gestatten, alle Prozesse zu beenden. Über das Attribut file_type lassen sich einzelnen Dateien in persistenden Filesystemen zugewiesene Types identifizieren. Attribute lassen sich per Komma getrennt bei der Definition eines Types oder bei dem Aufruf eines Ma- 4 ix 9/2006
Listing 6: Ausgabe von make policy [root@grobi policy]# make policy mkdir -p tmp m4 -Imacros -s flask/security_classes flask/initial_sids flask/access_vectors tunables/distro.tun tunables/tunable.tun attrib.te tmp/program_used_flags.te macros/program/apache_macros.te macros/program/chkpwd_macros.te domains/program/sendmail.te domains/program/snmpd.te domains/program/squid.te domains/program/syslogd.te domains/program/udev.te domains/program/winbind.te domains/program/ypbind.te assert.te rbac users serviceusers constraints initial_sid_contexts fs_use genfs_contexts net_contexts > policy.conf.tmp mv policy.conf.tmp policy.conf /usr/bin/checkpolicy -o policy.18 policy.conf /usr/bin/checkpolicy: loading policy configuration from policy.conf security: 4 users, 4 roles, 363 types, 28 bools security: 55 classes, 22860 rules /usr/bin/checkpolicy: policy configuration loaded /usr/bin/checkpolicy: writing binary representation (version 18) to policy.18 Validating file_contexts... /usr/sbin/setfiles -q -c policy.18 file_contexts/file_contexts kros angeben. Beim Schreiben von T y p e -Enforcement-Regeln kann man auf die Attribute zurückgreifen. Statt Subjekte anhand ihrer Domäne beziehungsweise Objekte anhand ihres Types zu charakterisieren, kann man auch einfach Attribute verwenden. Kommt anstelle eines Types ein bestimmtes Attribut zum Einsatz, spricht dies alle Objekte an, die über einen Type mit dem entsprechen Attribut verfügen. Für Subjekte verhält es sich genauso. Die Zeile allow unconfined_t file_type:filesystem *; gewährt allen Prozessen aus der Domäne u n c o n f i n e d _ t Zugriff auf alle Objekte mit dem Attribut file_type mit sämtlichen Rechten. Schließlich laufen bei der Targeted-Policy nur eine Handvoll Prozesse in geschützten Domänen, alle anderen besitzen keinen SELinux- Schutz und haben somit Zugriff auf sämtliche Dateien. Auch Dateien auf Filesystemen ohne Support für erweiterte Attribute lassen sich mit Labeln versehen. In genfs_context kann man Dateisystemen einen Security-Context zuweisen, sodass alle enthaltenen Files das gleiche Label bekommen. Hier ein Beispiel: genfscon cifs / system_u:object_r:cifs_t genfscon smbfs / system_u:object_r:cifs_t genfscon nfs / system_u:object_r:nfs_t genfscon iso9660 / system_u:object_r:iso9660_t m o u n t kennt eine Option, die sich für Filesysteme ohne erweiterte Attribute nutzen lässt. Sie ist beim Aufruf per c o n t e x t = U s e r : R o l l e : T y p e zu übergeben und setzt sich über Definitionen in der Policy hinweg. Auf die Rolle kommt es an In der Targeted-Policy kommt fast ausschließlich die SELinux-Implementierung Type-Enforcement (TE) zum Einsatz. SELinux unterstützt jedoch auch eine rollenbasierte Zugangskontrolle (RBAC). Diese gestattet einem Benutzer anhand seiner zugewiesenen Rolle (zweiter Teil des Security-Kontextes) Zugriff auf einen Prozess (Domäne) oder eben nicht. Die Strict-Policy a r b e i- tet intensiv mit Rollen. In der Datei u s e r s kann der Administrator jedem Benutzer mehrere Rollen zuordnen: user user_u roles { user_r }; user tscherf roles { user_r staff_r sysadm_r }; user root roles { sysadm_r staff_r secadm_r }; Beim Login erhält der Benutzer ein Auswahlmenü mit möglichen Rollen; die erste dient als Default-Vorschlag. Ein nachträglicher Rollen-Wechsel kann über das Tool n e w r o l e e r f o l g e n, hierfür muss sich der Benutzer allerdings erneut mit seinem Passwort authentifizieren. Ein Benutzer kann sich zu einem bestimmten Zeitpunkt immer nur in einer einzelnen Rolle befinden. In der Policy kann der Administrator nun definieren, welche Rolle Zugang zu welcher Domäne hat. Die Anweisungen role sysadm_r types ping_t; domain_auto_trans(sysadm_t, ping_exec_t, ping_t) gestatten allen Benutzern in der s y s - adm_r-rolle den Zugang zu Prozessen in der Domäne p i n g _ t. Eine Domain- Transition sysadm_t > ping_exec_t > p i n g _ t autorisiert das Makro d o m a i n _ auto_trans. Nimmt man die Autorisierung der Rolle s y s a d m _ r zur Domäne ping_t weg, so erhält man beim Aufruf von ping folgende Ausgabe: id -Z r o o t : s y s a d m _ r : s y s a d m _ t [root@grobi ~] ping www.redhat.de bash: /bin/ping: Keine Berechtigung [root@grobi ~] Dies ist eine schöne Möglichkeit, die Macht des Superuser zu begrenzen. Man kann den Default-Kontext von Root so ändern, dass er per Default eine nicht administrative Rolle (s t a f f _ r) zugewiesen bekommt. Zur Durchführung administrativer Aufgaben müsste ix 9/2006 5
P R A X I S SELinux-Tutorial II avr.selinux.tut2_id13947_ der Benutzer erst per n e w r o l e in eine neue (administrative) Rolle schlüpfen. Das erfordert jedoch die Eingabe des Root- Passwortes, Listing 5 zeigt einen beispielhaften Verlauf. In diesem Beispiel war der Benutzer Root nicht in der Lage, das System in den p e r m i s - s i v e-mode zu setzen. Grund hierfür ist die nicht administrative Rolle s t a f f _ r. Erst nach dem Wechsel in eine andere Rolle (s y s a d m _ r) gelang der Aufruf von setenforce 0. Erlangt ein Angreifer durch das Ausnutzen einer Sicherheitslücke in einer Software Root-Rechte auf einer betroffenen Maschine, so hat er dennoch keine privilegierten Rechte, solange sich Root in der Rolle s t a f f _ r befindet. Für einen Rollenwechsel müsste per n e w r o l e erst eine erfolgreiche Authentifizierung erfolgen. In a p p c o n f i g / r o o t _ d e f a u l t _ contexts lässt sich der Default- Kontext für den Benutzer Root ändern. Hier kann man im übrigen genau festlegen, welchen Kontext das System bei welcher Art Login setzen soll. So lässt sich beispielsweise ein lokaler Login von Root im Kontext direkt mit der Rolle s y s - a d m _ r verknüpfen, ein Login per s s h hingegen mit der nicht administrativen Rolle staff_r. Eine neue Policy erz e u ge n Hat der Administrator nun alle zum Regelwerk gehörenden Dateien nach den eigenen Wünschen angepasst, geht es an das Erzeugen der eigentlichen Policy-Datei. Natürlich lassen sich der für das Expandieren zuständige Makroprozessor m 4 und der Compiler c h e c k p o l i y, der die Binärversion der Policy erzeugt, manuell aufrufen. Allerdings existiert für diese Aufgabe ein Makefile im Source-Verzeichnis. Der Header des Makefiles beschreibt einige Targets. Beim Scrollen durch die Datei stellt man schnell fest, dass noch weitere, nicht explizit im Header beschriebene Targets existieren. Für das Generieren einer neuen Version der Policy reicht der Aufruf make po - l i c y. Listing 6 zeigt eine dazugehörige A u s g a b e. Listing 7: Aktivieren der neuen Label [root@grobi policy]# restorecon /etc/vsftpd/vsftpd.conf [root@grobi policy]# ls -lz /etc/vsftpd/vsftpd.conf -rw------- root root system_u:object_r:ftpd_conf_t /etc/vsftpd/vsftpd.conf Listing 8: m y f t p d. t e daemon_domain(ftpd, `,auth_chkpwd, nscd_client_domain') type ftpd_conf_t, file_type, sysadmfile; append_log_domain(ftpd) allow ftpd_t self:capability audit_write; can_network(ftpd_t) allow ftpd_t { ftp_data_port_t ftp_port_t port_t }:tcp_socket name_bind; allow ftpd_t self:capability { chown fowner fsetid setgid setuid net_bind_service sys_chroot sys_nice sys_resource }; allow ftpd_t self:unix_dgram_socket create_socket_perms; allow ftpd_t self:unix_stream_socket create_socket_perms; r_dir_file(ftpd_t, ftpd_conf_t) r_dir_file(ftpd_t, etc_t) allow ftpd_t { self proc_t }:file r_file_perms; allow ftpd_t self:fifo_file rw_file_perms; allow ftpd_t sbin_t:dir search; allow ftpd_t sbin_t:file { rx_file_perms execute_no_trans }; allow ftpd_t shadow_t:file r_file_perms; allow ftpd_t self:process { getcap setcap }; allow ftpd_t home_root_t:dir search; allow ftpd_t nscd_var_run_t:dir r_dir_perms; r_dir_file(ftpd_t, user_home_dir_t) r_dir_file(ftpd_t, user_home_t) allow ftpd_t self:netlink_audit_socket { create read write nlmsg_relay }; allow ftpd_t selinux_config_t:dir search; allow ftpd_t selinux_config_t:file { read getattr }; allow ftpd_t var_t:dir read; allow ftpd_t tty_device_t:chr_file { read write }; Der Aufruf erzeugt zuerst aus den einzelnen Policy-Dateien eine p o l i c y. c o n f. Diese enthält bereits die per m 4 e x- pandierten Makros. Im Anschluss erzeugt der SELinux-Compiler c h e c k p o l i - c y aus der Quelldatei p o l i c y. c o n f e i n e Binär-Version. Diese lässt sich anschließend per load_policy policy.18 i n den Security-Server des Kernels laden. Allerdings kann dies auch direkt über das Makefile erfolgen: Der Aufruf m ake load generiert nicht nur eine neue Policy, sondern lädt das neu erstellte Regelwerk unmittelbar danach in den Kernel. S ch u t z s child für ein neues Pro gra m m Möchte man nun also ein neues Programm unter das Schutzschild von SE- Linux stellen, ist die bestehende Policy passend zu ändern und um eigene Regeln zu ergänzen. Das Beispiel des FTP-Servers v s f t p d soll das Vorgehen verdeutlichen. Dieser ist in RHEL4 enthalten, gehört allerdings nicht zu den von der Targeted-Policy geschützten Diensten, das heißt, er läuft per Default in der Domäne u n c o n f i n e d _ t. Am Anfang stehen die beiden wichtigsten Dateien, die File-Kontextund Type-Enforcement-Datei. Man muss sich ansehen, welche Dateien zum Paket v s f t p d g e h ö- ren, und sich anschließend überlegen, mit welchem Label man sie versehen will. Interessant sind hierbei Log- und Konfigurationsdateien sowie Executables. Hier ein einfaches Beispiel für eine Datei f i l e _ c o n - texts/program/myftp.fc: /var/log/xferlog : \ s y s t e m _ u : o b j e c t _ r : f t p d _ l o g _ t /etc/vsftpd(/.*)? : \ s y s t e m _ u : o b j e c t _ r : f t p d _ c o n f _ t /etc/vsftpd.ftpusers : \ s y s t e m _ u : o b j e c t _ r : f t p d _ c o n f _ t /etc/vsftpd.user_list : \ s y s t e m _ u : o b j e c t _ r : f t p d _ c o n f _ t /usr/sbin/vsftpd : \ s y s t e m _ u : o b j e c t _ r : f t p d _ e x e c _ t Selbstverständlich muss man die verwendeten Types erst noch definieren, bevor sich eine neue Policy generieren lässt und restorecon die Dateien mit passenden Labeln versehen kann. Als Nächstes erzeugt man also eine Datei d o m a i n s / p r o - gram/myftp.te. type ftpd_conf_t, file_type, sysadmfile; daemon_domain(ftpd, `,auth_chkpwd ) a p p e n d _ l o g _ d o m a i n ( f t p d ) Das Kommando in der ersten Zeile erzeugt den Type für die Konfigurationsdateien, bei den Zeilen 2 und 3 handelt es sich jeweils um einen Makroaufruf mit dem Argument f t p d. Details liefern die Definition der beiden Makros in m a c r o s / g l o b a l _ m a c r o s. t e. d a e m o n _ d o m a i n legt unter anderem die Types $ 1 _ e x e c _ t und $ 1 _ t fest. Da das erste Argument des Makroaufrufs f t p d lautet, enthält die Policy später zwei Type-Definitionen f t p d _ e x e c _ t und f t p d _ t. Genau diese sind für die ausführbare Datei und für die Domäne erforderlich, in der der geschützte f t p d-prozess nachher laufen soll. Das Makro a p p e n d _ l o g _ d o m a i n e r z e u g t unter anderem den Type f t p d _ l o g _ t und gestattet außerdem dem Prozess aus der Domäne f t p d _ t, Dateien mit diesem Type anzulegen, falls sie noch nicht existieren, und diese auch zu beschreiben. Es ist immer eine gute Idee, mit diesen beiden Makro-Aufrufen anzufangen, da sie schon eine Menge 6 ix 9/2006
Regeln erzeugen. Eine genaue Übersicht bieten wieder die Definition der verwendeten Makros. In diesem Stadium sollte sich jetzt per make load schon eine neue Policy erzeugen und laden lassen. Anschließend befinden sich im Policy-Source- Verzeichnis zwei neue Dateien: p o l i - c y. c o n f und p o l i c y. 1 8. Über das Tool r e s t o r e c o n versieht man nun die zum FTP-Server gehörenden Dateien mit dem korrekten Label, Listing 7 zeigt ein Beispiel. Alle anderen Dateien sind entsprechend anzupassen. Nun ist es Zeit für den ersten Test, ob die Änderungen aktiv sind und sich Anwender mit dem v s f t p-server verbinden können. Zur Kontrolle empfiehlt sich parallel zum Starten des Servers in einem separaten Terminal- Fenster per tail -f /var/log/messages ein Blick auf die SELinux-Log-Datei. Der Verbindungsaufbau zum Server wird nicht gelingen. Ein Blick auf den relevanten Teil der Log-Datei offenbart die Ursache: Jun 20 11:58:26 grobi kernel: audit(\ 1150797506.789:32): avc: denied { \ search } for pid=12289 comm="vsftpd" \ name="vsftpd" dev=dm-0 ino=437179 \ scontext=root:system_r:ftpd_t tcontext=\ system_u:object_r:ftpd_conf_t tclass=dir Ein Prozess aus der Domäne ftpd_t hat versucht, ein Verzeichnis mit der Inode- Nummer 4 3 7 1 7 9 und dem Type f t p d _ c o n f _ t zu durchsuchen. Dafür existiert bisher noch keine Regel also ist der Zugriff nicht gestattet. Aus vorhandenen a v c : d e n i e d- M e l- dungen lassen sich mit dem Tool a u - d i t 2 a l l o w einfach entsprechende Regeln erzeugen: [root@grobi policy]# audit2allow -l -i /var/log/\ m e s s a g e s allow ftpd_t ftpd_conf_t:dir search; Es generiert im Terminal-Fenster aus allen a v c : d e n i e d-meldungen seit dem letzten Policy-Reload eine a l l o w- A n- weisung. Diese lässt sich bequem per C o p y & Paste in die passende Type-Enforcement-Datei eintragen. Nun s t e l l t man das System in den p e r m i s s i v e- M o d e, der zwar keine Aktionen unterbindet, allerdings nicht autorisierte Aktionen protokolliert. Die Prozedur beginnt von vorn: Man versucht den Server zu starten, schaut sich das Log- File an, erzeugt per a u d i t 2 a l l o w e n t- sprechende Regeln und lädt die neue Policy in den Kernel bis der Server problemlos funktioniert und im Log keine a v c : d e n i e d-meldungen mehr auftauchen. Dabei sollte man daran denken, dass es d o n t a u d i t- A n w e i s u n g e n geben kann, die sich allerdings durch den Aufruf von make enableaudit leicht aus der Policy verbannen lassen. Erscheinen auch danach keine Meldungen mehr im Log, sollte man das System zurück in den Enforcing-Mode bringen und den v s f t p d erneut starten. Er sollte einwandfrei funktionieren und in einer eigenen Domäne laufen, was sich so überprüfen lässt: [root@grobi policy]# ps -AZ grep vsftpd root:system_r:ftpd_t 12408 pts/3 00:00:00 vsftpd Der nächste Schritt dient der Optimierung einer funktionierenden Type-Enforcement-Datei mit Hilfe von Makros. a u d i t 2 a l l o w ist zwar eine nette Hilfe zum Entwickeln von Regelsätzen, allerdings sind diese meistens nicht sehr elegant und erlauben oft auch mehr als eigentlich notwendig ist. Konnte sich der f t p d nicht an den gewünschten Port binden, weil hierfür keine Regel existiert, so würde ein Aufruf von a u d i t 2 a l l o w folgendes Ergebnis bringen: allow ftpd_t reserved_port_t:tcp_socket name_bind; Es würde also der Zugang zu allen reservierten Ports (1 bis 1024) erlaubt. Die elegantere Varianten versieht jedoch über die Datei n e t _ c o n t e x t s d i e benötigten Ports mit einem Label und gestattet somit nur den Zugang zu diesen Ports. Listing 8 zeigt das Ergebnis einer beispielhaften myftpd.te. Im nächsten und letzten Teil des Tutorials stellt der Autor eine modulare, auf der Reference-Policy basierende, SELinux-Implementation vor. Das für Ende des Jahres erwartete Red Hat Enterprise Linux 5 (RHEL5) wird diese enthalten, Fedora Core 5 benutzt derzeit schon einen Technology Preview. (avr) T H O R STEN SCH E R F Thorsten Scherf arbeitet als Security- Experte für Red Hat EMEA und schreibt an einem Buch zu SELinux, dass Ende des Jahres erscheinen wird. L i te ra t u r [1]ˇThorsten Scherf; SELinux-Tutorial I; Gut bewacht; Mandatory Access Control für Linux-Systeme; i X 8 / 2006, S. 134 [2]ˇThorsten Scherf; SELinux; Sicherheit im Linux-Kernel; ISBN 3-937514-28-7, Open Source Press, München, circa Dezember 2006 x ix 9/2006 7