pietinger
Moderator
Joined: 17 Oct 2006
Posts: 4157
Location: Bavaria
|
 Posted: Sat Nov 28, 2020 9:59 pm Post subject: D4 AppArmor Profile selbst erstellen I. |
 |
|
(Dieser Post ist Teil einer Installation-Anleitung. Falls nicht schon geschehen lies bitte: Installation Guide for Paranoid Dummies Post Nr. 3)
D.4 AppArmor Profile selbst erstellen I.
Hier schreibe ich alles was Du für die Arbeit mit AA benötigst, selbst wenn Du niemals eigene Profile erstellen willst. Ich habe hier aber so geschrieben, wie wenn Du D.5 bereits installiert hättest und nun zusammen mit mir einiges ausprobieren willst. Quasi, zwei Durchgänge, einmal nur lesen und dann optional mit mir ausprobieren.
Wir erstellen drei Profile zu Lehrzwecken und reden dann über Variablen.
A. Das erste AP
1. Gehe in das Verzeichnis /etc/apparmor.d (als root) und editiere ...
| Code: | | /etc/apparmor.d # nano usr.bin.wget |
... mit folgendem Inhalt:
| Code: | # version 1
abi <kernel>,
profile wget /usr/bin/wget
{
include <local/ONLYNETWORK>
} |
Erläuterungen:
- Zeile 1: Dies ist nur ein Kommentar weil ein # am Anfang steht. Das ist nur für uns Menschen; AA interessiert sich überhaupt nicht dafür. Das wäre auch ein Kommentar: "# include". Wenn aber das Blank fehlen würde - also so: "#include" - wäre es kein Kommentar mehr, sondern ein echter Befehl wie in Zeile 5. Diese Schreibweise ist aber veraltet und soll nicht mehr verwendet werden (deprecated!). Wir schreiben also alle Includes so wie in Zeile 5.
- Zeile 2: Dies ist nun zwingend notwendig. Ich werde es aber erst im zweiten Teil erklären. Bis dahin nimm es einfach mal als gegeben hin.
- Zeile 3: Hier definieren wir den NAMEN unseres Profiles, gefolgt vom ausführbaren PROGRAMM. Als Name kannst Du zwar alles vergeben was Du willst, solltest aber etwas sinnvolles verwenden, da dieser Name in der "aa-status"-Abfrage erscheint.
Achtung/Fallstrick: Du musst hier den Pfad zum tatsächlichen Binary vergeben und NICHT zu einem Link davon - sonst bewirkt dieses Profil gar nichts ! Verlasse Dich nicht auf die Ausgabe von "which nano", der mir sagte "/usr/bin/nano". Tja, das ist aber nur ein Link auf "/bin/nano" ... (Rate mal wie es mir erging ...)
- Zeile 4: Damit AA weiß was alles zum profile gehört.
- Zeile 5: Wir includen das BP, wie in D.1 beschrieben.
- Zeile 6: Damit AA weiß wo unsere profile-Definitionen endet.
2. Nachdem Du diese Datei gespeichert hast, aktivieren wir das Profil mit
| Code: | | /etc/apparmor.d # apparmor_parser usr.bin.wget |
Es ist damit dem Kernel übergeben worden - genauer dem AppArmor-LSM im Kernel. Du kannst jetzt gerne mal wieder "aa-status" aufrufen. Hole Dir jetzt eine zweite Konsole und starte dort "tail -f /var/log/messages" (aka "mylogt"). Und dann noch eine dritte Konsole, wo Du nur als normaler User agierst. Gehe in Deinem Home in das Unterverzeichnis "Downloads" (erstelle es falls nicht vorhanden). Starte dort testweise:
| Code: | | ~/Downloads $ wget https://blog.fefe.de/ |
Jetzt siehst Du Fehlermeldungen in Deinem Systemlog. Diese besagen, dass Dein wget nicht in eine Datei in Deinem home-Verzeichnis schreiben durfte. Editiere nun nochmals das Profil und ergänze EINE Zeile:
| Code: | # version 1
abi <kernel>,
profile wget /usr/bin/wget
{
include <local/ONLYNETWORK>
/home/*/.wget-hsts rwk,
} |
Mit dieser Zeile erlaubst Du dem wget in Deinem Home diese Datei zu lesen und zu schreiben (und einen File-Lock darauf). Weil aber das Profil bereits "scharf" ist, musst Du die Übergabe an den Kernel mittels "apparmor_parser" jetzt mit dem Parameter "-r" aufrufen:
| Code: | | /etc/apparmor.d # apparmor_parser -r usr.bin.wget |
Starte nochmal den wget im Verzeichnis "Downloads". Es sollte jetzt funktionieren. Teste es in einem anderen Verzeichnis - z.B. in Deinem /home. Dies sollte fehlschlagen - genauso wie wir es wollen.
B. Ein zweites AP
Wir wollen nun den "nano" sichern. Dies ist ein Programm welches keine Netzwerk-Verbindung aufbauen soll/darf. Dafür darf er aber alle Dateien lesen und schreiben. Wir inkludieren deshalb das andere BP (siehe D.1) und geben ihm gleich mal sicherheitshalber Lese- und Schreibberechtigung auf alles: Das sieht dann so aus:
| Code: | /etc/apparmor.d # nano bin.nano
=>
# version 1
abi <kernel>,
profile nano /bin/nano
{
include <local/ONLYLOCAL>
/{,**} rw,
} |
Aktiviere das Profil. Versuche jetzt dieses Profil mit dem nano wieder zu öffnen ?!? Das funktioniert nicht ! Weil ... das Basis-Profil ... es verbietet ! Spätestens jetzt wirst Du Dir vermutlich D.5 ansehen ...
OK. Wir wollen weitermachen und deaktivieren dieses Profil jetzt mit
| Code: | | /etc/apparmor.d # apparmor_parser -R bin.nano |
Ich oute mich mal als Fan der Manpages und gebe Dir jetzt gleich diese:
| Code: | | # man apparmor_parser |
C. Ein letztes AP
Wir sichern jetzt den "ping". "Wassili, geben Sie mir ein Ping. Aber bitte nur eines." [aus dem Film "Jagd auf Roter Oktober"] Das Profil mit dem wir beginnen ist klar:
| Code: | # version 1
abi <kernel>,
profile ping /bin/ping
{
include <local/ONLYNETWORK>
} |
Aber wir aktivieren es jetzt mittels
| Code: | | /etc/apparmor.d # apparmor_parser -C bin.ping |
Schaue jetzt gleich mal in den "aa-status". Du siehst den Unterschied zu vorhin. Es ist nicht im "enforce mode", sondern im "complain mode". Wenn Du nun in Deiner Testkonsole einen "ping -c1 www.heise.de" absetzt, funktioniert dieser einwandfrei. Trotzdem hast Du Meldungen im Systemlog. Dies sind Meldungen nach dem Motto: "Wenn ich scharf wäre, würde ich das verbieten". Dieser Modus ist aber ideal um herauszufinden, was wir dem ping noch alles erlauben müssen. Die fehlende Zeile wäre "capability net_raw,". Und schon kommt meine nächste Manpage:
Dokumentationen
Nun wird es Zeit für einen Link zur offiziellen AA-Dokumentation auf gitlab. Zuerst die "kleine" Einführung:
https://gitlab.com/apparmor/apparmor/-/wikis/QuickProfileLanguage
Dann etwas tiefer gehend:
https://gitlab.com/apparmor/apparmor/-/wikis/AppArmor_Core_Policy_Reference
Die beiden erreichst Du vom Hauptdokument:
https://gitlab.com/apparmor/apparmor/-/wikis/Documentation
Zuletzt noch meine Lieblings-Manpage:
Was wir hier gemacht haben, findest Du auch nochmal in:
https://gitlab.com/apparmor/apparmor/-/wikis/Profiling_by_hand
Dort findest Du den Hinweis, dass Du das Ratelimit des Kernellogs auf Null setzen sollst, damit keine AA-Logausgaben vom klog verschluckt werden. Zwei Möglichkeiten dies auf Null zu setzen:
| Code: | # echo 0 > /proc/sys/kernel/printk_ratelimit
-or-
# sysctl -w kernel.printk_ratelimit=0 |
Mache dies aber nur für die laufende Sitzung und nicht dauerhaft in /etc/sysctl.conf. Das Ratelimit (5) hat sonst schon seine Berechtigung und sollte sonst nicht auf Null stehen.
Hinweis: Wenn Du ein Profil für ein bereits laufendes Programm aktivierst, gilt dies NICHT für dieses bereits laufende Programm, sonder NUR für NEU gestartete Instanzen dieses Programms. Probiere folgendes aus wenn Du den Privoxy (aus B.1) benutzt:
a) Kopiere das Profil aus D.6 und aktiviere es mit "apparmor_parser usr.sbin.privoxy"
b) Prüfe mit "aa-status"
c) Führe "/etc/init.d/privoxy restart" aus
d) Prüfe wieder mit "aa-status"
Du siehst die Unterschiede - ja.
Variablen in den Profilen
Du hast in den EP gesehen, dass dort Variablen beginnend mit @ genutzt werden. Warum haben wir das nicht ?
AA hat einen klitzekleinen Haken: Du musst Variablen VOR dem "profile" deklarieren. Also genau zwischen "abi" und "profile". Du kannst keine Variablen innderhalb des profiles deklarieren, sondern nur nutzen. Zum Beispiel:
| Code: | # version 1
abi <kernel>,
@{MYDATADIRS}=/home/*/ /mnt/ /media/
profile wget /usr/bin/wget
{
[...] |
Oder Du lagerst diese Deklaration in eine Datei aus, beispielsweise "VARIABLES". Dann musst Du diese ebenfalls VOR dem "profile" includieren:
| Code: | # version 1
abi <kernel>,
include <local/VARIABLES>
profile wget /usr/bin/wget
{
[...] |
Wenn Du nun in den Basis-Profilen Variablen benutzen willst, MUSST Du in JEDEM AP diese includen - selbst wenn Du keine einzige Variable im AP benutzt. Das ist der Grund warum in JEDEM AP aus den EP ein "include <tunables/global>" zwischen "abi" und "profile" steht. Ich will das nicht ! Wir werden das später zwar nutzen; aber vorerst kommen wir ganz gut ohne zurecht. Alle jetzigen AP brauchen keine Variablen.
Bevor ich diesen Post beende ein letzter Hinweis um Konfusion zu vermeiden:
WENN Du im Profil etwas einfach nicht erlaubst, dann wird AA jeden Verstoß protokollieren.
WENN Du im Profil etwas mit "deny" ausdrücklich verbietest, dann wird AA diesen Verstoß NICHT protokollieren, sondern "nur" unterbinden.
WENN Du im Profil etwas mit "audit deny" ausdrücklich verbietest, dann wird AA diesen Verstoß WIEDER protokollieren und natürlich auch unterbinden.
Mehr Informationen im zweiten Teil D.11. Schau Dir bis dahin aber einfach mal D.5 bis D.10 an.
. |
|
Deutsches Forum (German) 
