Ich erstelle ein Profil für proprietäre Software, um einen Satz von Berechtigungsanforderungen und SELinux-Richtlinien zu erstellen, die die Installation und Ausführung unter Oracle Linux (oder einem beliebigen RHEL-Derivat) ermöglichen.
Ich führe SELinux im permissiven Modus aus, habe „semodule -DB“ ausgeführt, um „dontaudit“ zu deaktivieren, und schaue mir /var/log/audit/audit.log an, um die Ergebnisse anzuzeigen.
Ich möchte jedoch auch ALLES sehen, was zulässig war (nicht nur Ablehnungen oder Auditallows), und das scheint, wie hier zu urteilen, die Mehrheit zu sein:
[root@aw-selinuxtest ~]# seinfo --stats
Statistics for policy file: /etc/selinux/targeted/policy/policy.24
Policy Version & Type: v.24 (binary, mls)
Classes: 81 Permissions: 237
Sensitivities: 1 Categories: 1024
Types: 3852 Attributes: 291
Users: 9 Roles: 12
Booleans: 228 Cond. Expr.: 268
Allow: 311381 Neverallow: 0
Auditallow: 133 Dontaudit: 0
Type_trans: 38576 Type_change: 38
Type_member: 48 Role allow: 19
Role_trans: 368 Range_trans: 5601
Constraints: 90 Validatetrans: 0
Initial SIDs: 27 Fs_use: 24
Genfscon: 84 Portcon: 471
Netifcon: 0 Nodecon: 0
Permissives: 91 Polcap: 2
Weiß jemand, wie das geht? Ich habe bisher Schwierigkeiten, eine Antwort zu finden.
Antwort1
permissiveWenn SELinux auf "Modus" eingestellt und alle AVC-Ablehnungen aufgezeichnet werden, um ein Richtlinienmodul zu entwickeln, kann dies entgegen der üblichen Vorgehensweise dazu führen, dass in eine solche Richtlinie ein falscher Berechtigungssatz aufgenommen wird.
Ein Beispiel hierfür könnte das Folgende sein: Angenommen, der normale Betrieb dieser proprietären Software erfordert eineDomänenübergang, im permissiven Modus findet der Übergang nicht statt und es sieht so aus, als ob die Quelldomäne alle Berechtigungen benötigt, die als AVC-Ablehnungen aufgezeichnet sind (Sven Vermeulens SELinux-Kochbuchenthält mehrere Hinweise auf dieses potenzielle Problem).
Ein besserer Ansatz zur Erstellung eines Richtlinienmoduls für eine proprietäre Software wäre, SELinux zunächst im Durchsetzungsmodus zu belassen, um sicherzustellen, dassgeringste Privilegienmöglich ist.
Als Nächstes müsste die Software sowohl online (gibt es eine Dokumentation?) als auch offline ( ss, strace, ipcs, …) untersucht werden, um ihren architektonischen Entwurf im Detail zu bestimmen, insbesondere (jedoch nicht beschränkt auf):
Dateien, die ebenfalls in Untergruppen unterteilt werden sollten (Konfiguration, Transaktionen, Protokolle, ...)
Prozesse, Dienste (verfügt die Software über ein systemd/upstart/init-Skript?)
Netzwerkkonnektivität (eingehender und ausgehender Datenverkehr, Ports, ...)
Benutzer, Gruppen
Wenn Sie alle diese Informationen zur Hand haben, können Sie mit der Entwicklung einer Richtlinie für diese Software beginnen.
Du wirst brauchen:
Erstellen Sie eine Filecontexts-Datei, die den Sicherheitskontext aller beteiligten Dateien definiert
Erstellen Sie eine Schnittstellendatei, die Ihre Domäne hinsichtlich aller Interaktionen zwischen Dateien, Prozessen, Ports, Benutzern, Domänenübergängen usw. definiert.
Erstellen Sie eine Typ-Enforcement-Datei, die beschreibt, welche Benutzer Zugriff auf die oben genannte Domäne haben und die tatsächlichen Regeln
Kompilieren und laden Sie es, überprüfen Sie die AVC-Ablehnungen, debuggen und verbessern Sie Ihre Richtlinie. Wiederholen Sie den Vorgang.
Aus dem oben genannten Buch noch ein letztes Zitat:
Einige Richtlinienentwickler möchten den permissiven Anwendungsmodus ausführen (entweder indem sie das gesamte System im permissiven Modus ausführen oder indem sie diese bestimmte Domäne als permissive Domäne markieren), alle durchgeführten Zugriffe registrieren (über die AVC-Ablehnungen) und die Richtlinie basierend auf diesen Informationen verbessern. Obwohl dies zu einer schneller funktionierenden Richtlinie führen kann, riskieren diese Entwickler auch, einer Richtlinie zu viele Berechtigungen hinzuzufügen, was später nur sehr schwer zu widerlegen und zu ändern ist. Stattdessen lassen wir SELinux Zugriffe verhindern und schauen uns an, wie die Anwendung reagiert. Basierend auf der Fehlerprotokollierung der Anwendung oder dem Verhalten der Anwendung und den in den Protokollen angezeigten AVC-Ablehnungen können wir uns ein gutes Bild davon machen, welche Berechtigungen wirklich erforderlich sind.