D1 AppArmor Einführung

[pietinger]

(Dieser Post ist Teil einer Installation-Anleitung. Falls nicht schon geschehen lies bitte: Installation Guide for Paranoid Dummies Post Nr. 3)



D.1 AppArmor Einführung

Ich habe in o.g. Post etwas gemogelt, als ich sagte, dass "OpenSMTPD" nur ein Zeile im Profil benötigt hätte. Ja, es wäre dann geschützt gewesen, hätte dafür aber gar nicht arbeiten können. Denn AppArmor arbeitet nach dem Prinzip: Es ist alles verboten was nicht ausdrücklich erlaubt ist ! (Du kennst das schon von unserer FireWall aus B.1)

Ich greife kurz vor, weil Du das für das nächste Kapitel wissen musst: Ja, es gibt diesen "deny" wirklich. Jetzt fragst Du Dich warum das denn, wenn eh alles verboten ist. Ich brauche dann ja nur etwas nicht erlauben. Das hat zwei Gründe. Einen zwingenden:

Wenn Du einem Programm Zugriff auf ALLE Files in Deinem /home geben möchtest, AUSSER dem ".ssh"-Verzeichnis, dann kannst Du nicht jede einzelne Datei (und jedes Verzeichnis) freigeben, denn der Inhalt Deines homes ist variabel. In diessem Fall MUSST Du alles freigeben und machst einen deny auf das .ssh. Die Reihenfolge spielt dabei keine Rolle - es ist egal ob Du die Freigabe vor oder nach Deinem deny machst, der deny hat höchste Priorität und wirkt immer.

Der zweite Grund: Du kannst Deine Regeln optimieren. Wenn Du 20 Files in einem Verzeichnis hast und davon 17 freigeben willst, dann kannst Du entweder 17 Regeln schreiben oder 4 Regeln (3+1).

Themawechsel.

Es gibt das Packet "apparmor-profiles". Ich habe es mir natürlich geholt, angesehen und überprüft. Du KANNST es Dir ebenso jetzt schon holen und als Vorlage nutzen. Ich werde diese Profile später "emerge-Profile" oder kurz "EP" nennen. Wir werden diese aber nicht verwenden. Verschiebe den Inhalt von /etc/apparmor.d irgendwo in Dein /home (ich werde Dich noch einmal daran erinnern). Warum ?

Meine Kritik dieser Profile

• Sie sind auf die Hauptnutzer von AA ausgerichtet: Ubuntu, Debian und SuSe.
  
