Wir haben einen Server mit dem Betriebssystem Alma Linux 9.3. Standardmäßig ist es (wie auch alle aktuellen RHEL-ähnlichen Betriebssysteme) fapolicydaktiviert. Auf diesem Server läuft auch ein Anwendungsserver (WildFly/JBoss/Java). Die bereitgestellte Anwendung verarbeitet einige Datendateien (die von Benutzern übermittelt wurden) und funktioniert in der Standardsituation einwandfrei.
Derzeit gibt es jedoch einen Zeitraum, in dem die Anwendung etwa 1000 Dateien pro Minute verarbeiten muss. In einer solchen Situation fapolicydbeansprucht der Overhead etwa 15 % der CPU, was wir als zu viel erachten.
Ich konnte im Internet niemanden mit einem ähnlichen Problem finden.
Ich bin auch überrascht, dass es fapolicydhier auf ServerFault kein Tag gibt.
Fragen:
- Gibt es eine Möglichkeit,
fapolicyddie Konfiguration zu optimieren, sodass schneller entschieden werden kann, ob ein Dateizugriff erlaubt oder verweigert wird?- Eine Sache, die mir in den Sinn kommt, ist die Reihenfolge der benutzerdefinierten Regeln.
- Vielleicht die Verwendung von Platzhaltern statt der Verwendung wörtlicher Regeln.
- Irgendwelche Hinweise, wie wir einschätzen können, wie wichtig es
fapolicydfür uns ist?- Ob wir es einfach abschalten können oder ob es trotz des enormen Mehraufwands wirklich eine gute Idee ist, es laufen zu lassen.
- Ob andere Distributionen so etwas auch verwenden
fapolicydoder ob es "nur zusätzliche Sicherheit" ist undSELinuxausreicht. (Ich weiß, dass das nicht dasselbe ist.)
Quellen:
Antwort1
Die Zulassungsliste ausgeführter Programme gehört zu den wirksamsten Sicherheitsfunktionen. Ohne sie könnte ein kompromittiertes Benutzerkonto beliebige Nutzdaten ausführen. Oder Benutzer installieren Programme in ihrem Home-Verzeichnis, die sie nicht sollten. Allerdings handelt es sich dabei um eine optionale Funktion, die Sie aktivieren können oder nicht.
Die Überprüfung aller dieser Dateisystemaufrufe geht zu Lasten der Leistung. Der Mehraufwand kann jedoch durch die Optimierung der Regeln und der Datenbank minimiert werden.
Messen Sie, ob die Leistung aus Sicht des Benutzers akzeptabel ist. Ein auf die Reaktionszeit fokussiertes Ziel, etwa „99,9 % der API-Aufrufe der Anwendung werden in weniger als einer Sekunde abgeschlossen“, erkennt echte Probleme, nicht nur Trends bei der Ressourcennutzung.
Zunächst einige Hintergrundinformationen zu fapolicyd. Beachten Sie die Leistungseinführung vondie README:
LEISTUNG
Wenn ein Programm eine Datei öffnet oder execve aufruft, muss dieser Thread warten, bis fapolicyd eine Entscheidung trifft. Um eine Entscheidung treffen zu können, muss fapolicyd Informationen über den Prozess und die aufgerufene Datei nachschlagen. Jeder Systemaufruf, den fapolicyd durchführen muss, verlangsamt das System.
Um die Arbeit zu beschleunigen, speichert fapolicyd alles, was es sucht, im Cache, sodass nachfolgende Zugriffe den Cache verwenden, anstatt Dinge von Grund auf neu nachzuschlagen. Aber der Cache ist nur begrenzt groß. Sie haben jedoch die Kontrolle darüber. Sie können sowohl den Subjekt- als auch den Objekt-Cache vergrößern. Wenn das Programm endet, gibt es eine Leistungsstatistik wie diese in /var/log/fapolicyd-access.log oder auf dem Bildschirm aus:
Permissive: false q_size: 640 Inter-thread max queue depth 7 Allowed accesses: 70397 Denied accesses: 4 Trust database max pages: 14848 Trust database pages in use: 10792 (72%) Subject cache size: 1549 Subject slots in use: 369 (23%) Subject hits: 70032 Subject misses: 455 Subject evictions: 86 (0%) Object cache size: 8191 Object slots in use: 6936 (84%) Object hits: 63465 Object misses: 17964 Object evictions: 11028 (17%)In diesem Bericht können Sie sehen, dass die interne Anforderungswarteschlange bei 7 voll war. Das bedeutet, dass der Daemon höchstens 7 Threads/Prozesse warten ließ. Das zeigt, dass er etwas überlastet war, aber die Anforderungen ziemlich schnell verarbeitete. Wenn diese Zahl groß wäre, z. B. mehr als 200, könnte eine Erhöhung der q_size erforderlich sein. Beachten Sie, dass systemd möglicherweise angewiesen werden muss, mehr als 1024 Deskriptoren zuzulassen, wenn Sie über 1015 gehen. In der Datei fapolicyd.service müssen Sie LimitNOFILE=16384 oder eine Zahl hinzufügen, die größer als Ihre Warteschlange ist.
Eine weitere Statistik, die einen Blick wert ist, ist das Verhältnis von Treffern zu Auslagerungen. Wenn eine Anfrage keinen Platz für Informationen hat, muss sie etwas auslagern, um Platz zu schaffen. Dies wird von einem LRU-Cache erledigt, der natürlich feststellt, was nicht verwendet wird, und seinen Speicher für die Wiederverwendung verfügbar macht.
In der obigen Statistik betrug die Trefferquote für das Subjekt 95 %. Der Objekt-Cache hatte nicht ganz so viel Glück. Hierfür erhalten wir eine Trefferquote von 79 %. Das ist immer noch gut, könnte aber besser sein. Dies würde darauf hindeuten, dass der Cache für die Arbeitslast auf diesem System etwas größer sein könnte. Wenn die für die Cache-Größe verwendete Zahl eine Primzahl ist, erhalten Sie weniger Cache-Fluktuation aufgrund von Kollisionen, als wenn sie einen gemeinsamen Nenner hätte. Einige Primzahlen, die Sie für die Cache-Größe in Betracht ziehen könnten, sind: 1021, 1549, 2039, 4099, 6143, 8191, 10243, 12281, 16381, 20483, 24571, 28669, 32687, 40961, 49157, 57347, 65353 usw.
Außerdem sollte erwähnt werden, dass je mehr Regeln in der Richtlinie enthalten sind, desto mehr Regeln durchlaufen werden müssen, um eine Entscheidung zu treffen. Was die Auswirkungen auf die Systemleistung betrifft, so hängt dies stark von der Arbeitslast ab. In einem typischen Desktop-Szenario werden Sie nicht bemerken, dass es ausgeführt wird. Ein System, das für kurze Zeit viele zufällige Dateien öffnet, hat größere Auswirkungen.
Eine weitere Konfigurationsoption, die die Leistung beeinträchtigen kann, ist die Integritätseinstellung. Wenn diese auf sha256 eingestellt ist, führt jeder Fehler im Objektcache dazu, dass ein Hash für die aufgerufene Datei berechnet wird. Ein Kompromiss wäre, die Größenüberprüfung anstelle von sha256 zu verwenden. Dies ist nicht so sicher, aber eine Option, wenn die Leistung problematisch ist.
do_stat_report = 1in der Konfiguration, um den Statistikbericht zu aktivieren, und starten Sie dann fapolicyd neu, falls dies nicht kürzlich geschehen ist. Analysieren /var/log/fapolicyd-access.log und notieren Sie die Muster, welche PIDs welche Dateien öffnen.
Beachten Sie das Verhältnis von „Treffern“ zu „Fehlschlägen“. Eine höhere Trefferquote ist besser, der Zugriff auf die Datenbank im Arbeitsspeicher ist viel schneller als der Zugriff und die Verarbeitung auf das Dateisystem. Erhöhen Sie obj_cache_sizein der Konfiguration die Anzahl der Dateien, die Ihr System gleichzeitig hat. Eine mögliche Obergrenze ist die Anzahl der verwendeten Inodes im Datendateisystem, wie aus df -ider Ausgabe hervorgeht. Das könnte übertrieben sein, aber wenn Sie den Speicher haben, warum nicht ein paar hunderttausend Einträge zwischenspeichern.
Überprüfen Sie die Konfiguration in fapolicyd.conf. integrityAndere Werte als noneoder sizeberechnen die Prüfsumme und verursachen Mehraufwand. Insbesondere wenn bei der Verarbeitung neuer Dateien viele Fehler auftreten, kann dies eine erhebliche CPU-Belastung bedeuten. q_sizesollte größer sein als die „maximale Warteschlangentiefe“ im Zugriffsbericht, ich bezweifle jedoch, dass die Warteschlangengröße erhöht werden muss.
Überprüfen Sie die Regeln in compiled.rules von rules.d. RHEL und Fedora füllen vertrauenswürdige Dateien aus rpm, erlauben keine Ausführung unbekannter Dateien, erlauben nicht den ld.so-Trick und lassen die meisten Öffnungen zu. Wenn Sie Regeln ändern, denken Sie an die Auswirkungen auf die Leistung, wenn Sie mehr Dinge tun, während dieser offene Systemaufruf wartet.
Und wie immer können Sie bei der Fehlerbehebung ein Profil dessen erstellen, was genau vor sich geht. perf topEs wird gedruckt, welche Funktionen auf der CPU ausgeführt werden, und es ist sogar noch besser, wenn Debuginfo installiert ist. Das Paket bcc-tools verfügt über einige nette Skripte: opensnoop und execsnoop zum Auflisten offener und exeve-Aufrufe in Echtzeit.
Letztendlich liegt es an Ihnen, welche Kontrollen Sie einrichten, um nur die Ausführung nicht autorisierter Programme zuzulassen. Eine Allow-Liste direkt im Exec-Aufruf, wie fapolicyd, ist natürlich sehr leistungsfähig. Eine weniger umfassende Alternative könnte darin bestehen, den Shell-Zugriff einzuschränken: Benutzern keine interaktiven Shells zu erlauben und die Berechtigungen für Home-Verzeichnisse zu sperren. Oder, wenn ein Datendateisystem überhaupt keine Programme enthalten soll, sollten Sie es mit noexec mounten. Ein gutes Sicherheitsaudit würde die Checkliste nicht als unveränderlich behandeln, sondern alternative vorhandene Kontrollen und deren Gründe auflisten.