
Ich habe SELinux unter Alma Linux 9.2 ausprobiert und gelernt. Ziel war es, eine Flask-Anwendung zu erstellen, die eine File-Inclusion-Schwachstelle aufweist, und zu zeigen, wie SELinux diese Schwachstelle verhindern kann, um bestimmte Dateien zu schützen, die für einen Angreifer nicht zugänglich sein sollten, selbst wenn die Flask-Anwendung kompromittiert ist. Um dies zu testen, habe ich eine Textdatei im Home-Verzeichnis eines Benutzers erstellt und versucht, über die Flask-Anwendung darauf zuzugreifen, woraufhin SELinux dies erzwungen hat. SELinux hat es blockiert. So weit, so gut. Dann habe ich versucht, die /etc/passwd
Datei über die Flask-Anwendung zu lesen, und sie hat es zugelassen. Ich bin mir nicht sicher, warum! Ich dachte, die Datei /etc/passwd
wäre sensibel genug, damit SELinux unbefugten Zugriff darauf blockiert. Hier ist die Ausgabe ls -Z
der beiden Dateien.
system_u:object_r:passwd_file_t:s0 /etc/passwd
unconfined_u:object_r:user_home_t:s0 /home/vagrant/test.txt
Ich bin nicht sicher, ob dieses Verhalten beabsichtigt ist.
Antwort1
Um meinen ursprünglichen Kommentar zu wiederholen:
- In der Regel
/etc/passwd
werden diese Informationen nicht als vertraulich betrachtet. Die darin enthaltenen Informationen werden beispielsweise von Anwendungen benötigt, um UID-Nummern nachzuschlagen und benutzerfreundliche Benutzernamen anzuzeigen.
Eine zweite Überlegung:
- Sofern Sie keinen benutzerdefinierten SELinux-Kontext für Ihre benutzerdefinierte Anwendung/Ihren Daemon erstellen, wird dieser nicht mit speziellen Schutzmechanismen/Einschränkungen ausgeführt. (Und effektiv verweigern nur die herkömmlichen Dateisystemberechtigungen den Zugriff.)
Sie können den aktuellen SELinux-Kontext eines laufenden Daemons mit der -Z
Option in überprüfen ps
. Was Sie sehen, hängt ein wenig davon ab, wie Sie Ihren Daemon starten, aber fürBeispiel:
ps -efZ | grep mydaemon
system_u:system_r:unconfined_service_t:s0 root 4117 1 0 16:56 ? 00:00:00 /usr/local/bin/mydaemon
zeigt unconfined_service_t
und das bedeutet: keine Einschränkungen, keine SELinux-Richtlinie.
DerRed Hat SELinux-Handbuchbietet eine kurze Einführung in die Erstellung einer solchen benutzerdefinierten SELinux-Richtlinie:
- Generieren Sie eine benutzerdefinierte Richtlinie:
sepolicy generate --init /usr/local/bin/mydaemon
- Erstellen Sie die Systemrichtlinie mit dem neuen Richtlinienmodul mithilfe des Setup-Skripts neu:
cd /home/example.user/mysepol ; ./mydaemon.sh
- Benennen Sie den entsprechenden Teil des Dateisystems mit dem Befehl restorecon neu:
restorecon -v /usr/local/bin/mydaemon /usr/lib/systemd/system
- Starten Sie den Daemon neu und prüfen Sie, ob er jetzt unter SELinux-Beschränkung läuft.
- Jetzt sollten Ihnen SELinux-Ablehnungen/Fehler angezeigt werden.