logprof

Mit diesem Befehl können Sie die AppArmor-Protokollmeldungen analysieren und entsprechende Änderungen an den Profilen vornehmen. Dieser Befehl ist besonders interessant, wenn viele Profile betroffen sind. Sie versetzen mit dem Befehl complain die entsprechenden Profile in den Lernmodus und rufen nach der Benutzung logprof auf. Die Syntax für den Aufruf ist sehr einfach. Sie können drei optionale Parameter angeben:

• -d -dir <Profilverzeichnis>. Hiermit können Sie ein alternatives Profilverzeichnis angeben. Das ist aber eigentlich nie nötig.
• -f -file <Protokolldatei>. Hiermit können Sie die Protokolldatei auswählen, in der die AppArmor-Meldungen gespeichert werden. Dies ist notwendig, wenn Logprof nicht selbst die richtige Datei findet. Das kann zum Beispiel der Fall sein, wenn Sie den Syslog-Daemon umkonfiguriert haben, so dass die Meldungen nicht in der Datei /var/log/messages landen.
• -m -logmark ``. Dieser Parameter ist der wichtigste von allen. Hiermit weisen Sie Logprof an, die Analyse der Protokolldatei an einer bestimmten Stelle zu beginnen und ältere Einträge zu ignorieren. Wenn Logprof von Genprof aufgerufen wird, wird diese Option genutzt, um den Analysestart festzulegen. Wie Sie selbst diese Protokollmarkierung erzeugen können, wird bei der Protokollanalyse beschrieben (siehe 12.1).

Logprof startet dann als interaktives Werkzeug und wird auch von Genprof und von den Yast-Assistenten genutzt. Seine Darstellung auf der Kommandozeile ist in Abbildung 10.2 zu erkennen. Logprof analysiert die Protokollmeldungen und schlägt Ihnen Modifikationen des Profils vor, welche die gemeldeten Zugriffe in Zukunft erlauben. Häufig schlägt Logprof Ihnen mehrere Möglichkeiten vor, wie Sie den Zugriff erlauben können. Sie können dann aus der Liste, durch Auswahl der vorangestellten Nummer, den besten Vorschlag auswählen. Wenn Ihnen kein Vorschlag gefällt, können Sie durch die Eingabe von N für New einen eigenen Vorschlag erstellen.

Die Analyse der Protokollmeldungen kann sowohl mit Profilen im Complain-Modus als auch im Enforce-Modus erfolgen. Der einzige Unterschied im Verhalten von Logprof ist die Auswahl der Default-Aktion bei der Auswahl der verschiedenen Möglichkeiten. War das Profil im Complain-Modus schlägt Ihnen Logprof per Default Allow vor. Ansonsten ist es ein Deny. Natürlich funktioniert Logprof besser im Complain-Modus. Im Enforce-Modus verhindert AppArmor den Zugriff auf die angeforderte Ressource. Häufig kann dann das Programm nicht weiterarbeiten. Logprof kann daher immer nur wenige Meldungen analysieren.

Eine besondere Funktion von AppArmor und Logprof ist das Globbing. AppArmor unterstützt ein Globbing der Dateinamen mit dem Wildcard &sstarf#star;. Die hierfür erforderlichen Ausdrücke können sehr leicht mit Logprof erzeugt werden. Wenn Sie einmal Glob auswählen wird der letzte Anteil des Pfades entfernt und durch einen &sstarf#star; ersetzt. Wählen Sie erneut Glob aus, so wird wieder der letzte Teil des Pfades entfernt und es werden &sstarf#star;&sstarf#star; angehängt. Während &sstarf#star; ein Wildcard für jeden beliebigen Dateinamen ist, ist &sstarf#star;&sstarf#star; ein Wildcard für den gesamten Verzeichnisbaum unterhalb des angegebenen Pfades. Die letzte Globbing-Variante wird auch automatisch vorausgewählt (siehe 10.3).

Abbildung: Um die Regeln übersichtlicher zu gestalten, erlauben AppArmor und Logprof die Verwendung von Wildcards in den Regeln.

