SELinux - kanonische Methode zum automatischen Anwenden eines Kontexts bei der Dateierstellung

Nach meinem derzeitigen Verständnis müssen Sie restoreconden gewünschten Kontext manuell auf eine neu erstellte Datei oder ein neu erstelltes Verzeichnis anwenden, es sei denn, Sie sind mit dem Kontext zufrieden, den es von seinem übergeordneten Verzeichnis erbt.

Ich frage mich, ob es möglich ist, einen Kontext basierend auf seinem Pfad automatisch auf die Erstellung anzuwenden, ohne ausgeführt werden zu müssen restorecon.

Ich habe ein bisschen gegoogelt und diesen Beitrag von Dan Walsh gefunden, in dem er erwähnt restorecond, inotifywie sich der Kontext bei der Erstellung ändert. Er weist auch auf das offensichtliche Problem damit hin (Rennbedingung). Ist dies die einzige Möglichkeit, das Problem der erneuten Kontextualisierung automatisch zu lösen, falls ein Kind seinen Kontext nicht vom übergeordneten Verzeichnis erben sollte?

Ein Problem ist, dass restorecondEinträge nicht so behandelt werden, wie /etc/selinux/targeted/contexts/files/file_contextskeine regulären Ausdrücke, und dass sie nicht rekursiv funktionieren und daher so /etc/selinux/restorecond.confetwas nicht enthalten können

/var/www(/.*)?/logs(/.*)?

oder

/var/www/*

oder auch

/var/www/*/logs

Gibt es eine Möglichkeit, dieses Problem zu umgehen?

BEARBEITEN:

Gemäß der Antwort von @ Michael sollte dies OOTB funktionieren, wenn eine entsprechende Regel existiert, aber nicht:

# rm -rf /var/www/foo
# semanage fcontext -a -t httpd_log_t '/var/www/foo/logs'
# grep '/var/www.*logs' /etc/selinux/targeted/contexts/files/file_contexts*
/etc/selinux/targeted/contexts/files/file_contexts:/var/www(/.*)?/logs(/.*)?    system_u:object_r:httpd_log_t:s0
/etc/selinux/targeted/contexts/files/file_contexts.local:/var/www/foo/logs    system_u:object_r:httpd_log_t:s0
# matchpathcon /var/www/foo/logs
/var/www/foo/logs       system_u:object_r:httpd_log_t:s0
# mkdir -p /var/www/foo/logs
# touch /var/www/foo/logs/quux
# ls -alZ /var/www/foo/logs*
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_content_t:s0 .
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_content_t:s0 ..
-rw-r--r--. root root unconfined_u:object_r:httpd_sys_content_t:s0 quux
# restorecon -vR /var/www/foo
restorecon reset /var/www/foo/logs context unconfined_u:object_r:httpd_sys_content_t:s0->unconfined_u:object_r:httpd_log_t:s0
restorecon reset /var/www/foo/logs/quux context unconfined_u:object_r:httpd_sys_content_t:s0->unconfined_u:object_r:httpd_log_t:s0

Der Kernel führt das folgende Verfahren aus, um den Dateityp einer neu erstellten Datei zu bestimmen.

• In der Richtlinie ist eine bestimmte Dateiübergangsregel vorhanden. Wenden Sie dies also an.
• Lassen Sie die neu erstellte Datei den Typ des übergeordneten Verzeichnisses annehmen.

In den allermeisten Fällen erben neue Dateien den Typ der übergeordneten Verzeichnisse. Manchmal ist dies nicht wünschenswert. Daher kann ein Richtlinienschreiber Regeln erstellen, die auf den Bedingungen basieren, wer die Kennzeichnung vornimmt und wo, um zu einem anderen Typ zu wechseln.

Dies wird in der Richtlinie mit der type_transitionAnweisung gesteuert , obwohl normalerweise ein Richtlinienschreiber filetrans_patternstattdessen das Makro aufruft.

Im Kernel basieren diese Entscheidungen nicht auf Pfaden, sondern auf Typen (obwohl in neueren Richtlinien eine geringfügige Ausnahme besteht).

Eine Regel sieht normalerweise so aus.

type_transition httpd_t var_log_t:file httpd_var_log_t;

In diesem Beispiel besagt die Regel, dass. Wenn der Prozess / Benutzer, der die Dateierstellung durchführt, httpd_tund das Verzeichnis, in dem das Objekt erstellt wird, sind var_log_tund das Objekt als klassifiziert ist file, muss die neue Datei als gekennzeichnet werden httpd_var_log_t.

Dies hat natürlich eine Reihe von Einschränkungen. Ein gutes Beispiel hierfür ist die Bedingung, wenn Sie .htaccess-Dateien in Apache (in / var / www / html) erstellen. In diesem Beispiel gilt die Standardrichtlinie zum Erstellen eines Dateityps mit demselben Typ wie das übergeordnete Verzeichnis. In Wirklichkeit ist der richtige Dateityp jedoch httpd_sys_htacess_tnicht der Standardtyp httpd_sys_content_t.

