Für Fortgeschrittene

Nicht immer ist das Problem so leicht zu lösen wie im letzten Beispiel. In der Vergangenheit existierte ein beispielsweise ein Problem mit dem Programm Podsleuth, das bindet angeschlossene Ipods in das System einbindet und sie Programmen wie beispielswiese Banshee zur Verfügung stellt. In einer älteren Version von Podsleuth klappte das jedoch nicht und es kam immer zu einer Fehlermeldung sobald man einen Ipod an sein Linux-System angeschlossen hat (Listing 5).

type=1400 audit(1257521916.401:63): avc:  denied  { read write } for
pid=21391 comm="mono" name="sdc2" dev=tmpfs ino=3219332
scontext=system_u:system_r:podsleuth_t:s0
tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file
type=1400 audit(1257521916.401:64): avc:  denied  { open } for  pid=21391
comm="mono" name="sdc2" dev=tmpfs ino=3219332
scontext=system_u:system_r:podsleuth_t:s0
tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file
type=1400 audit(1257521916.402:65): avc:  denied  { getattr } for  pid=21391
comm="mono" path="/dev/sdc2" dev=tmpfs ino=3219332
scontext=system_u:system_r:podsleuth_t:s0
tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file
type=1400 audit(1257521916.402:66): avc:  denied  { ioctl } for  pid=21391
comm="mono" path="/dev/sdc2" dev=tmpfs ino=3219332
scontext=system_u:system_r:podsleuth_t:s0
tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file

Natürlich lässt sich das Problem nach der eben vorgestellten Methode beseitigen. Allerdings würde dies zu folgender Anweisung in der Policy führen:

allow podsleuth_t fixed_disk_device_t:blk_file↩
 { read write getattr open ioctl };

Hiermit erhielte die Podsleuth-Anwendung eine Art Freifahrt-Schein für sämtliche Zugriffe auf alle Block-Devices, nicht nur Wechselmedien wie den IPod. Sicherer wäre es der Anwendung lediglich Zugriff auf den IPod zu gewähren. In der Policy ist der Zugriff von Podsleuth bespielsweise auf Objekte vom Typ »removable_t« erlaubt. Die Rechte, die Podsleuth auf Geräte mit diesem File-Type besitzt, zeigt das Tool »sesearch« an:

# sesearch -A -s podsleuth_t -t removable_t
Found 2 semantic av rules:
allow podsleuth_t removable_t : dir { ioctl ↩
read getattr lock search open };
allow podsleuth_t removable_t : blk_file { ↩
ioctl read write getattr lock append open } ;

Anstatt der Ausgabe von »audit2allow« blind zu vertrauen, sollte das Ipod-Gerät besser über das richtige Label verfügen, sodass ein Zugriff von Podsleuth möglich ist. Nun ist aber üblicherweise der Geräte-Namen, unter dem das Linux-System ein Wechselmedium einbindet, nicht von vornherein bekannt. Ein weiteres Problem ist, dass man das Gerät natürlich nicht jedes Mal manuell mit einem Security-Label versehen möchte, wenn dieses an den Rechner angeschlossen wird. Als temporäre Lösung, bevor ein offizieller Fix für das Problem verfügbar war, bot sich folgende Möglichkeit an. Wieso die Aufgabe nicht einfach an den Udev-Dameon weiterleiten. Dieser kann das notwendige Kommando zum Labeln des IPod-Gerätes (»chcon -t removable_t /dev/sdX« ) automatisch ausführen, wenn es eingesteckt wird. Hiermit hätte man dann zwei Fliegen mit einer Klappe geschlagen. Zum einen kennt Udev den Geräte-Namen und zum anderen kann Udev auch beliebige Kommandos bei einem bestimmten Event, hier dem Anschluss des Ipods, ausführen. Eine mögliche Udev-Regel ist in Listing 6 zu sehen.

### Listing4: /etc/udev/rules.d/80-posleuth.rules
SUBSYSTEM!="block", GOTO="end_podsleuth"
ACTION!="add", GOTO="end_podsleuth"
ATTRS{vendor}=="Apple*", ATTRS{model}=="iPod*", \
        RUN+="/usr/bin/chcon -t removable_t /dev/%k"
LABEL="end_podsleuth"

Memory-Checks

Grundsätzlich unterscheidet SELinux zwischen geschützen (confined) und ungeschützen (unconfined) Prozessen. Erstere laufen in einer eigenen SE-Linux-Domäne, beispielsweise »httpd_t« . Alle anderen Prozesse befinden sich in der sogenannten »unconfined_t« -Domäne. Für Prozesse in dieser Domäne existieren keine Einschänkungen hinsichtlich der SE-Linux-Implementierung Type-Enforcement. Das heisst, ein Zugriff ist auf sämtliche Ressourcen möglich. Troztzdem funktionieren manche Applikationen, die in der Unconfined-Domäne laufen, nicht korrekt. Das Audit-Log zeigt dann beispielsweise einen Eintrag wie in Listing 7.

