Product SiteDocumentation Site

14.4.4.3. Eine .te-Datei schreiben

Sehen Sie sich die beispiel.te-Datei an:
WEITERE SCHRITTE Die Makrosprache m4
Die SELinux-Entwickler verwendeten einen Makro-Befehlsprozessor, um die Richtlinien ordentlich zu strukturieren. Anstatt viele ähnliche allow-Anweisungen zu duplizieren, haben sie „Makrofunktionen“ erstellt, um eine Logik auf höherer Ebene zu verwenden, die auch zu viel leichter lesbaren Richtlinien führt.
Konkret wird m4 benutzt, um diese Regeln zu kompilieren. Es führt den umgekehrten Vorgang durch: es erweitert alle diese auf hoher Ebene befindlichen Anweisungen zu einer großen Datenbank von allow-Anweisungen.
Die SELinux-„Schnittstellen“ sind lediglich Makrofunktionen, die bei der Kompilierung durch einen Regelsatz ersetzt werden. Desgleichen sind einige Berechtigungen in Wirklichkeit Sätze von Berechtigungen, die bei der Kompilierung durch ihre Werte ersetzt werden. 
policy_module(myapp,1.0.0) 1

########################################
#
# Declarations
#

type myapp_t; 2
type myapp_exec_t;
domain_type(myapp_t)
domain_entry_file(myapp_t, myapp_exec_t) 3

type myapp_log_t;
logging_log_file(myapp_log_t) 4

type myapp_tmp_t;
files_tmp_file(myapp_tmp_t)

########################################
#
# Myapp local policy
#

allow myapp_t myapp_log_t:file { read_file_perms append_file_perms }; 5

allow myapp_t myapp_tmp_t:file manage_file_perms;
files_tmp_filetrans(myapp_t,myapp_tmp_t,file)

1

Das Modul muss mit seinem Namen und seiner Versionsnummer gekennzeichnet sein. Diese Anweisung ist obligatorisch.

2

Falls das Modul neue Typen einführt, muss es sie mit Anweisungen wie dieser festlegen. Zögern Sie nicht, so viele Typen zu erstellen, wie erforderlich sind, anstatt zu viele nutzlose Berechtigungen zu erteilen.

3

Diese Schnittstellen legen den Typ myapp_t als Prozess-Domain fest, die von jeder mit myapp_exec_t gekennzeichneten ausführbaren Datei benutzt werden sollte. Dies fügt diesen Objekten stillschweigend auch ein exec_type-Attribut hinzu, das seinerseits anderen Modulen ermöglicht, Berechtigungen zur Ausführung dieser Programme zu gewähren: zum Beispiel erlaubt das userdomain-Modul Prozessen mit den Domains user_t, staff_t und sysadm_t, sie auszuführen. Die Domains anderer eingeschränkter Anwendungen sind nicht berechtigt, sie auszuführen, es sei denn, die Regeln gewähren ihnen ähnliche Berechtigungen (dies trifft zum Beispiel auf dpkg mit seiner dpkg_t-Domain zu).

4

logging_log_file ist eine von den Referenzrichtlinien bereitgestellte Schnittstelle. Sie zeigt an, dass mit diesem Typ gekennzeichnete Dateien Protokolldateien sind, die die entsprechenden Regeln wahrnehmen können sollten (zum Beispiel dem Befehl logrotate Berechtigungen erteilen, sodass er sie handhaben kann).

5