Dies war mehrere Jahre lang ein bekanntes Problem und wurde schließlich behoben, indem Richtlinienschreibern gestattet wurde, den Dateinamen anzugeben, für den der Übergang in Richtlinien gilt. Leider sind diese Funktionen in EL6 nicht verfügbar.

In Ihrem speziellen Fall gibt es - wie Sie bereits erwähnt haben - einige Problemumgehungen, die die Wiederherstellungssekunde betreffen. Abgesehen davon sollten Sie Ihre Daten idealerweise in verschiedene Typen aufteilen, indem Sie sie in separate Unterverzeichnisse einfügen, in denen das Unterverzeichnis ein ausreichend beschrifteter Typ ist. Wenn dies immer noch nicht möglich ist und eine Wiederherstellungsbedingung nicht möglich ist, besteht die einzige Lösung darin, die Datei nach ihrer Erstellung nachträglich in der Datei auszuführen.

Sogar die "neueren" benannten Filetrans haben Probleme, da sie letztendlich kein Globbing oder Regex unterstützen, was ihre Funktionalität stark auf spezifisch gut benannte Dateien (wie .htaccess) beschränkt.

restoreconDerzeit gibt es keinen so flexiblen In-Kernel-Mechanismus wie seine regulären Ausdrücke, um Dateien bis zu diesem Grad korrekt zu kennzeichnen.

Das Problem der korrekten Beschriftung bei der Dateierstellung wurde in Fedora 16 mit einer Funktion namens Dateinamenübergang behoben (obwohl Sie sie auch als "benannte Dateiübergänge" finden können), deren Definition im Wesentlichen Folgendes besagt:

Mit den Funktionen für Dateinamenübergänge können Richtlinienschreiber Regeln schreiben, die den Dateinamen und nicht den Dateipfad berücksichtigen. Dies ist der Basisname des Dateipfads. Da der Kernel zum Zeitpunkt der Objekterstellung die Bezeichnung des enthaltenen Verzeichnisses, die Bezeichnung des Prozesses, der das Objekt erstellt, und den Objektnamen kennt. Wir können jetzt eine Richtlinienregel schreiben, die besagt, dass die Datei mit der Bezeichnung resolv.conf versehen werden soll, wenn ein Prozess ohne Einschränkung_t eine Datei mit dem Namen resolv.conf in einem Verzeichnis mit der Bezeichnung etc_t erstellt.

Es ist bekannt, dass die Art und Weise, wie ein Objekt zur Erstellungszeit beschriftet wird, abhängig vom Erstellungsprozess des Objekts variieren kann ( cpvs.mv ist ein gutes Beispiel). Die Standardmethode zum Beschriften eines Objekts ist die Vererbung: Das Objekt erhält die Bezeichnung des übergeordneten Verzeichnisses.

Dies ist zwar praktisch, aber nicht immer korrekt, und der Systemadministrator muss die Situation manuell mit (einer Kombination aus) restorecon+ restorecond+ korrigieren semanage fcontext -a -t.

Dies ist das Problem, das Name File Transitions zu beheben versucht, indem Sie es zulassen

[...] Richtlinienschreiber haben die Möglichkeit, dies zu überschreiben, indem sie eine Regel in eine Richtlinie schreiben, die besagt, dass das Objekt c_t erstellt wird, wenn ein Prozess vom Typ a_t ein Objekt der Klasse "file" in einem Verzeichnis mit der Bezeichnung b_t erstellt.

Offensichtlich existieren benannte Dateiübergänge für benutzerdefinierte Speicherorte nicht. Sie könnten bereits vorhandene finden, zum Beispiel mit:

# sesearch -ASCT -s unconfined_t | grep Found
...
Found XX named file transition filename_trans:
...

Um Ihr Problem zu beheben, müssen Sie im Voraus wissen, welcher Benutzer (SELinux-Benutzer) welche Datei / welches Verzeichnis und wo erstellt, und anschließend eine benutzerdefinierte Richtlinie mit einem Dateiübergang schreiben. Es gibt einige Beispiele auf der Fedora-Projekt-Wiki-Seite, die ich oben verlinkt habe.

Dies ist kein Problem, Sie nähern sich nur aus der falschen Richtung.

Wenn Sie Ihre eigenen Dateikontexte möchten, erstellen Sie einfach Ihre eigenen mit semanage fcontext. Dies wird akzeptiert reguläre Ausdrücke.

Hier ist ein allgemeines Beispiel, mit dem das Verzeichnis verschoben wird, aus dem Apache Dateien bereitstellt :

semanage fcontext -a -t httpd_sys_content_t "/volume1/web(/.*)?"

Fühlen Sie sich frei, dies an Ihre eigenen Bedürfnisse anzupassen.