Sollten Sie in einem früheren Dialog bereits weitere Dateien in dem Verzeichnis, z.B. /usr/share/nmap/nmap-protocols aufgenommen haben, so werden diese automatisch von Logprof entfernt, sobald eine entsprechende Globbing-Regel in das Profil aufgenommen wird.

Durch die Auswahl von Abort werden alle akzeptierten Änderungen vergessen und rückgängig gemacht. Mit Finish akzeptieren Sie die Änderungen.

Neben den einfachen Dateizugriffen analysiert Logprof auch die Ausführung neuer Prozesse, ChangeHat Ereignisse und den Zugriff auf Capabilities.

Ruft das analysierte Programm ein weiteres Programm auf, so schlägt Ihnen Logprof vier verschiedene Möglichkeiten vor:

• px. Hier muss das aufgerufene Programm über ein eigenes Profil verfügen und wird von diesem überwacht. Existiert für das Programm bei der späteren Ausführung kein Profil, wird der Aufruf verweigert!
• ix. Das aufgerufene Programm erbt das Profil des aufrufenden Programms. Es darf lediglich auf die gleichen Dateien zugreifen, auf die auch der Mutterprozess zugreifen darf. Dies ist in vielen Fällen die beste und auch eine sehr sichere Lösung. Viele Programme, wie zum Beispiel der Pager less, werden von einer Vielzahl von Softwarepaketen genutzt. Wollte man ein eigenes Profil für den Befehl less erzeugen, müsste dieses alle aufrufenden Softwarepakete berücksichtigen. Da ist es einfacher und besser das Elternprofil zu vererben (Inherit).
• ux. Diese Option ist sehr gefährlich. Das aufgerufene Programm wird von AppArmor nicht überwacht. Ein Angreifer kann versuchen über den Elternprozess gefährliche Daten an dieses nicht überwachte (unconstrained) Programm zu übergeben. Jedoch gibt es bestimmte Befehle, die in der Datei /etc/apparmor/logprof.conf definiert werden (siehe 10.4.1) bei denen nur diese Option angeboten wird.
• Deny. Selbsterklärend.

Falls Logprof ein ChangeHat Ereignis erkennt (aktuell nur für den Apache 2.0), werden Sie aufgefordert zu entscheiden, ob für diesen Zugriff der DefaultHat genutzt werden soll, Sie einen neuen Hat (Subprofil) erzeugen möchten, in dem Sie die weiteren Zugriffe dann erlauben, oder ob Sie den Zugriff verweigern möchten. Häufig ist es sinnvoll, wenn Serverbasiertes Skripting eingesetzt wird, einen eigenen Hat zu definieren. Sie können dann den Zugriff des Skriptes einschränken oder erweitern, ohne die restlichen Funktionen auf dem Webserver zu beeinflussen.

Das letzte Ereignis, welches von Logprof besonders behandelt wird, ist der Zugriff auf eine POSIX Capability (siehe 5). Hier haben Sie dann die Möglichkeit zu entscheiden, ob der Prozess diese Capability nutzen darf, oder nicht. Damit beschneiden Sie die Möglichkeiten der Prozesse, die mit Root-Privilegien gestartet wurden. Obwohl der Prozess mit Root-Privilegien gestartet wurde, darf er nur die speziell erlaubten Capabilities nutzen. So darf ein ping-Kommando zunächst ein SetUID zu Root durchführen, wie es die Linux-Dateirechte ihm erlauben und dann sowohl RAW- als auch PACKET-Sockets öffnen und benutzen. Eine Administration der Netzwerkdienste (NET_ADMIN) oder das Lesen beliebiger Dateien (DAC_OVERRIDE) werden ihm nicht erlaubt, obwohl er dies ohne AppArmor-Überwachung durchaus dürfte.

#include <tunables/global>

/bin/ping {
  #include <abstractions/base>
  #include <abstractions/consoles>
  #include <abstractions/nameservice>

  capability net_raw,
  capability setuid,

  /bin/ping ixr,

...
}