High Availability lässt sich heute mit günstiger Hardware und einer großen Auswahl an kommerzieller sowie freier Software realisieren. ADMIN erklärt die ... (mehr)

Log aktivieren

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.

Für Fortgeschrittene

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"
comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023