Probleme mit SE Linux finden und lösen

Aus ADMIN 02/2010

Tritt ein Fehler in der SE-Linux-Konfiguration eines Servers auf, fehlt vielen Admins einfach die Zeit, dem eigentlichen Problem auf den Grund zu gehen. Kurzerhand lassen sie die Maschine ohne aktivierten SE-Linux-Schutz weiterlaufen und verschieben die Problemlösung auf später. Dieser Artikel zeigt, dass es auch anders geht: Mit dem nötigen Know-How und einigen kleinen Tricks läuft jede Anwendung auch mit aktiviertem Schutzschild.

Kurzer Rückblick

Bei SE Linux handelt es sich um ein sehr flexibles Security-Framework auf Basis der Mandatory-Access-Control, das auf dem Flask-Forschungsprojekt der amerikanischen NSA-Behörde basiert [1]. Im Standard-Kernel ist es über die sogenannte Linux-Security-Module API (LSM) integriert. Alle Interaktionen zwischen so genannten Subjekten und Objekten sind durch eine gesonderte Security-Policy zu autorisieren. Die Anweisungen enthalten dabei jedoch keine Datei-, Prozess- oder Benutzernamen, stattdessen kommt ein abstrahiertes Model mit Security-Labeln zum Einsatz. Prozesse und Benutzer bekommen diese dynamisch zugewiesen, Dateien speichern das Label in den erweiterten Attributen. Es ist möglich, diese Policy zur Laufzeit des Systems zu ändern. Hierbei findet jedoch eine strikte Trennung von Policy und deren Durchsetzung statt. Für dieses Enforcement sind diverse Hooks im Linux-Kernel verantwortlich. Sie erweitern die klassischen Zugriffsrechte der Discretionary-Access-Control (DAC) um eine entsprechende MAC-Funktionalität. Über eine binäre Policy-Datei gelangen die eigentlichen Regelwerke in den Security-Server des Linux-Kernels.

SE Linux kennt drei Modi: Im Enforcing-Mode ist jeder einzelne Zugriff einer Kontrolle durch die SE-Linux-Policy ausgesetzt. Jeder Zugriff wird ausgewertet und gegebenfalls untersagt wenn es keine Regel gibt, die diesen Zugriff erlaubt. Im Permissive-Mode wird ebenfalls jeder Zugriff überwacht, allerdings kommt es nicht zur Durchsetzung der Regeln. Das bedeutet, dass ein Zugriff selbst dann stattfindet, wenn keine Regel den Zugriff explizit erlaubt. SE Linux schreibt für jeden nicht durch eine Regel erlaubten Zugriff einen Logeintrag, allerdings nur für beim ersten Mal. Alle weiteren Zugriffe unterdrückt das System stillschweigend. Im Disabled-Mode ist SE Linux überhaupt nicht aktiv. Es kommen lediglich Zugriffsentscheidungen auf Basis der DAC zum Einsatz. Dabei muss der Administrator daran denken, dass Dateien, die im Disabled-Mode erzeugt wurden, auch kein Security-Label bekommen.

Zur Erweiterung des klassischen Discretionary-Access-Control-Modells stellt SE Linux verschiedene Implementierungen zur Verfügung:

• Type-Enforcement (TE)

• Role-based-Access-Control (RBAC)

• Multi-level-Security (MLS)

• Multi-Category-Security (MCS)

Die wichtigste Implementierung ist hierbei das Type-Enforcement. Es regelt den Zugriff von einem Subjekt, beispielsweise einem Prozess, auf die diversen Objekte, beispielsweise Dateien oder Verzeichnisse. Allerdings gibt es eine Vielzahl unterschiedlicher Objekte. Zu ihnen diesen zählen neben Dateien und Verzeichnissen beispielsweise auch Netzwerk-Ports. Die den Subjekten und Objekten zugewiesenen Security-Label sind auch unter dem Namen Domäne oder Typ bekannt. Allgemein ausgedrückt regelt das Type-Enforcement, welche Domäne auf welchen Typen zugreifen darf.

