Hallo, liebe Leute,
ich habe mir gerade ein Apparmor-Profil für die neuere Python-Variante von Obfsproxy erstellt, da ich eine Tor-Bridge betreibe.
Und falls das jemandem genauso geht, aber Apparmor doof und doch unverzichtbar scheint, möchte ich es hiermit teilen.
Zunächst einmal öffne die Datei /etc/apparmor.d/local/system_tor. Da ist noch nichts drin und sie existiert nur, weil das Profil unter /etc/apparmor.d/system_tor bei einem Tor-Update aktualisert werden könnte und selbstgemachte Änderungen verloren gehen würden.
In /etc/apparmor.d/local/system_tor schreibt Ihr einfach folgende Zeile:
1 | /usr/bin/obfsproxy rpx, |
Sie besagt einfach, dass Tor das Hilfsprogramm obfsproxy lesen und ausführen darf und dass für obfsproxy ein eigenes Profil vorliegt, das Ihr weiter unten findet. Die Umgebungsvariablen werden dabei weitergegeben (kleines "p"), wer testen möchte, ob es auch ohne funktioniert (noch sichererer, keine Ahnung) tauscht das kleine "p" einfach durch ein großes "P" aus. Keine geschweifte Klammer am Ende, da alles in /etc/apparmor.d/local/system_tor von /etc/apparmor.d/system_tor eingebunden wird, und zwar vor dem Profilabschluss, der in /etc/apparmor.d/system_tor ist.
Jetzt kommt das Obfsproxy-Profil (es hat 15 Zeilen, alle kopieren):
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | #include <tunables/global>
/usr/bin/obfsproxy {
#include <abstractions/base>
#include <abstractions/nameservice>
#include <abstractions/python>
/usr/bin/ r,
/usr/bin/obfsproxy r,
/usr/bin/python2.7 rix,
/usr/lib{,32,64}/python2.[4567]/**.{pyc,so} mrw,
}
|
Speichert es als /etc/apparmor.d/usr.bin.obfsproxy
Jetzt einmal
1 | sudo service apparmor reload |
eingeben. Nur "okay" ist okay, "fail" ist nur bei Welpen niedlich. Und einmal
1 | sudo aa-status |
eingeben, um zu prüfen, ob unter "XX processes are in enforce mode" sowohl system_tor (für Tor) als auch /usr/bin/obfsproxy aufgeführt sind, wenn Tor läuft und für obfsproxy konfiuguriert wurde.
Bei mir funktioniert das jedenfalls, ob das Profil okay ist, müssen bessere als ich beurteilen.