audit(1234106860.110:0): avc:  denied  { execmod } for  pid=4094
comm=firefox-bin path=/home/tscherf/.mozilla/plugins/libflashplayer.so
dev=hda9 ino=1056003 scontext=user_u:system_r:unconfined_t
tcontext=user_u:object_r:default_t tclass=file

Doch wie kann so ein Fehler überhaupt für eine Anwendung in der Unconfined-Domäne auftreten? Schließlich gibt es für Prozesse in dieser Domäne ja fast keine Einschränkungen. Die Antwort ist ganz einfach. Mit Fedora Core 5 wurden erstmals diverse Memory-Checks eingeführt. Sie prüfen auf ein merkwürdes Verhalten einer Applikation bezüglich ihrer Speichernutzung. Diese Tests gelten für sämtliche Prozesse, unabhängig davon, in welcher SE-Linux-Domäne diese gerade ablaufen. Der Grund hierfür liegt einfach darin, dass böswillige Angreifer Kontrolle über ein System erhalten, indem sie durch das Aussnutzen einer Sicherheitslücke, beliebigen Programmcode auf der betroffenen Maschine ausführen können. Hierfür kommen beispielsweise Buffer-Overflow-Attacken zum Einsatz. Diese versuchen bestimmte Speicherbereiche mit eigenem Programmcode (Shellcode) zu überschreiben. Wenn der betroffene Speicherbereich einer Applikation nun nicht nur beschreibbar, sondern auch ausführbar ist, kann ein Angreifer den eingeschleusten Programmcode ausführen und so beispielsweise eine Shell auf dem System starten. Läuft die Anwendung dann noch unter dem Benutzer-Kontext Root, so ist keine weitere Arbeit mehr notwendig, der Angreifer hat sein Ziel erreicht und die Kontrolle über das System erlangt.

Um dies zu verhindern, überprüfen einige Tests das Speicherverhalten von Applikationen. Diese Tests lassen sich systemweit über Booleans aktivieren oder deaktivieren. Die Default-Einstellungen sehen auf einem Fedora-System wie folgt aus:

# getsebool -a | grep allow_exec
allow_execheap --> off
allow_execmem --> on
allow_execmod --> off
allow_execstack --> on

Gerade beim Einsatz von Shared-Libraries tritt immer wieder der Fehler auf, das diese eine Text-Rellocation durchführen möchten. Hierbei markiert eine Anwendung einen bestimmten Speicerbereich als read/write, kopiert den gewünschten Programme-Code an diese Speicherstelle und ändert die Rechte dieses Speicherbereichs anschließend wieder auf read/exec. Solch eine Vorgehensweise ist meistens nicht notwendig und lässt sich durch den Einsatz anderer Programmiertechniken verhindern. Red-Hat-Entwickler Ulrich Drepper hat hierzu einen ausführlichen Blog-Eintrag verfasst [3].

Da das Boolean für diesen speziellen Memory-Check standardmäßig aktiv ist, funktioniert die Anwendung natürlich nicht wie gewohnt. Häufig schieben Anwender das Problem dann auf SE-Linux, obwohl der Fehler tatsächlich im schlechten Programmcode der Anwendung liegt. Tritt ein solcher Fehler auf, sollte man einen entsprechenden Bug-Report an den Hersteller senden. Vertraut man der Applikation und möchte nicht auf einen Fix warten, so lässt sich das Boolean, das für den genannten Memory-Check zuständig ist, mit folgendem Befehl deaktivieren:

setsebool -P allow_execmod=1

Hiermit erhält dann jedoch jede Applikation das Recht, Text-Relocations durchzuführen. Besser ist es, nur der ausgewählte Anwendung das notwendige Recht zu gewähren. Da dieser Fehler recht häufig vorkommt, haben die SE-Linux-Entwickler sogar einen eigenen SE-Linux-Typen für solch fehlerhafte Programme entwickelt: »textrel_shlib_t« . Mit Hilfe von »semanage« erhält die SE-Linux-Policy einen entsprechenden Eintrag für das fehlerhafte Programm:

semanage fcontext -a -t textrel_shlib_t /home/↩
tscherf/.mozilla/plugins/libflashplayer.so
restorecon -v /home/tscherf/.mozilla/plugins/↩
libflashplayer.so

Einen solchen Zugriff sollte man aber wirklich nur in Ausnahmefällen erlauben. Die Anwendung bekommt so Rechte zugesprochen, die eigentlich nicht notwendig sind. Zudem ensteht durch dieses zusätzliche Recht ein weiteres Sicherheitsrisiko, und dies soll SE Linux ja schließlich vermindern.