Genau hier liegt oft das Problem. Besitzt ein Objekt nicht den richtigen Typ, ist der Zugriff hierauf nicht möglich wenn das System sich im SE-Linux Enforcing-Mode befindet. Ein Log-Eintrag in der Datei »/var/log/audit/audit.log« sieht dann zum Beispiel wie in Listing 1 aus.

01 type=AVC msg=audit(1217917079.027:14267): avc:  denied  { getattr } for
02 pid=10054 comm="httpd" path="/var/www/html/index.html" dev=dm-2 ino=1974309
03 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:user_tmp_t:s0
04 tclass=file

Der Log-Typ bestimmt hierbei den Ursprung der Nachricht. AVC steht für Access-Vector-Cache und ist ein Teil des Security-Servers im Kernel, der Zugriffsvektoren zwischenspeichert. Der Log-Typ »SYSCALL« und bezieht sich beispielsweise auf Events, die das Audit-Subsystem festhält, wenn es um das Monitoring von System-Calls geht. Mit Hilfe von »ausearch -m Typ« ist ein Zugriff auf einen ganzen bestimmten Log-Typen möglich. Der nächste Eintrag gibt den Zeitpunkt des Events in Unix-Zeit an. Mit Hilfe von »date -d @Unix-Zeit« lässt sich diese leicht in ein menschenlesbares Format verwandeln. Im Anschluss erfolgt die genaue Art der Log-Meldung, also ob es sich um eine Deny-Meldung handelt oder nur um eine Information, beispielsweise ob die SE-Linux-Policy neu geladen wurde oder ob sich der SE-Linux-Mode geändert hat.

Die nächsten beiden Angaben (»pid« und »comm«) bestimmen die Herkunft der Fehlermeldung, hier also einen Webserver-Prozess mit seiner Prozessnummer. Das Objekt der Begierde folgt unmittelbar in Form eines Dateipfads (»path«), Device (»dev«) und Inode-Nummer (»ino«). Da für die Interaktion zwischen Prozess und Datei jedoch die Security-Label die größte Bedeutung haben, sind diese natürlich ebenfalls aufgeführt. »scontext« steht hierbei für den Source-Context des Webservers, »tcontext« für den Target-Context der Datei. Zum Abschluss gibt die Logmeldung noch Auskunft über den genauen Objekt-Typen. Hiermit ist die Unterscheidung von Objekten mit gleichem Security-Label möglich.

Seit einiger Zeit existiert für diese doch recht kryptischen Logeinträge eine Alternative. Fedora Core hat mit Version 6 den Setroubleshoot-Daemon [2] eingeführt. Bei dieser Gnome-Anwendung handelt es sich um ein plugin-basiertes Tool mit einer Vielzahl unterschiedlicher Regelsätze, die abhängig vom stattgefundenen Event dem Benutzer mit Rat und Tat zur Seite steht. Auch lassen sich unterschiedliche Benachrichtiguns- Mechanismen einstellen. Beispielsweise kann der Benutzer veranlassen, dass er eine Mail erhält, wenn das SE-Linux-System eine nicht erlaubte Aktion unterbindet. Benutzer mit einem grafischen Desktop haben die Möglichkeit, ein Sealert-Applet in Ihre Taskbar einzubinden um sich direkt über ein Pop-Up über aktuelle Meldungen des Setroubleshoot-Daemons zu informieren. Die Logeinträge der Anwendung finden sich in der Datei »/var/log/messages« (Listing 2).

Abbildung 1: Der grafische SE-Linux-AVC-Browser liefert Hilfestellung zu möglichen Problemen.

01 Aug  5 08:18:07 tiffy setroubleshoot: SELinux is preventing the httpd from
02 using potentially mislabeled files (/var/www/html/index.html). For complete
03 SELinux messages. run sealert -l 774df3c6-badf-4f42-b1f3-e8ff94897d6b

Folgt der Benutzer dem Rat des Setroubleshoot-Daemons und ruft den Befehl »sealert« mit den angegebenen Parameter auf, so erhält er eine detailierte Übersicht über das aufgetretene Problem und Informationen darüber, wie er das Problem beheben kann (Listing 3).