Die allow-Anweisung ist die grundlegende Anweisung zur Genehmigung eines Vorgangs. Der erste Parameter ist die Prozess-Domain, der es erlaubt ist, den Vorgang auszuführen. Der zweite legt das Objekt fest, das ein Prozess der zuvor genannten Domain handhaben darf. Dieser Parameter hat die Form „type:class“, wobei type sein SELinux-Typ ist und class die Art des Objekts beschreibt (Datei, Verzeichnis, Socket, FIFO usw.). Schließlich beschreibt der letzte Parameter die Berechtigungen (die erlaubten Vorgänge).
Berechtigungen sind als Satz erlaubter Vorgänge festgelegt und entsprechen diesem Schema: { vorgang1 vorgang2 }. Jedoch können Sie auch Makros verwenden, die die nützlichsten Berechtigungen darstellen. Die Datei /usr/share/selinux/default/include/support/obj_perm_sets.spt listet sie auf.
Die folgende Website stellt eine recht vollständige Liste von Objektklassen und von Berechtigungen, die gewährt werden können, bereit. http://www.selinuxproject.org/page/ObjectClassesPerms
Jetzt müssen Sie lediglich den kleinsten Regelsatz finden, der erforderlich ist, damit die Anwendung oder der Dienst, auf die er abzielt, ordnungsgemäß funktionieren. Um dies zu erreichen, sollten Sie sich gut damit auskennen, wie die Anwendung funktioniert, und welche Art von Daten sie verarbeitet oder erzeugt.
Jedoch ist auch eine auf Erfahrung beruhende Vorgehensweise möglich. Nachdem die relevanten Objekte richtig gekennzeichnet sind, können Sie die Anwendung im permissive-Modus benutzen: die Vorgänge, die verboten würden, werden protokolliert, werden aber weiterhin ausgeführt. Durch eine Analyse der Protokolle können Sie nun die Vorgänge identifizieren, die erlaubt werden sollen. Hier ist ein Beispiel eines derartigen Protokolleintrags: 
avc:  denied  { read write } for  pid=1876 comm="syslogd" name="xconsole" dev=tmpfs ino=5510 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=fifo_file
Um diese Mitteilung besser verstehen zu können, gehen wir sie Schritt für Schritt durch.
Tabelle 14.1. Analyse eines SELinux-Ablaufs
Meldung Beschreibung
avc: denied Ein Vorgang wurde abgelehnt.
{ read write } Dieser Vorgang erforderte die Berechtigungen read und write.
pid=1876 Der Prozess mit der PID 1876 hat den Vorgang ausgeführt (oder hat versucht, ihn auszuführen).
comm="syslogd" Der Prozess war eine Ausführung des Programms syslogd.
name="xconsole" Das Zielobjekt hieß xconsole.
dev=tmpfs Das Gerät, auf dem sich das Zielobjekt befindet, ist ein tmpfs (ein im Arbeitsspeicher befindliches Dateisystem). Bei einer echten Platte würden Sie die Partition, die das Objekt enthält, sehen (zum Beispiel: „hda3“).
ino=5510 Das Objekt ist mit der Inode-Nummer 5510 bezeichnet.
scontext=system_u:system_r:syslogd_t:s0 Dies ist der Sicherheitskontext des Prozesses, der den Vorgang ausgeführt hat.
tcontext=system_u:object_r:device_t:s0 Dies ist der Sicherheitskontext des Zielobjekts.
tclass=fifo_file Das Zielobjekt ist eine FIFO-Datei.

Durch Betrachtung dieses Protokolleintrags ist es möglich, eine Regel zu erstellen, die diesen Vorgang erlauben würde. Zum Beispiel: allow syslogd_t device_t:fifo_file { read write }. Dieser Prozess kann automatisiert werden, und genau dies bietet der Befehl audit2allow (aus dem Paket policycoreutils). Diese Herangehensweise ist nur sinnvoll, wenn die verschiedenen Objekte bereits in Übereinstimmung mit den erforderlichen Einschränkungen richtig gekennzeichnet sind. In jedem Fall müssen Sie die erzeugten Regeln sorgfältig überprüfen und sie auf der Grundlage ihrer Kenntnis der Anwendung bewerten. Faktisch tendiert diese Herangehensweise dazu, mehr Berechtigungen zu erteilen als tatsächlich erforderlich sind. Die richtige Lösung besteht häufig darin, neue Typen zu erstellen und dann nur diesen Typen Berechtigungen zu gewähren. Es kommt auch vor, dass ein verweigerter Vorgang für die Anwendung keine Folgen hat. In diesem Fall kann es besser sein, einfach eine „dontaudit“-Regel hinzuzufügen, um einen Protokolleintrag zu vermeiden, obwohl eine Verweigerung stattgefunden hat.
ERGÄNZUNGEN Keine Rollen in den Richtlinien
Es mag seltsam erscheinen, dass bei der Erstellung neuer Regeln Rollen überhaupt nicht auftreten. SELinux verwendet nur die Domains um herauszufinden, welche Vorgänge erlaubt sind. Die Rolle kommt nur indirekt zum Tragen, indem sie es dem Benutzer erlaubt, zu einer anderen Domain zu wechseln. SELinux basiert auf einer Theorie, die Type Enforcement heißt, und der Typ ist das einzige Element, das bei der Gewährung von Berechtigungen zählt.