Ubuntu 26.04 / AppArmor-Profile und Verweigerungsprotokolle überprüfen

AppArmor fügt anwendungsspezifische Kontrollen über Dateien, Ausführung, Netzwerk und andere Operationen hinzu. Untersuchen Sie die gewöhnlichen Dateisystemberechtigungen zusammen mit dem aktiven Profil und den Ablehnungsprotokollen, anstatt AppArmor als erste Maßnahme global zu deaktivieren.

Unterscheiden Sie gewöhnliche Berechtigungen von Profilen

Ein Programm kann von AppArmor blockiert werden, selbst wenn Benutzer, Gruppe und Dateimodus den Zugriff erlauben. Umgekehrt bedeutet keine AppArmor-Meldung nicht, dass die Verzeichnisberechtigungen, der Mount-Zustand oder die Dienstidentität korrekt sind. Zeichnen Sie zunächst den fehlerhaften Pfad und das ausführende Konto auf.

Überprüfen Sie geladene Profile und Modi

sudo aa-status
systemctl status apparmor --no-pager

Die Modi enforce und complain unterscheiden sich: enforce setzt die Richtlinie durch, während complain die Diagnose unterstützt und den Schutz verringern kann. Der Service-Status allein beweist nicht, dass jeder Prozess eingeschränkt ist; prüfen Sie die geladenen Profile und die zugehörigen Prozesse in aa-status.

Die Sicherheitsdokumentation von Ubuntu erklärt die Durchsetzung, Modi und den Umfang der Beschränkungen von AppArmor.

Fehler mit aktuellen Protokollen abgleichen

sudo journalctl -k -b --since '10 minutes ago' --no-pager | grep 'apparmor="DENIED"'

Zeichnen Sie die Zeit einer kontrollierten Reproduktion auf und korrelieren Sie Profil, Vorgang, Name, PID, requested_mask und denied_mask. Verwenden Sie die tatsächliche Ausgabe, anstatt gefälschte Protokolle als Maschinenergebnis darzustellen. Teilen Sie nur die notwendigen Zeilen, da Pfade und Benutzerdetails sensibel sein können.

Wenn keine Ausgabe erscheint, überprüfen Sie den Boot, Zeitraum, Sammelpfad und das tatsächliche Profil. Explizite Ablehnungsregeln und andere Bedingungen können die erwartete Nachricht nicht erzeugen, daher ist das Fehlen von Protokollen kein Beweis für die Berechtigung.

Lesen Sie Ablehnungsfelder anhand eines anschaulichen Beispiels

Die untenstehende Zeile ist ein erfundenes Feldablesebeispiel, nicht ein von einer bestimmten Ubuntu-Maschine gesammeltes Protokoll. profile bezeichnet die Richtlinie, operation die versuchte Aktion und name den Zielpfad. Das r in requested_mask und denied_mask steht für angeforderte und verweigerte Leserechte.

apparmor="DENIED" operation="open" profile="/usr/sbin/example-app" name="/srv/example-data/settings.ini" requested_mask="r" denied_mask="r"

In einer echten Untersuchung sollten Zeit des Fehlers, Prozess, Identität und Pfad korreliert werden. Dies ist keine Anweisung, Zugriff auf den beispielhaften Pfad zu gewähren. Das Wiederherstellen eines unterstützten Datenorts kann die geeignete Maßnahme sein; erlauben Sie nicht jede protokollierte Anfrage.

Identifizieren Sie das Profil und dessen Besitzer

Für normale Profile identifizieren Sie den Namen und die ausführbare Datei unter /etc/apparmor.d. Für generierte Richtlinien wie Snap-Profile, überprüfen Sie Schnittstellen- und Herausgeber-Einstellungen, anstatt das generierte Ergebnis zu bearbeiten. Erfinden Sie keinen Profil-Dateinamen und kopieren Sie nicht blind die Richtlinie eines anderen Programms.

Wenn eine nicht unterstützte Datenpfadänderung das Problem verursacht hat, ziehen Sie zunächst in Betracht, einen unterstützten Speicherort wiederherzustellen. Eine Richtlinienänderung erfordert eine dokumentierte Vorgehensweise, den genauen Pfad, den Zugriffsumfang und Backups des Profils sowie der lokalen Includes. Erlauben Sie nicht, dass die gesamte Festplatte durch breite Wildcards zugänglich ist.

Überprüfen Sie ein Profil, ohne es in den Kernel zu laden

Identifizieren Sie die tatsächliche Quelldatei eines normalen Profils und geben Sie sie unten ein; schließen Sie von Snap generierte Richtlinien bei dieser Bearbeitungsübung aus. -Q überspringt das Laden des Profils in den Kernel und -K deaktiviert das Caching. Eine erfolgreiche Kompilierung stellt kein korrektes Anwendungszulassungs-/Verweigerungsverhalten sicher.

(
set -eu
read -r -p 'Actual ordinary profile path under /etc/apparmor.d/: ' profile
case "$profile" in
    /etc/apparmor.d/*) ;;
    *) printf 'Choose the verified profile source.\n' >&2; exit 1 ;;
esac
sudo test -f "$profile"
sudo apparmor_parser -Q -K "$profile"
)

Wenn tatsächlich eine gezielte Richtlinienbearbeitung erforderlich ist, sichern Sie die Quelldatei und die lokalen Includes, bestehen Sie diese Überprüfung und laden Sie dieses Profil mit sudo apparmor_parser -r ACTUAL_PROFILE_FILE neu. Im Fehlerfall stellen Sie diese Sicherungen wieder her, validieren/wenden Sie sie erneut an und überprüfen Sie aa-status und den ursprünglichen Durchsetzungszustand. Laden Sie nichts nur zu Übungszwecken neu.

Überprüfen Sie das offizielle AppArmor 5.0 Handbuch für Kompilations-, Cache- und Kernel-Ersatzverhalten.

Definieren Sie enge Änderungen, Überprüfungen und Rücksetzungen

Validieren Sie ein bearbeitetes Profil mit offiziellen Tools, laden Sie nur dieses Profil neu und testen Sie sowohl die Operation, die funktionieren sollte, als auch Operationen, die weiterhin verweigert werden sollen. Überprüfen Sie die vorgeschlagenen Regeln der Diagnosetools, anstatt jeden protokollierten Antrag zu genehmigen.

Im Fehlerfall stellen Sie nur die Richtlinienänderung wieder her und überprüfen Sie den ursprünglichen Durchsetzungszustand und das Anwendungsverhalten. Lassen Sie den Test nicht bestehen, indem Sie AppArmor oder Benutzer-Namespaceschutz global deaktivieren. Protokollieren Sie Ursache, Profil, Umfang, erlaubte und verweigerte Tests sowie die Schritte zur Rücksetzung.