01 [root@tiffy ~]# sealert -l 774df3c6-badf-4f42-b1f3-e8ff94897d6b
02 Summary:
03 
04 SELinux is preventing the httpd from using potentially mislabeled files
05 (/var/www/html/index.html).
06 
07 Detailed Description:
08 
09 [SELinux is in permissive mode, the operation would have been denied but was
10 permitted due to permissive mode.]
11 
12 SELinux has denied httpd access to potentially mislabeled file(s)
13 (/var/www/html/index.html). This means that SELinux will not allow httpd to
14 use these files. It is common for users to edit files in their home directory
15 or tmp directories and then move (mv) them to system directories. The problem
16 is that the files end up with the wrong file context which confined applications
17 are not allowed to access.
18 
19 Allowing Access:
20 
21 If you want httpd to access this files, you need to relabel them using
22 restorecon -v '/var/www/html/index.html'. You might want to relabel the entire
23 directory using restorecon -R -v '/var/www/html'.
24 Additional Information:
25 
26 Source Context                system_u:system_r:httpd_t:s0
27 Target Context                unconfined_u:object_r:user_tmp_t:s0
28 Target Objects                /var/www/html/index.html [ file ]
29 Source                        httpd
30 Source Path                   /usr/sbin/httpd
31 Port                          <Unknown>
32 Host                          tiffy.tuxgeek.de
33 Source RPM Packages           httpd-2.2.8-3
34 Target RPM Packages
35 Policy RPM                    selinux-policy-3.3.1-79.fc9
36 Selinux Enabled               True
37 Policy Type                   targeted
38 MLS Enabled                   True
39 Enforcing Mode                Permissive
40 Plugin Name                   home_tmp_bad_labels
41 Host Name                     tiffy.tuxgeek.de
42 Platform                      Linux tiffy.tuxgeek.de 2.6.25.9-76.fc9.i686 #1
43 SMP
44                               Fri Jun 27 16:14:35 EDT 2008 i686 i686
45 Alert Count                   1
46 First Seen                    Tue Aug  5 08:17:59 2008
47 Last Seen                     Tue Aug  5 08:17:59 2008
48 Local ID                      774df3c6-badf-4f42-b1f3-e8ff94897d6b
49 Line Numbers

Diese Meldung weist schon auf das eigentliche Problem hin. Die Datei »/var/www/html/index.html« besitzt das falsche Security-Label und somit ist ein Zugriff des Webservers hierauf nicht möglich. Eine mögliche Lösung ist ebenfalls aufgeführt:

# restorecon -R -v /var/www/html
# ls -ldZ /var/www/html
drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 /var/www/html

Der Aufruf von restorecon sorgt dafür, dass jedes Objekt im Verzeichnis »/var/www/html« das richtige Label bekommt. Danach sollte der Zugriff wieder funktionieren. Aber was ist in diesem Zusammenhang eigentlich das richtige Label? Es bezieht sich darauf, welches Label diese Datei in der binären Policy besitzt. Mit Hilfe von »semanage« bekommt der Admin schon im Vorfeld raus, wie das hinterlegte Label lautet:

# semanage fcontext -l | grep /var/www
/var/www(/.*)?          all files  system_u:object_r:httpd_sys_content_t:s0

Was soll man aber machen, um den Zugriff auf ein Objekt zu erlauben, das noch über keinen Eintrag in der Policy verfügt? In einem solchen Fall ist die Datei mit dem gewünschten Label in die Policy aufzunehmen. Dies funktioniert ebenfalls mit dem Tool »semanage«. Angenommen das Webserver-Documentroot befindet sich unterhalb von »/www«, so ist natürlich auch dieses Verzeichnis, mit allen darin enthaltenen Dateien, mit dem Label »httpd_sys_content_t« zu versehen. Der folgende Aufruf fügt der Policy einen entsprechenden Eintrag hinzu:

# semanage fcontext --add --type public_content_rw_t '/www(/.*)?'
# restorecon -Rv /www

Der abschließende Aufruf von »restorecon« setzt das neue Label auf dem Verzeichnis und allen darin enthaltenen Dateien.

Genauso wie der Zugriff auf Dateien oder Verzeichnisse anhand eines Security-Label stattfindet, geschieht es auch mit Netzwerk-Ports. Das Tool »semanage« bindet das Security-Label an einen Port:

semanage port -a -t http_port_t -p tcp 8000

