Nun ist diese Diskretion aber gerade bei der Suche nach einem Fehler nicht wünschenswert. Bestes Beispiel hierfür ist ein Problem im aktuellen SELinux-Paket von Red Hat EnterpriSELinux (RHEL5) in Kombination mit einem installierten Postfix-Server. Hier greift ein Prozess aus der SELinux-Domäne
»postfix_postdrop_t
«
auf eine Socketdatei vom SELinux-Typ
»sendmail_t
«
zu. Doch dieser Zugriff ist verboten. Die folgende Regel in der Policy verhindert jedoch einen entsprechenden Logeintrag:
dontaudit postfix_postdrop_t sendmail_t:unix_stream_socket { getattr read write ioctl };
Mit einem kleinen Trick ist es dennoch möglich, alle Dontaudit-Anweisungen aus der Policy zu entfernen. Das Tool Semodule führt hier zum Ziel:
semodule -DB
Danach finden sich alle AVC-Deny-Meldungen im Log wieder. Mit diesen Meldungen ist es nicht schwer, den Fehler zu beseitigen. Es reicht, ein neues Policy-Modul zu generieren, das den gewünschten Zugriff erlaubt. Das Policy-Modul mit allen notwendigen Anweisungen lässt sich mit dem Tool
»audit2allow
«
erzeugen. Leitet der Admin die Ausgabe der Logdatei
»/var/log/audit/audit.log
«
durch dieses Tool, erhält er die nötigen Regeln, um den Zugriff von
»postfix_postdrop_t
«
auf
»sendmail_t
«
zu gestatten (
Listing 4
).
Listing 4
audit2allow
01 # cat /var/log/audit/audit.log|audit2allow -l -R 02 03 gen_require(` 04 type sendmail_t; 05 type postfix_postdrop_t; 06 ') 07 08 #============= postfix_postdrop_t ============== 09 allow postfix_postdrop_t sendmail_t:unix_stream_socket { getattr read write ioctl };
Speichert er die Ausgabe in einer Datei
»mypostfix.te
«
, kann er im Anschluss aus dieser Datei das neue Policy-Modul bauen und dem Regelwerk hinzufügen:
make -f /usr/share/selinux/devel/Makefile semodule -i mypostfix.pp
Damit jedoch nicht unnötig viele Meldungen in der Logdatei auftauchen und der Setroubleshoot-Daemon nicht plötzlich mit Logeinträgen überflutet wird, sollte der Admin nach der Fehlersuche der Policy die eben entfernten Dontaudit-Anweisungen mit dem Befehl
»semodule -B
«
wieder hinzufügen.
Nicht immer ist das Problem so leicht zu lösen wie im letzten Beispiel. In der Vergangenheit gab es beispielsweise ein Problem mit dem Programm Podsleuth, das angeschlossene I-Pods in das System einbindet und sie Programmen wie etwa Banshee zur Verfügung stellt. In einer älteren Version von Podsleuth klappte das jedoch nicht und es kam zu einer Fehlermeldung, sobald ein I-Pod an das Linux-System angeschlossen wurde ( Listing 5 ).
Listing 5
audit.log mit Podsleuth
01 type=1400 audit(1257521916.401:63): avc: denied { read write } for 02 pid=21391 comm="mono" name="sdc2" dev=tmpfs ino=3219332 03 scontext=system_u:system_r:podsleuth_t:s0 04 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file 05 type=1400 audit(1257521916.401:64): avc: denied { open } for pid=21391 06 comm="mono" name="sdc2" dev=tmpfs ino=3219332 07 scontext=system_u:system_r:podsleuth_t:s0 08 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file 09 type=1400 audit(1257521916.402:65): avc: denied { getattr } for pid=21391 10 comm="mono" path="/dev/sdc2" dev=tmpfs ino=3219332 11 scontext=system_u:system_r:podsleuth_t:s0 12 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file 13 type=1400 audit(1257521916.402:66): avc: denied { ioctl } for pid=21391 14 comm="mono" path="/dev/sdc2" dev=tmpfs ino=3219332 15 scontext=system_u:system_r:podsleuth_t:s0 16 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 Freifahrtschein für sämtliche Zugriffe auf alle Blockdevices, nicht nur Wechselmedien wie den I-Pod selbst. Sicherer wäre es, der Anwendung lediglich Zugriff auf den I-Pod zu gewähren. In der Policy ist der Zugriff von Podsleuth beispielsweise auf Objekte vom Typ
»removable_t
«
erlaubt. Die Rechte, die Podsleuth auf Geräte mit diesem File-Typ 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 } ;
Statt der Ausgabe von
»audit2allow
«
blind zu vertrauen, sollte das I-Pod-Gerät besser über das richtige Label verfügen, sodass ein Zugriff von Podsleuth möglich ist. Nun ist aber üblicherweise der Gerätename, unter dem das Linux-System ein Wechselmedium einbindet, nicht von vornherein bekannt. Ein weiteres Problem ist, dass man das Gerät gewiss nicht jedes Mal manuell mit einem Security-Label versehen möchte, um es an den Rechner anzuschließen.
Als temporäre Lösung, noch 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-Daemon weiterleiten. Dieser kann das notwendige Kommando zum Labeln des I-Pod-Geräts (
»chcon -t removable_t /dev/sdX
«
) automatisch ausführen, wenn es eingesteckt wird. Hiermit hätte der Benutzer zwei Fliegen mit einer Klappe geschlagen. Zum einen kennt Udev den Gerätenamen, zum anderen kann Udev auch beliebige Kommandos bei einem bestimmten Event, hier dem Anschluss des I-Pod, ausführen. Eine passende Udev-Regel zeigt
Listing 6
.
Listing 6
audit.log beim Hotpluggen
01 ### Listing4: /etc/udev/rules.d/80-posleuth.rules 02 SUBSYSTEM!="block", GOTO="end_podsleuth" 03 ACTION!="add", GOTO="end_podsleuth" 04 ATTRS{vendor}=="Apple*", ATTRS{model}=="iPod*", \ 05 RUN+="/usr/bin/chcon -t removable_t /dev/%k" 06 LABEL="end_podsleuth"