AppArmor blockiert einen Anwendungsvorgang · Linux Fix Lab

Symptome und Geltungsbereich

Eine Anwendung kann einen für das Konto erreichbaren Pfad nicht nutzen.
Kernel-Audit-Einträge enthalten apparmor="DENIED".

Betroffene Umgebung

Linux mit AppArmor; vollständiger Profilstatus und Kernel-Audit-Protokolle können administrative Leserechte erfordern.

Erkennbare Meldungen (synthetische Beispiele)

audit: type=1400 apparmor="DENIED" operation="open" profile="/usr/bin/example" name="/srv/example/data" denied_mask="r"

Profil und Pfad grenzen die Untersuchung ein; Unix-Rechte können zusätzlich begrenzen.

audit: type=1400 apparmor="DENIED" operation="sendmsg" profile="/usr/bin/example" family="inet" sock_type="stream" denied_mask="send"

Netzwerkregeln und vorgesehenes Ziel prüfen, bevor dies als Verbindungsstörung eingeordnet wird.

Mögliche Ursachen

Das sind mögliche Erklärungen, keine bestätigte Diagnose. Mehrere unabhängige Fehler können gleichzeitig vorliegen.

Die Anwendung kann einen Pfad außerhalb der erlaubten Profilorte verwenden.
Ein aktualisiertes Programm kann einen im installierten Profil fehlenden Vorgang benötigen.

Sicher prüfen

Führe jeweils einen Befehl in der passenden Sitzung aus. Lies zuerst die Erklärung. Großgeschriebene Platzhalter brauchen deine Werte; Werkzeuge und Rechte unterscheiden sich je nach Distribution. Die Website zeigt Befehle an und führt sie niemals aus.

Prüfschritt 1

Liest Kernel-Ablehnungen des aktuellen Starts; ein Konto mit Leserecht für das Kerneljournal verwenden.

journalctl -k -b --no-pager --grep='apparmor="DENIED"'

Ergebnis einordnen: profile, operation, name und denied_mask mit dem fehlerhaften Vorgang vergleichen. Kein sichtbarer Eintrag schließt explizite deny-Regeln oder unvollständige Protokolle nicht aus.

Prüfschritt 2

Listet geladene Profile und ihre Modi; administrative Leserechte können nötig sein.

aa-status

Ergebnis einordnen: Ein erzwingendes Profil kann Zugriff sperren. Complain protokolliert normalerweise erlaubte Verstöße; das konkrete Profil prüfen, statt alle Profile gleich zu behandeln.

Nächste Schritte nach Befund

Einen bereits im Profil erlaubten Pfad verwenden

Wenn die Anwendung auf einen ungewollten Sonderpfad zeigt, ihren dokumentierten Daten- oder Konfigurationsort wieder nutzen. Daten nur über eine unterstützte Migration mit Sicherung verschieben und den Vorgang gegen das genannte Profil erneut prüfen.

Vorsicht: Anwendungsbesitzer und normale Dateirechte erhalten; AppArmor ersetzt diese Prüfungen nicht.

Wiederherstellung / Rücknahme: Die gesicherte Pfadeinstellung und Datensicherung der Anwendung wiederherstellen, wenn die Migration zurückgenommen werden muss.

Hat dir dieser Hinweis geholfen?

Hinweis teilen #

Eine geprüfte minimale lokale Profilregel ergänzen

Wenn der blockierte Vorgang berechtigt ist, den konkreten Eintrag mit aa-logprof prüfen und nur den benötigten Pfad und Zugriff in einer unterstützten lokalen Ergänzung freigeben. Diese vorher sichern, das einzelne Profil neu laden und seinen erzwingenden Modus prüfen.

Vorsicht: Nicht jede vorgeschlagene Regel annehmen oder AppArmor global abschalten. Netzwerkablehnungen benötigen Netzwerkregeln statt weiter Datei-Platzhalter.

Wiederherstellung / Rücknahme: Die gesicherte lokale Ergänzung wiederherstellen und dasselbe Profil neu laden; nur die für diese Untersuchung ergänzte Regel entfernen.