Hier wird der TCP-Port 8000 mit dem Label »httpd_port_t« versehen. Verifizieren lässt sich dies mit dem erneuten Aufruf von »semanage«:

# semanage port -l |grep http_port_t http_port_t
tcp      80, 443, 488, 8000, 8008, 8009

Log aktivieren

Manchmal funktioniert eine Anwendung im Enforcing-Mode nicht, die Logdatei zeigt jedoch keine Fehlermeldung an. Wie kann das sein? Die Antwort ist ganz einfach. In der Policy exitsieren so genannte Dontaudit-Regeln, die einen Zugriff unterbinden, ihn aber nicht loggen. Das ist meistens ganz praktisch, wenn zum Beispiel eine Anwendung Aktionen durchführen will, die für eine korrekte Funktion aber nicht notwendig sind. Da SE Linux nach dem ,,Principle of least Privilege`` arbeitet, sind solche Zugriffe nicht erlaubt. Natürlich soll aber auch nicht jedes Mal ein Eintrag im Log erfolgen.

Nun ist dieses Verhalten aber gerade bei der Suche nach einem Fehler nicht wünschenswert. Bestes Beispiel hierfür ist ein Problem im aktuellen SE-Linux-Paket von Red Hat Enterprise Linux (RHEL5) in Kombination mit einem installierten Postfix-Server. Hier greift ein Prozess aus der SE-Linux-Domäne »postfix_postdrop_t« auf eine Socket-Datei vom SE-Linux-Typ »sendmail_t« zu. Doch dieser Zugriff ist verboten. Die folgende Regel in der Policy verhindert jedoch auch einen entsprechenden Logeintrag:

dontaudit postfix_postdrop_t sendmail_t:unix_stream_socket { getattr read write ioctl };

Mit einem kleinen Trick ist es jedoch möglich, sämtliche Dontaudit-Anweisungen aus der Policy zu entfernen. Das Tool Semodule ist hier des Rätsels Lösung:

semodule -DB

Anschließend finden sich alle AVC-Deny-Meldungen im Log wieder. Mit Hilfe dieser Meldungen ist es dann nicht schwer den Fehler zu beseitigen. Hierfür reicht es, 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 Anwender die Ausgabe der Logdatei »/var/log/audit/audit.log« durch dieses Tool, erhält er die notwendigen Regeln, um den Zugriff von »postfix_postdrop_t« auf »sendmail_t« zu gestatten (Listing 4).

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-Dameon nicht plötzlich mit Logeinträgen überflutet wird, sollte man nach der Fehlersuche, der Policy die eben entfernten Dontaudit-Anweisungen mit dem Befehle »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 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).

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 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.

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*", RUN+="/usr/bin/chcon -t removable_t /dev/%k"
05 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.

01 audit(1234106860.110:0): avc:  denied  { execmod } for  pid=4094
02 comm=firefox-bin path=/home/tscherf/.mozilla/plugins/libflashplayer.so
03 dev=hda9 ino=1056003 scontext=user_u:system_r:unconfined_t
04 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.

Fazit

Anstatt auf den zusätzlichen Schutz durch SE Linux zu verzichten, sollte der verantwortliche Admin sich die Zeit nehmen, das notwendige SE Linux Know-How zu erwerben, um mögliche Probleme selbst zu lösen. Zur Fehlersuche sind die Logs des Audit-Daemons unverzichtbar. Um diese zentral zu verwalten bietet sich im Unternehmens-Einsatz ein grafisches Frontend wie Prewikka an. Mit dem passenden Plugin, »audispd-prelude«, schicken dann sämtliche Systeme Ihre audit-Meldungen an das Prewikka-System. Über ein komfortables Webinterface lassen sich diese dann nachverfolgen. Mögliche Fehlerquellen sind so schnell identifiziert und mit den hier vorgestellten Techniken schnell behoben. (ofr)

Infos

[1] NSA Selinux Projektseite: [http://www.nsa.gov/research/selinux/]

[2] Setroubleshoot-Tool des Fedora-Projekts: [http://fedorahosted.org/setroubleshoot/]

[3] Ulrich Drepper über SELinux Memory Protection Checks: [http://people.redhat.com/drepper/selinux-mem.html]