D.11 AppArmor Profile selbst erstellen II
Nachdem Du Dir nun meine Profile angesehen hast - und vielleicht auch mit den EP verglichen hast - stehst Du vielleicht vor neuen Fragen.
Was bedeutet "abi <kernel>,"
... und warum haben wir keine Definitionsdatei wie in den EP (dort ist => abi <abi/3.0>,) ?
Kurz gesagt, "abi" soll eine Übereinstimmung zwischen dem was das Profil an Regeln vorgibt, mit dem was der Kernel = das AA-LSModul im Kernel - dann letztendlich tatsächlich überprüft, erreichen. Du kannst Dir die aktuellen Feautures Deines AA-LSM anzeigen lassen mit:
Code: Select all
# ls -R /sys/kernel/security/apparmor/features/*) Edit 2023-03-05: Nur zur Info: Inzwischen ist es schon wieder nicht mehr nötig CHECKPOINT_RESTORE für "mesa" zu enabeln, da der Systemaufruf SYS_kcmp herausgelöst wurde und nun automatisch enabelt wird, soabld Du DRM im Kernel aktiviert hast (was ebenfalls automatisch gesschieht, wenn Du die Graphik-Module enablest; KCMP siehst Du auch nur dann, wenn der "expert user" enabled ist). Details findest Du hier:
https://git.kernel.org/pub/scm/linux/ke ... aee6a248c7
Angenommen wir hätten ein Profil für "mesa" für einen älteren Kernel erstellt, dann hätten wir ganz sicher nicht im Profil diese Capability erlaubt (weil ja (noch) gar nicht existent). Wenn wir nun unter dem aktuellen Kernel "mesa" neu compilieren, wird "mesa" das natürlich nutzen (vorausgesetzt Du hast das auch in der Kernel-Config erlaubt) ... und benötigt dann auch die Erlaubnis vom AA-LSM dazu. Wir müssen also das Profil aktualisieren und diese Capability erlauben.
Dies ist für viele Binär-Distributionen unpraktikabel und deshalb nutzen sie eine Definitionsdatei, die angibt welche Fähigkeiten des AA-LSM überhaupt benutzt werden soll. Die tatsächlichen Fähigkeiten werden also mit den maximalen Fähigkeiten der Profile abgeglichen. Wenn im "abi-File" eine Fähigkeit nicht definiert ist, wird sie dann auch vom AA-LSM nicht geprüft. Damit wird trotz fehlender Berechtigung im "mesa"-Profil für diese Capability kein Deny erzeugt, weil das AA-LSM es nun auch nicht überprüft.
Dies ist jedoch für mich unerwünscht. Ich möchte neue Fähigkeiten von AA mitbekommen - auch um den Preis, dass dann einige Profile erweitert werden müssen. Dies erreiche ich durch abi <kernel>. Mit diesem Schlüsselwort weiß der Parser (apparmor_parser) (der ja unsere Profil-Dateien in Binär umwandelt und dem AA-LSM übergibt), dass er sich "nur" an den aktuellen tatsächlichen Fähigkeiten unseres AA-LSM orientieren muss. Das ganze ist ein bischen weird dokumentiert in:
https://gitlab.com/apparmor/apparmor/-/ ... FeatureABI
https://gitlab.com/apparmor/apparmor/-/ ... eaturesabi
https://gitlab.com/apparmor/apparmor/-/ ... eaturesDev
(Gleiches gilt auch für den umgekehrten Fall: Wenn der Kernel weniger kann als das Profil. Dadurch dass der Parser beide Fähigkeiten prüft, gibt er dem Kernel dann auch nicht zuviel mit.)
Was wäre wenn im Profil gar kein "abi" definiert wäre ?
Das habe ich mangels Dokumentation einfach mal getestet. Anscheinend fällt der Parser dann in eine Art "Minimal-Definition" zurück, dessen Umfang mir aber nicht bekannt ist. Ich kann nur sagen, dass ich dann Netzwerk-Zugriff hatte, obwohl ich im Profil keinen erlaubt habe ... Also, ohne abi sollte man wirklich kein Profil mehr erstellen !
Die Variable @{profile_name}
Vielleicht ist Dir aufgefallen, dass ich in ISAX11 diese Variable verwendet habe, ohne dass diese irgendwo deklariert wurde. Trotzdem funktioniert dieses Profil. Diese Variable ist eine - momentan die einzige - im "apparmor_parser" eingebaute Variable, die der Parser selbständig substituieren kann. Erinnerst Du Dich als ich im ersten Teil sagte, dass Du als Profil-Namen vergeben kannst, was Du willst ? Nun, das stimmt nicht mehr, WENN Du diese Variable verwenden willst. Denn dann ist der Name schon ausschlaggebend um die nötigen Freigaben zu bekommen. Du darfst daher meine Profile nicht umbenennen (das darfst Du bei den EP auch nicht, da diese ebenfalls diese Variable benutzen) !
Optimierung von AP
Vielleicht ist Dir auch aufgefallen, dass die Profile "konqueror" und "falkon" einige identische Freigaben im Profil haben. Könnte man diese nicht auslagern ? Ja, natürlich - ist bei mir ja auch bereits so. Habe ich aber erstmal nicht gemacht, damit wir dies nun gemeinsam tun können (und wir nicht zuviele USE-Profile für den Anfang bekommen). Keine Sorge - diese Profile sind jetzt schon voll funktionsfähig. Was wir machen ist eher für zukünftige Profile, die auch die QTWebEngine nutzen, interessant. Drei Zeilen können wir schon mal problemlos in eines neues BP verschieben. Die vierte Zeile (ptrace (read, readby) ...) ist beinahe identisch, bis auf den Namen ... genau da brauchen wir - wieder - obige Variable. Dann können wir ein neues USEQTWEBENGINE-Profile erstellen ...
Code: Select all
# version 2
/usr/lib64/libexec/kf5/kio_http_cache_cleaner rix,
/usr/lib64/qt5/libexec/QtWebEngineProcess rix,
/dev/shm/.org.chromium.* rwk,
/proc/*/oom_score_adj rw,
ptrace (read, readby) peer=@{profile_name},Code: Select all
# version 2
abi <kernel>,
profile falkon /usr/bin/falkon
{
include <local/ONLYNETWORK>
include <local/ISAKDE>
include <local/USESOUND>
include <local/USEQTWEBENGINE>
# include <local/USECUPS>
# include <local/USEWEBCAM>
# needed for private mode
/usr/bin/falkon ix,
/dev/ r,
owner /home/*/.config/falkon/profiles/*/* l -> /home/*/.config/falkon/profiles/*/#[0-9]*,
owner /home/*/.pki/** wrk,
}File Globbing
Weil das immer wieder für Verwirrung sorgt, möchte ich einiges noch mal ganz explizit aufführen. Ich sagte ja schon, dass einige Verzeichnisse, wie z.B. /dev niemals komplett freigegeben werden sollten. Und trotzdem siehst Du in obigen Profil ein "/dev r," ... ? Erlaube ich dann nicht den Zugriff auf alles in /dev ? Nein, Du erlaubst nur das Auslesen des Verzeichnis-Inhalts, aber NICHT das Lesen einzelner Dateien. Ich gebe Dir mal eine Übersicht am Beispiel /dev:
Code: Select all
/dev/ Nur Verzeichnis-Inhalt - keine Dateien
/dev/* ALLE Dateien in dev direkt - NICHT in Unterverzeichnisse - NICHT der Verzeichnis-Inhalt
/dev/** ALLE Dateien in dev und allen Unterverzeichnisse (in beliebiger Hierarchie-Tiefe)
/dev/{,*} Der Verzeichnis-Inhalt von /dev UND ALLE Dateien in dev direkt - NICHT in Unterverzeichnisse - Könnte auch mit zwei Zeilen so geschrieben werden:
/dev/
/dev/*
/dev/{,**} Der Verzeichnis-Inhalt von /dev UND ALLE Dateien in dev und allen Unterverzeichnissen (in bel. Tiefe) -""-
/dev/
/dev/**
/dev/[^.]* Alle Dateien in dev direkt AUSSER Dot-Files - Keine Unterverzeichnisse - NICHT der Verzeichnis-Inhalt
/dev/[^.]** Alle Dateien in dev und allen Unterverzeichnissen AUSSER Dot-Files - NICHT der Verzeichnis-InhaltAutomatische Profil-Erstellung
Vielleicht hast Du https://gitlab.com/apparmor/apparmor/-/ ... with_tools gelesen ...
... tue es nicht ... das ganze ist auf die EP zugeschnitten und Du hast mehr Ärger als Nutzen - aber es ist natürlich Deine Entscheidung.
Ist B.5 nun obsolet ?
Jein.
Ja, der User "No" wird nicht mehr gebraucht (funktioniert auch gar nicht mehr) und AppArmor ist natürlich um Welten sicherer !
Nein, ich nutze natürlich noch das "Lösch-Skript" um meine Privacy zu schützen ...
Was mache ich, wenn einige Anwendungen plötzlich auf DBUS zugreifen wollen ?
Stand heute überprüft das AA-LSM noch keine DBUS-Kommunikation. Etwaige Regeln zu DBUS werden also nicht an den Kernel übergeben. Falls dies zukünftig notwendig sein sollte, kannst Du entweder die nötigen Freigaben anhand des Systemlog herausfinden und einzeln alles freigeben, oder Du machst es so wie in den EP (abstractions/ubuntu-helpers):
Code: Select all
# Allow all DBus communications
dbus,Code: Select all
# Full access
/ r,
/** rwkl,
/{,usr/,usr/local/}lib{,32,64}/{,**/}*.so{,.*} m,Brauche ich überhaupt noch IMA ?
Nun ... im Mittelalter hatten sie auch zwei Burgmauern ... Ich habe beides im Einsatz und fühle mich sehr sicher !
Falls Du noch weitere Fragen hast, scheue Dich nicht, diese einfach im passenden Thread zu stellen (vielleicht haben andere die gleiche Frage und freuen sich auf eine Antwort dort).
Have Fun !