• Trotzdem wird versucht jede mögliche Konstellation abzudecken. Das bläht das Regelwerk ungemein auf. Soweit, dass bereits Ubuntu warnt:
  

  Quote:

  [...] Durch diese mehrstufige Verschachtelung ist es - insbesondere bei der Verwendung mehrerer abstractions - häufig sehr schwierig, die effektiven Berechtigungen zu durchschauen, die man sich dadurch eingehandelt hat. Es besteht daher die Gefahr, dass auf diese Weise einer Anwendung mehr Rechte als nötig oder beabsichtigt erteilt werden. Das ist ein potentielles Sicherheitsrisiko. Hinzu kommt, dass es bei der Verwendung mehrerer abstractions mitunter zu konkurrierenden Berechtigungen kommen kann [...]

  (aus https://wiki.ubuntuusers.de/AppArmor/) JA, nicht nur kann, sondern so isses tatsächlich !
  
• Es fehlen wichtige Profile, dafür werden harmlose Programme gesichert (gut, wir werden für den "ping" auch ein Profil erstellen - aber nur zu Lehrzwecken).
  
• Einige Profile wurden ohne einen Test einfach zusammengebaut, frei nach dem Motto: Wenns ein Kommandozeilenprogramm ist, braucht es auch einen Include für "consoles" - obwohl das überhaupt nicht notwendig wäre (ich sehe "consoles" problematisch).
  
• Dafür legen Sie eine ungeahnte Paranoia an den Tag, wenn es darum geht lesenden Zugriff auf /etc zu erlauben. Ich habe nach über 30 einzelnen Allows aufgehört zu zählen. Bei mir wird es komplett freigegeben und dafür nur einige sicherheitskritische gesperrt. (Ja, das birgt auch die Gefahr etwas zu übersehen.)
  
• Es wird ebenso eine Sicherheit suggeriert die nicht vorhanden ist. Wenn ich nicht vorhabe den Apache2 wirklich zu sichern, dann lasse ich das Profil einfach weg und schreibe nicht soetwas in das Profil:
  

  Code:

  / rw,   /** mrwlkix,

  
  Ja Du denkst richtig, das erlaubt dem Apache2 Zugriff auf das komplette Filesystem. Gut, Sie warnen Dich im Kommentar, weil Du ja natürlich alle Profile liest:

  Quote:

  # This profile is completely permissive.

  
  
• Fast das gleiche mit dem Webbrowser, der darf auf alle meine Files in /home zugreifen ... GEHTS NOCH ?!
  
• Wenigstens war man so ehrlich und hat kein Profil für den "sshd" beigelegt. (Dazu sage ich noch was in D.6)

Ich kam deshalb zu dem Entschluss, eigene Regeln für Gentoo schreiben zu wollen. Und zwar so, dass selbst ein absoluter Neuling in AppArmor diese verstehen und beurteilen kann. Ich möchte, dass Du nicht davon abhängig bist auf solche Meldungen angewiesen zu sein:
https://www.heise.de/ratgeber/Tor-Browser-10-unter-Debian-10-4965355.html

Falls Du kein Programmierer bist und Du gerade bei "Include" gestutzt hast, lasse mich als erstes dies erläutern (als alter IT-Hase lächelst Du jetzt gerade leise in Dich hinein).

Verschachtelte Profile - der Include - die Basis Profile

Jedes Programm welches vom AA-Modul des Kernels geschützt werden soll, benötigt ein Profil - hinterlegt in einer Text-Datei, welches dann dem Kernel übergeben wird. Ich werde dieses in der ganzen D-Reihe als Applikations-Profil - kurz AP - bezeichnen. In diesem musst Du dem Programm alles erlauben, was ihm erlaubt werden muss, damit es ORDNUNGSGEMÄSS funktioniert. Das kann ziemlich viel sein.

a) Wenn Du für z.B. 20 Programme 20 APs erstellst, wirst Du feststellen, dass viele Freigaben von allen Programmen benötigt werden. Statt diese in jedem der 20 APs immer und immer wieder reinzuschreiben, kannst Du eine zusätzliche Datei anlegen und nur EINMAL diese Freigaben definieren. Diese Datei nenne ich nun Basis-Profil - kurz BP.

In Deinen 20 APs schreibst Du jetzt nur eine einzige Zeile, die dafür sorgt, dass der Inhalt aus dem BP in das eigentliche AP übernommen wird. Diese Zeile beginnt mit dem Statement "Include" und danach kommt nur noch der Dateiname des Basis-Profils.

b) Wenn Du weiterhin Deine 20 APs analysierst, wirst Du feststellen, dass es einige Freigaben gibt, die zwar nicht von allen, aber von einigen Programmen benötigt werden. Beispielsweise brauchen alle Programme die Musik ausgeben sollen, Zugriff auf die gleichen Files in /dev. Auch diese Freigaben kannst Du auslagern in ein BP und in den jeweiligen APs nur den benötigten Include reinsetzen.

Meine Umsetzung zu:

a) Es gibt nur zwei Basis-Profile die sich jedoch gegenseitig ausschließen: "ONLYLOCAL" und "ONLYNETWORK". Ich habe den Präfix ONLY gewählt um diese Exklusivität kenntlich zu machen.

b) Alle anderen BPs die Du je nach Bedarf "zubuchen" kannst beginnen mit "USE....", wie z.B. "USESOUND". Hier kannst Du soviele einbinden, wie Dein Programm benötigt. Es gibt noch ein letztes BP mit dem Namen "ISAKDE", auf deutsch "ist ein KDE-Programm" ...

Namenskonventionen

Ich habe die BPs absichtlich immer groß geschrieben, damit ich eventuell vorhandenen Dateien aus den EPs (siehe oben) nicht in die Quere komme. Für die von mir verwendeten APs habe ich aber mit voller Absicht die Namenskonvention von den Erfindern von AA übernommen. Zum einen, weil ich diese gut und logisch finde; viel wichtiger aber noch, weil sie sich dann gegenseitig mit den EPs ausschließen. Falls Du also ein Profil von hier mit dem Namen "usr.bin.wget" im Einsatz hast und Du doch die EPs installieren und aktivieren willst, wird dieses Profil dann überschrieben und Du nutzt automatisch das Profil aus den EPs.


Ich habe wieder absichtlich nicht zum Gentoo Wiki verlinkt, weil es leider veraltet ist. Selbst bei der "Konkurrenz" sieht es sehr düster aus und ich empfehle diesen Link nur um mal kurz querzulesen:
https://wiki.archlinux.org/index.php/AppArmor
Es hat sich vor kurzem einiges geändert und das habe ich in dieser D-Reihe eingearbeitet. Deshalb empfehle ich in jedem Fall D.4 zu lesen, selbst wenn Du Dir denkst, dass Du niemals eigene Profile erstellen willst. Ich gebe Dir dort auch alle Links die Du benötigst.

Ein letzter Hinweis: Ich habe alles mit den unstable Kernels der 5.9.x-Reihe getestet - mein restliches Gentoo ist stable -, sowie mit allen vorherigen Installationen (B.1, B.2, B.3 und auch C. IMA). Jedoch kann ich natürlich nicht für alle möglichen Programme ein Profil erstellen und testen, deshalb soll diese D-Reihe ein MITMACH-Projekt sein.

Du bist herzlich eingeladen alle Threads ab D.6 mit Deinen Profilen zu erweitern.


Weiter gehts mit D.2