|
|
| (100 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt) |
| Zeile 1: |
Zeile 1: |
| | | #WEITERLEITUNG [[Linux/SELinux/04/07_Kontexte]] |
| = Schritt 1.1: Struktur und Auslesen des Sicherheitskontexts =
| |
| | |
| == Kontexte / Labels ==
| |
| Im SELinux-System (Security-Enhanced Linux) wird der Zugriff auf Ressourcen nicht auf Grundlage der Eigentümerrechte gesteuert (wie im klassischen DAC-Modell), sondern auf Grundlage von '''Sicherheitskontexten'''. Ein Kontext ist ein spezielles Label, das jedem Systemobjekt zugewiesen wird (Dateien, Prozessen, Netzwerkports).
| |
| | |
| Datei-Labels werden direkt im Dateisystem als '''erweiterte Dateiattribute (Extended Attributes oder xattr)''' gespeichert. SELinux verwendet dabei das Attribut mit dem Namen <code>security.selinux</code>.
| |
| | |
| Auf das Vorhandensein erweiterter Attribute weist ein Punkt am Ende der Attributanzeige bei Verwendung von <code>ls -l</code> hin:
| |
| <code># ls -l /var/log/apt/
| |
| total 388
| |
| -rw-r--r--. 1 root root 43628 Mar 21 12:52 eipp.log.xz
| |
| -rw-r--r--. 1 root root 54225 Mar 21 12:52 history.log
| |
| -rw-r-----. 1 root adm 283440 Mar 21 12:52 term.log</code>
| |
| ----
| |
| | |
| == Anatomie der Kontextzeichenfolge ==
| |
| Das vollständige Label eines Sicherheitskontexts besteht aus vier (manchmal fünf) durch Doppelpunkte getrennten Elementen. Die typische Struktur sieht wie folgt aus:
| |
| <code>user : role : type : level</code>
| |
| | |
| == Bedeutung des Typs (Type) in der Targeted Policy ==
| |
| In den meisten modernen Distributionen (RHEL, CentOS, Fedora, Debian) wird standardmäßig die Policy '''Targeted''' verwendet. In diesem Modell liegt der Schwerpunkt auf '''Type Enforcement (TE)''' — der erzwungenen Zuweisung von Typen.
| |
| ----'''Zur Analyse von Sicherheitslabels (Kontexten) werden Standard-Linux-Werkzeuge mit der zusätzlichen Option''' <code>-Z</code> '''verwendet.'''
| |
| | |
| Die Option <code>-Z</code> wird von fast allen grundlegenden Befehlen unterstützt:
| |
| | |
| * <code>cp -Z</code> — kopiert eine Datei und weist ihr sofort den korrekten Kontext des Zielverzeichnisses zu (den Standardkontext des Verzeichnisses). Im Gegensatz dazu bewahrt der Parameter <code>-a</code> den ursprünglichen Kontext der Datei.
| |
| * <code>mkdir -Z</code> — erstellt ein Verzeichnis, das sofort den Standardkontext erhält (ohne dass <code>restorecon</code> ausgeführt werden muss).
| |
| * Außerdem die Anzeigeprogramme: <code>ls -Z</code> (Dateien), <code>ps -Z</code> (Prozesse), <code>id -Z</code> (Benutzer).
| |
| | |
| ----
| |
| | |
| === Kontext von Dateien und Verzeichnissen ===
| |
| Zum Anzeigen des Kontexts von Dateien wird der Befehl <code>ls -Z</code> verwendet.
| |
| <code>ls -Z /var/log</code>
| |
| Ausgabe:
| |
| <code>system_u:object_r:var_log_t:s0 README
| |
| system_u:object_r:var_log_t:s0 alternatives.log
| |
| system_u:object_r:httpd_log_t:s0 apache2
| |
| system_u:object_r:apt_var_log_t:s0 apt
| |
| system_u:object_r:auditd_log_t:s0 audit
| |
| system_u:object_r:faillog_t:s0 btmp
| |
| system_u:object_r:var_log_t:s0 cloud-init-output.log
| |
| system_u:object_r:var_log_t:s0 cloud-init.log
| |
| system_u:object_r:var_log_t:s0 dpkg.log</code>
| |
| | |
| === Interpretation der Typen: ===
| |
| Bei der Analyse von Kontexten sollte man auf die Suffixe der Typen achten, da diese häufig auf ihren Zweck hinweisen:
| |
| | |
| * <code>_t</code>: Allgemeines Suffix für Typen (type).
| |
| * <code>_exec_t</code>: Typ, der ausführbaren Dateien (Binärdateien) zugewiesen wird.
| |
| * <code>_conf_t</code>: Typ für Konfigurationsdateien.
| |
| * <code>_log_t</code>: Typ für Logdateien.
| |
| * <code>_tmp_t</code>: Typ für temporäre Dateien.
| |
| | |
| = Schritt 1.2: Speicherung auf dem Datenträger (Extended Attributes) =
| |
| SELinux-Sicherheitskontexte werden nicht in einer separaten Datenbank oder einem zentralen Journal gespeichert. Sie sind ein integraler Bestandteil des Dateisystems und werden zusammen mit den Dateien verschoben, wenn diese kopiert oder verschoben werden (sofern die verwendeten Werkzeuge die Beibehaltung der Attribute unterstützen).
| |
| | |
| == Begriff Extended Attributes (xattr) ==
| |
| '''Erweiterte Attribute (xattr)''' sind eine Funktion von Dateisystemen (wie Ext4, XFS, Btrfs), die es ermöglichen, einer Datei oder einem Verzeichnis zusätzliche Metadaten im Format „Schlüssel=Wert“ zuzuordnen.
| |
| | |
| Während Standardattribute (Zugriffsrechte, Eigentümer, Zeitstempel) eine feste Struktur haben, ermöglichen erweiterte Attribute die Speicherung beliebiger Daten. Genau hier speichert SELinux die Kontextzeichenfolge unter dem Schlüssel <code>security.selinux</code>.
| |
| ----
| |
| | |
| == Namensräume (Namespaces) ==
| |
| Zur Vermeidung von Konflikten und zur Gewährleistung der Sicherheit sind erweiterte Attribute in '''Namensräume''' unterteilt. Jeder Namensraum hat eigene Zugriffsregeln:
| |
| {| class="wikitable"
| |
| !'''Namensraum'''
| |
| !'''Zweck'''
| |
| !'''Zugriff'''
| |
| |-
| |
| |<code>security</code>
| |
| |Wird von Sicherheitsmodulen verwendet (SELinux, AppArmor, IMA).
| |
| |Der Zugriff ist auf den Kernel und Prozesse mit besonderen Privilegien beschränkt.
| |
| |-
| |
| |<code>system</code>
| |
| |Wird vom Kernel zur Speicherung von Systemdaten verwendet, zum Beispiel von Access Control Lists (ACL).
| |
| |In der Regel nur für den Kernel zugänglich.
| |
| |-
| |
| |<code>user</code>
| |
| |Ist für Benutzeranwendungen und Dokumente vorgesehen.
| |
| |Wird durch die standardmäßigen Zugriffsrechte (DAC) geregelt.
| |
| |-
| |
| |<code>trusted</code>
| |
| |Zur Speicherung von Daten, auf die nur Prozesse mit dem Privileg <code>CAP_SYS_ADMIN</code> zugreifen dürfen.
| |
| |Für normale Benutzer unsichtbar, selbst wenn sie Eigentümer der Datei sind.
| |
| |}
| |
| | |
| == Direkte Arbeit mit Attributen: getfattr und setfattr ==
| |
| Obwohl für die Verwaltung von SELinux häufiger spezialisierte Befehle (<code>chcon</code>, <code>semanage</code>) verwendet werden, ermöglichen Low-Level-Werkzeuge aus dem Paket <code>attr</code>, zu sehen, wie diese Daten aus Sicht des Dateisystems aussehen.
| |
| | |
| == Attribute anzeigen (getfattr) ==
| |
| Zum Lesen eines Attributs einer bestimmten Datei wird der Befehl <code>getfattr</code> verwendet. Um den SELinux-Kontext anzuzeigen, muss der vollständige Schlüsselname im Namensraum <code>security</code> angegeben werden.
| |
| <code>getfattr -n security.selinux /etc/passwd</code>
| |
| Um alle vorhandenen Attribute einer Datei anzuzeigen, wird ein Befehl der Form <code>getfattr -m . -d /etc/passwd</code> verwendet.
| |
| | |
| == Attribute setzen (setfattr) ==
| |
| Der Befehl <code>setfattr</code> ermöglicht es, den Kontextwert manuell zu ändern. Diese Aktion erfordert Superuser-Rechte und wird in der Regel nur zu Debugging-Zwecken oder für ein tieferes Systemverständnis ausgeführt.
| |
| <code>touch testfile
| |
| setfattr -n security.selinux -v "unconfined_u:object_r:user_home_t:s0" testfile</code>
| |
| <blockquote>Bei der Verwendung von <code>setfattr</code> prüft das System die Korrektheit des eingegebenen Kontexts nicht so streng, wie es die SELinux-Werkzeuge tun. Ein Fehler in der Zeichenfolge kann dazu führen, dass die Datei für Zielprozesse unzugänglich wird.</blockquote>
| |
| | |
| == Praktische Übung ==
| |
| | |
| === Modus prüfen: ===
| |
| <code>getenforce</code>
| |
| ''Wenn der Befehl'' <code>Enforcing</code> ''zurückgibt, schalten Sie ihn vorübergehend mit dem Befehl'' <code>setenforce 0</code> ''auf'' <code>Permissive</code> ''um.''
| |
| | |
| === Erzeugen einer blockierenden Situation ===
| |
| | |
| * Stellen wir uns folgende Situation vor: Sie haben eine Datei erstellt, ihr jedoch versehentlich (oder absichtlich) einen Kontext zugewiesen, der weder für einen normalen Benutzer noch für das aktuelle Verzeichnis vorgesehen ist.
| |
| | |
| <code>touch /tmp/testfile
| |
| ls -Z /tmp/testfile</code>
| |
| Ausgabe:
| |
| <code># ls -Z /tmp/testfile
| |
| unconfined_u:object_r:user_tmp_t:s0 /tmp/testfile</code>
| |
| Wie an der Konsolenausgabe zu sehen ist, hat die Datei den Typ <code>user_tmp_t</code>, der typisch für Dateien im Verzeichnis <code>/tmp</code> ist. Viele Programme haben Leserechte auf dieses Verzeichnis.
| |
| | |
| * Weisen wir der Datei nun den Typ <code>shadow_t</code> zu. Unter normalen Umständen haben nur Passwortdateien diesen Typ, und normalen Prozessen sowie Benutzern ist die Interaktion mit solchen Dateien untersagt.
| |
| | |
| <code>setfattr -n security.selinux -v "system_u:object_r:shadow_t:s0" /tmp/testfile</code>
| |
| ----Zum Setzen von Attributen kann auch das Werkzeug <code>chcon</code> verwendet werden; in diesem Fall sieht der Befehl wie folgt aus:
| |
| <code>chcon -t shadow_t /tmp/testfile</code>
| |
| Über das Werkzeug <code>chcon</code> sprechen wir etwas später noch genauer.
| |
| ----
| |
| | |
| * Prüfung, ob die Attribute korrekt gesetzt wurden:
| |
| | |
| <code># ls -Z /tmp/testfile
| |
| unconfined_u:object_r:shadow_t:s0 /tmp/testfile</code>
| |
| | |
| * Schließlich muss nun ein Verstoß provoziert werden; dazu versuchen wir, die Datei zu lesen oder zu ändern.
| |
| | |
| <code>echo "test" > /tmp/testfile</code>
| |
| | |
| * Nun betrachten wir die AVC-Ereignisse mit dem Werkzeug <code>ausearch</code>.
| |
| | |
| <code>ausearch -m AVC -ts recent</code>
| |
| ... Und wir werden nichts sehen, denn standardmäßig gelangt ein Benutzer, der sich per SSH oder über die Konsole anmeldet, in den Standardrichtlinien (Targeted Policy) in die Domäne <code>unconfined_t</code> (uneingeschränkt). Das kann mit dem Befehl <code>id -Z</code> geprüft werden.
| |
| <code># id -Z
| |
| unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023</code>
| |
| Prozessen in der Domäne <code>unconfined</code> ist praktisch alles erlaubt. SELinux sieht, dass ein „uneingeschränkter“ Prozess eine Datei liest, und selbst wenn die Datei einen ungewöhnlichen Typ hat (wie <code>shadow_t</code>), betrachtet es dies für diesen konkreten Prozess nicht als Richtlinienverstoß.
| |
| | |
| '''Um die Funktionsweise von SELinux zu prüfen, muss das Lesen der Datei mit dem Kontext eines anderen Prozesses gestartet werden, zum Beispiel''' <code>httpd_t</code>'''.'''
| |
| | |
| * Da der Typ <code>httpd_t</code> keinen Zugriff auf ausführbare Dateien des Typs <code>bin_t</code> hat (dieser Typ ist für <code>cat</code> gesetzt), erstellen wir eine Kopie von <code>cat</code> und weisen ihr den Typ <code>httpd_t</code> zu.
| |
| | |
| <code>cp /usr/bin/cat /tmp/fake_httpd
| |
| setfattr -n security.selinux -v "system_u:object_r:httpd_t:s0" /tmp/fake_httpd # oder chcon -t httpd_t /tmp/fake_httpd</code>
| |
| Prüfung:
| |
| <code>systemd-run -p SELinuxContext=system_u:system_r:httpd_t:s0 /tmp/fake_httpd /tmp/testfile</code>
| |
| | |
| * In <code>SELinuxContext</code> wird der Kontext für den Start angegeben.
| |
| ** Anschließend wird <code>cat</code> mit dem Sicherheitstyp <code>httpd_t</code> gestartet und versucht, <code>/tmp/testfile</code> zu lesen.
| |
| | |
| * Wir betrachten die AVC-Einträge:
| |
| | |
| <code>ausearch -m AVC -ts recent -c fake_httpd</code>
| |
| | |
| * Ausgabe:
| |
| | |
| <code>type=AVC msg=audit(1774103099.579:33834): avc: denied { getattr } for pid=38589 comm="fake_httpd" path="/tmp/testfile" dev="tmpfs" ino=117 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:shadow_t:s0 tclass=file permissive=1</code>
| |
| | |
| * <code>{ getattr }</code> zeigt, welche konkrete Aktion das Subjekt auszuführen versucht hat.
| |
| * <code>tcontext</code> zeigt den Kontext des Objekts, auf das ein unbefugter Zugriff versucht wurde.
| |
| * <code>scontext</code> zeigt den Kontext des Subjekts, das versucht hat, auf das Objekt mit <code>tcontext</code> zuzugreifen.
| |
| * <code>path</code> zeigt den Pfad zur Datei.
| |
| | |
| '''Wie im Log zu sehen ist, wurde der Zugriff für fake_httpd bereits beim Lesen der Dateiattribute verweigert!'''
| |
| | |
| Außerdem ist zu erkennen, dass es für SELinux keine Rolle spielt, unter welchem Benutzer der Prozess gestartet wurde, der gegen die Regeln verstoßen wollte. Auch Zugriffsrechte wie <code>chmod 777</code> beeinflussen das Ergebnis nicht.
| |
| | |
| Versuchen wir dasselbe mit dem Typ <code>user_home_t</code>. Dieser Typ wird für Dateien im Home-Verzeichnis eines Benutzers verwendet. Der Prozess <code>httpd</code> darf keine Leserechte auf Dateien im Home-Verzeichnis eines Benutzers haben. Zur Veranschaulichung geben wir der Datei zusätzlich Vollzugriff für alle.
| |
| <code>setfattr -n security.selinux -v "system_u:object_r:user_home_t:s0" /tmp/testfile
| |
| chmod 777 /tmp/testfile
| |
| systemd-run -p SELinuxContext=system_u:system_r:httpd_t:s0 /tmp/fake_httpd /tmp/testfile
| |
| ausearch -m AVC -ts recent -c fake_httpd</code>
| |
| | |
| * Und erneut erscheint im Log eine Meldung über einen Verstoß:
| |
| | |
| <code>type=AVC msg=audit(1774103685.752:33957): avc: denied { getattr } for pid=38729 comm="fake_httpd" path="/tmp/testfile" dev="tmpfs" ino=117 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:user_home_t:s0 tclass=file permissive=1</code>
| |
| Wichtig: Wenn dieselbe verbotene Aktion mehrmals hintereinander ausgeführt wird, erscheint sie nicht jedes Mal im Log, um Spam zu vermeiden. Um den SELinux-Cache zu leeren, kann ein Neustart des Betriebsmodus verwendet werden:
| |
| <code>setenforce 1 && setenforce 0</code>
| |
| | |
| = Schritt 1.3: Verhalten beim Kopieren (<code>cp</code>) und Verschieben (<code>mv</code>) =
| |
| | |
| == In diesem Abschnitt wird das Verhalten des Kontexts beim Kopieren und Verschieben von Dateien gezeigt. ==
| |
| Zunächst ist wichtig zu verstehen, dass bei der Beibehaltung des Kontexts bei der Arbeit mit Dateien — zum Beispiel beim Verschieben — ein normaler Benutzer nur den Namensraum <code>user.*</code> überträgt, während der Superuser alle Namensräume außer <code>system.*</code> kopiert.
| |
| | |
| In der Praxis bedeutet das, dass die Beibehaltung von SELinux-Labels über xattr in der Regel Root-Rechte erfordert. In dieser Lektion arbeiten wir ausschließlich als Benutzer <code>root</code>.
| |
| | |
| == 1.3.1 Kopieren einer Datei ==
| |
| | |
| * Für einen sauberen Versuch erstellen wir ein temporäres Verzeichnis, das ein Webserver-Verzeichnis simuliert, und weisen ihm den passenden Kontext zu:
| |
| | |
| <code>mkdir /tmp/web_root
| |
| chcon -t httpd_sys_content_t /tmp/web_root
| |
| ls -Zd /tmp/web_root</code>
| |
| | |
| * Nun erstellen wir zwei identische Testdateien im gewöhnlichen Verzeichnis <code>/tmp</code> (wo Dateien standardmäßig mit dem Kontext <code>user_tmp_t</code> angelegt werden):
| |
| | |
| <code>touch /tmp/file_to_copy
| |
| touch /tmp/file_to_move
| |
| ls -Z -1 /tmp/file_to_*</code>
| |
| Ausgabe:
| |
| <code># ls -Z -1 /tmp/file_to_*
| |
| unconfined_u:object_r:user_tmp_t:s0 /tmp/file_to_copy
| |
| unconfined_u:object_r:user_tmp_t:s0 /tmp/file_to_move</code>
| |
| | |
| * Wir kopieren die erste Datei in unser „Web-Verzeichnis“ und sehen uns das Ergebnis an:
| |
| | |
| <code>cp /tmp/file_to_copy /tmp/web_root/
| |
| ls -Z /tmp/web_root/file_to_copy</code>
| |
| Ausgabe:
| |
| <code># ls -Z /tmp/web_root/file_to_copy
| |
| unconfined_u:object_r:httpd_sys_content_t:s0 /tmp/web_root/file_to_copy</code>
| |
| Die Datei hat ihren Typ auf <code>httpd_sys_content_t</code> '''geändert'''.
| |
| | |
| Das Werkzeug <code>cp</code> erstellt auf dem Datenträger eine '''vollständig neue Datei''' (einen neuen inode). Nach den SELinux-Regeln '''erbt jede neue Datei standardmäßig den Kontext ihres Elternverzeichnisses'''. Das Verzeichnis <code>/tmp/web_root/</code> hat den Typ für Web-Inhalte, deshalb wurde auch die neue Datei als Web-Inhalt markiert. Der Webserver wird sie lesen können.
| |
| | |
| == 1.3.2 Verschieben einer Datei ==
| |
| | |
| * Nun verschieben wir die zweite Datei und prüfen ihren Kontext:
| |
| | |
| <code>mv /tmp/file_to_move /tmp/web_root/
| |
| ls -Z /tmp/web_root/file_to_move</code>
| |
| Ausgabe:
| |
| <code># ls -Z /tmp/web_root/file_to_move
| |
| unconfined_u:object_r:user_tmp_t:s0 /tmp/web_root/file_to_move</code>
| |
| Die Datei hat ihren alten Typ <code>user_tmp_t</code> '''beibehalten'''.
| |
| | |
| Das Werkzeug <code>mv</code> erstellt (bei einem Verschieben innerhalb desselben Dateisystems) keine neue Datei. Es ändert lediglich den Verzeichniseintrag, also die Zuordnung der Datei von einem Verzeichnis in ein anderes. Die Datei bleibt physisch dieselbe, und alle ihre erweiterten Attribute (einschließlich des SELinux-Labels) „wandern“ zusammen mit ihr. Der Webserver wird sie '''nicht lesen können''' und einen Zugriffsfehler liefern.
| |
| | |
| == 1.3.3 Steuerung dieses Verhaltens ==
| |
| | |
| === Kopieren unter Beibehaltung der Attribute ===
| |
| Für verschiedene Zwecke, zum Beispiel zum Schutz wichtiger Daten oder für Backups, kann es erforderlich sein, den Kontext beim Kopieren vollständig beizubehalten.
| |
| | |
| Dafür wird das '''Flag''' <code>--preserve=context</code> (oder der '''Archivmodus''' <code>-a</code>) verwendet.
| |
| | |
| * Wir erstellen eine Testdatei:
| |
| | |
| <code>touch /tmp/important_file
| |
| chcon -t shadow_t /tmp/important_file</code>
| |
| | |
| * Wir kopieren sie mit ausdrücklicher Anweisung, den SELinux-Kontext beizubehalten:
| |
| | |
| <code>cp --preserve=context /tmp/important_file /tmp/web_root/important_backup</code>
| |
| oder
| |
| <code>cp -a /tmp/important_file /tmp/web_root/important_backup</code>
| |
| | |
| * Prüfung:
| |
| | |
| <code>ls -Z /tmp/web_root/important_backup</code>
| |
| Damit zwingen wir <code>cp</code>, nicht nur den Dateiinhalt, sondern auch die erweiterten Sicherheitsattribute zu kopieren. Das ist bei der Erstellung von Backups von entscheidender Bedeutung.
| |
| | |
| === Verschieben mit Vererbung ===
| |
| Wir haben die Dateien einer Website nach <code>/tmp</code> heruntergeladen und wollen sie nach <code>/var/www/html</code> verschieben, damit sie sofort den korrekten Web-Kontext erhalten und die Website ohne 403-Forbidden-Fehler funktioniert.
| |
| | |
| ==== Variante 1. Flag <code>-Z</code> ====
| |
| Werkzeuge aus der <code>coreutils</code>-Familie sind in modernen Linux-Distributionen gut über SELinux informiert. Ein großes <code>-Z</code> veranlasst den Befehl <code>mv</code>, das System unmittelbar zu fragen: ''„Welcher Kontext sollte hier standardmäßig gesetzt werden?“'' und diesen dann anzuwenden.<blockquote>Die Standardkontexte für Verzeichnisse werden in einer Datenbank gespeichert und mit dem Werkzeug <code>semanage</code> verwaltet; eine ausführliche Besprechung folgt in späteren Lektionen. In diesem Beispiel verwenden wir das Verzeichnis <code>/var/www/html</code> mit dem Standardkontext <code>httpd_sys_content_t</code> anstelle von <code>/tmp/web_root</code>, weil die SELinux-Datenbank keinen Eintrag dafür hat, welcher Standardkontext für <code>/tmp/web_root</code> gesetzt werden soll.</blockquote>
| |
| | |
| * Wir bereiten die benötigte Datei vor:
| |
| | |
| <code>touch /tmp/site_index.html</code>
| |
| | |
| * Wir verschieben sie mit dem Flag <code>-Z</code>:
| |
| | |
| <code>mv -Z /tmp/site_index.html /var/www/html/</code>
| |
| | |
| * Prüfung:
| |
| | |
| <code>ls -Z /var/www/html/site_index.html</code>
| |
| Ausgabe:
| |
| <code># ls -Z /var/www/html/site_index.html
| |
| unconfined_u:object_r:httpd_sys_content_t:s0 /var/www/html/site_index.html</code>
| |
| Die Datei wurde physisch verschoben, aber ihr SELinux-Label wurde automatisch gemäß den Standardregeln des neuen Verzeichnisses neu gesetzt.
| |
| | |
| ==== Variante 2. Kontext wiederherstellen ====
| |
| Das Flag <code>-Z</code> kann man leicht einmal vergessen. Für solche Fälle gibt es die Möglichkeit, den Kontext mit dem Werkzeug <code>restorecon</code> (restore context) auf das Standardlabel zurückzusetzen.
| |
| | |
| * Wir erstellen eine weitere Datei und verschieben sie auf klassische Weise, also ohne Vererbung:
| |
| | |
| <code>touch /tmp/another_file.html
| |
| ls -Z /tmp/another_file.html
| |
| mv /tmp/another_file.html /var/www/html/</code>
| |
| | |
| * Wiederherstellung des Labels:
| |
| | |
| <code>restorecon -v /var/www/html/another_file.html</code>
| |
| Ausgabe:
| |
| <code># restorecon -v /var/www/html/another_file.html
| |
| Relabeled /var/www/html/another_file.html from unconfined_u:object_r:user_tmp_t:s0 to unconfined_u:object_r:httpd_sys_content_t:s0</code>
| |
| Das Werkzeug <code>restorecon</code> ist in Systemen mit SELinux ein nützliches Hilfsmittel zur Diagnose von Problemen nach dem Verschieben von Dateien in Systemverzeichnisse. Der Parameter <code>-v</code> wird verwendet, um Details auf der Konsole auszugeben.
| |
| | |
| === Verschieben mit <code>rsync</code> ===
| |
| Zunächst ist wichtig zu beachten, dass <code>rsync -a</code> weder ACLs noch erweiterte Attribute <code>xattr</code> einschließt.
| |
| | |
| Die Option <code>-X</code> veranlasst <code>rsync</code>, erweiterte Attribute beizubehalten.
| |
| | |
| * Zur Festigung erstellen wir ein Dateipaar:
| |
| | |
| <code>touch rsynced1 && touch rsynced2</code>
| |
| | |
| * Wir versuchen, sie auf verschiedene Arten in das Verzeichnis <code>/tmp/web_root</code> zu verschieben:
| |
| | |
| <code>rsync -a rsynced1 /tmp/web_root/
| |
| rsync -aX rsynced2 /tmp/web_root/
| |
| ls -Z -1 /tmp/web_root/rsy*</code>
| |
| Ausgabe:
| |
| <code># ls -Z -1 /tmp/web_root/rsy*
| |
| unconfined_u:object_r:httpd_sys_content_t:s0 /tmp/web_root/rsynced1
| |
| unconfined_u:object_r:user_home_t:s0 /tmp/web_root/rsynced2</code>
| |
| Daraus folgt:
| |
| | |
| * <code>rsync -a</code>: überträgt Standardattribute
| |
| * <code>rsync -A</code>: überträgt ACLs
| |
| * <code>rsync -X</code>: überträgt xattrs
| |
| | |
| In der Praxis wird für Backups am häufigsten der universelle Befehl <code>rsync -aHAX</code> verwendet, der alle Attributarten einschließt; dabei steht der Parameter <code>H</code> für Hardlinks.
| |
| | |
| Die häufigsten Probleme bei der Arbeit von <code>rsync</code> mit Attributen hängen mit einer Ausführung ohne ausreichende Privilegien zusammen. Abschließend ist wichtig zu erwähnen, dass <code>security.selinux</code> von NFS möglicherweise nicht unterstützt wird, da dort eine ältere <code>xattr</code>-Semantik verwendet wird.
| |