Analyse von Zugriffsproblemen unter Linux (4) - AppArmor
Nachdem ich mich in den vorangegangenen Artikeln dieser Serie mit den traditionellen Dateirechten, den erweiterten Dateiattributen und den POSIX Capabilities beschäftigt habe, geht es in diesem Artikel um AppArmor, ein Mandatory Access Control System. Im nächsten Artikel dieser Serie geht es um SELinux.
Wie bei allen Artikeln dieser Reihe betrachte ich auch AppArmor aus dem Blickwinkel der Fehlersuche. Für weiterführende Informationen verweise ich auf die Projekt-Homepage http://apparmor.net/
Wie jedes Sicherheitssystem, dass unerlaubte Aktivitäten verhindern soll, kann
es auch bei AppArmor vorkommen, das erlaubte Aktivitäten gestört oder
verhindert werden.
Habe ich bei einem Problem AppArmor im Verdacht, überprüfe ich als erstes, ob
es überhaupt aktiv ist.
Dazu verwende ich das Programm aa-status:
# aa-status
apparmor module is loaded.
22 profiles are loaded.
20 profiles are in enforce mode.
/sbin/dhclient
...
/usr/share/gdm/guest-session/Xsession
2 profiles are in complain mode.
/usr/sbin/libvirtd
/usr/sbin/ntpd
3 processes have profiles defined.
1 processes are in enforce mode.
/usr/sbin/cupsd (727)
2 processes are in complain mode.
/usr/sbin/libvirtd (1667)
/usr/sbin/ntpd (1436)
0 processes are unconfined but have a profile defined.
AppArmor beschränkt nur Anwendungen, für die Profile definiert sind. Falls AppArmor nicht aktiviert ist oder keine Profile geladen sind, kann ich in den meisten Fällen davon ausgehen, dass die Probleme nicht von AppArmor verursacht werden.
Nachrichten im Logfile
Wenn AppArmor aktiviert ist, schaue ich als nächstes nach Nachrichten im Systemlog. Diese finde ich unter Ubuntu zum Beispiel mit
# grep type=1400 /var/log/syslog
Ist AppArmor aktiviert, aber ich sehe keine Logmeldungen, überprüfe ich den Audit-Modus:
# cat /sys/module/apparmor/parameters/audit
normal
Der Audit-Modus kann die folgenden Werte haben:
normal
quiet_denied - verweigerte Zugriffe werden nicht protokolliert
quiet - das Modul protokolliert gar nichts
noquiet - das Modul überschreibt Profilregeln, die einzelne Nachrichten unterdrücken
all - gibt alle Prüfungen für alle Zugangsanfragen aus, auch für erlaubte Zugriffe
Um den Audit-Modus zu ändern, schreibe ich in die Datei:
# echo -n all > /sys/module/apparmor/parameters/audit
Audit-Einstellungen der Profile
AppArmor prüft nur Tasks (Prozesse), für die es ein Profil gibt. Dabei kennt es vier Modi:
Enforce mode - nur Statusereignisse (Laden von Profilen, ...) und Ereignisse, die nicht zugelassen wurden, erzeugen Audit-Nachrichten.
Complain mode - wie Enforce Mode, außer dass es den Nachrichtentyp von verboten zu erlaubt ändert, so dass AppArmor diese Anwendung nicht beschränkt. In diesem Modus protokolliert AppArmor nur unbekanntes Verhalten.
Audit mode - schreibt eine Protokollnachricht für jedes Ereignis, egal ob erlaubt oder verboten.
Kill mode - schreibt eine Protokollnachricht für jedes verbotene Ereignis und beendet die Anwendung.
Profile können Kennzeichen (Flags) enthalten, die das Audit beeinflussen.
Deny rule - jede Regel, die diesen Präfix enthält, wird ohne Protokollnachricht abgewiesen. Das setzt man ein, wenn die abgewiesenen Ereignisse bekannt sind und nicht die Systemlogs vollschreiben sollen.
Audit rule - mit diesem Präfix werden die Ereignisse dieser Regel protokolliert.
Beschränkungen eines Prozesses untersuchen
Wenn ich ein Problem mit AppArmor untersuche, schaue ich zunächst, ob der
betreffende Prozess überhaupt von AppArmor beschränkt wird.
Das kann ich entweder mit ps oder indem ich mir die entsprechenden Attribute
des Prozesses im proc Dateisystem anschaue:
# ps -Z 727
LABEL PID TTY STAT TIME COMMAND
/usr/sbin/cupsd 727 ? Ss 0:01 /usr/sbin/cupsd -F
# cat /proc/727/attr/current
/usr/sbin/cupsd (enforce)
# ps -Z 1667
LABEL PID TTY STAT TIME COMMAND
/usr/sbin/libvirtd 1667 ? Sl 0:00 /usr/sbin/libvirtd -d
# cat /proc/1667/attr/current
/usr/sbin/libvirtd (complain)
# ps -Z 1
LABEL PID TTY STAT TIME COMMAND
unconfined 1 ? Ss 0:00 /sbin/init
# cat /proc/1/attr/current
unconfined
Probleme mit AppArmor behandeln
Das beste, was ich tun kann, ist, die denied Nachrichten im Systemlog zu betrachten, deren Ursache zu verstehen und dann das Profil anzupassen.
Um ein Profil anzupassen kann ich das Program aa-logprof verwenden.
Dieses interaktive Programm durchsucht die Protokolldatei und schlägt bei
unbekannten AppArmor-Ereignissen Änderungen am jeweiligen Profil vor.
Wenn das Programm sich beendet, schreibt es die Änderungen in die Profildatei
und die geänderten Profile werden neu geladen.
Nötigenfalls werden die Profile laufender Prozesse aktualisiert.
Alternativ kann ich die Profildatei unter /etc/apparmor.d/ mit einem Editor direkt bearbeiten und mit
# apparmor_parser -r /etc/apparmor.d/$profile
neu laden.
Wichtig! Ich kann zwar einem laufenden Prozess zusätzliche Rechte gewähren. Will ich aber einer laufenden Anwendung Rechte entziehen, habe ich nur die Möglichkeit, das Profil ganz zu entfernen, es anschließend (mit weniger Rechten) wieder hinzuzufügen und dann den Prozess neu zu starten.
Profile in den Beschwerdemodus setzen
Wenn ich ein Profil gerade nicht anpassen kann, kann ich es in den Beschwerdemodus setzen. Entweder zeitweilig (bis zum Reboot):
# apparmor_parser -Cr /etc/apparmor.d/$profile
Oder permanent:
# aa-complain $profile
Dann sollte die entsprechende Anwendung sich verhalten, wie eine unbeschränkte, während AppArmor weiterhin Protokollnachrichten schreibt.
Dieser Artikel wird Teil des Buches Fehlersuche bei Linux-Servern und IP-Netzwerken, an dem ich momentan arbeite. Weitere Informationen zu diesem Buch finden sich unter http://buecher.mamawe.net/buecher/troubleshoot-linux-network/.
Posted 2013-11-06