fossonly hat geschrieben: 06.03.2021 07:44:17
Natürlich haben Firejail und AppArmor eine große Zukunft vor sich,
Ich habe nicht gesagt, dass sie keine Zukunft vor sich hätten. Sondern ich sprach von der Integration in das Gesamtsystem.
Ebenso sind das auch keine Fremdkörper, sondern lediglich im Userspace befindliche Bestandteile für Sicherheitsmechanismen im Linux-Kernel, was eine defakto sehr tiefgreifende und transparente Integration darstellt.
Natürlich sind das in das System schlecht integrierte Fremdkörper.
Denn wenn du ein beliebiges Programm in der Konsole startest, dann wird die MAC Funktion erstmal nicht benutzt.
Um es zu benutzten musst du viel einrichten (AppArmor) oder nen Programmnamen (firejail) davor schreiben.
Vielleicht hast du auch gar nicht verstanden was ich meine, wenn ich von Integration spreche.
Der Kernel hat das Zeug, habe ich ja oben geschrieben, aber darum geht es mir hier überhaupt nicht, sondern um die Integration im Userlevelbereich.
Prinzipiell muss man keines von beidem nutzen, da praktisch jede Software die Schnittstellen diverser Sicherheitsmechanismen im Linux-Kernel direkt ansteuern kann.
Und das ist das Problem.
Es wird nicht defaultmäßig benutzt, weil es eben auf Userebene nicht integriert ist.
Wäre es integriert, dann würde ein einfaches Hello World es schon mit der striktesten Einstellung starten, ohne dass es der Nutzer durch Zutun in seinem Programmcode oder voranschreiben eines anderen Programmnamens wie firejail irgendwie aktivieren müsste.
Den zusätzlichen Code bräuchte er bei einer sauberen Integration lediglich um nach Erlaubnis für eine Auflockerung zu erfragen.
Z.B.
Programm an Kernel: "Gib mir Netzwerkzugriff auf Port X"
Dann Kernel an Datenbank: "Prozess mit SHA256 Prüfsumme n will Freigabe für Netzwerkzugriff auf Port X, ist da schon eine MAC Konfiguration hinterlegt?
Datenbank an Kernel: "Für den Prozess mit SHA256 Prüfsumme n ist noch keine Konfiguration hinterlegt."
Kernel an Konsole oder Windowmanger: "Pop mal ein Fenster auf und frage den Nutzer, ob er eine Netzwerkfreigabe auf Port X für Prozesss mit SHA256 Prüfsumme N freigeben möchte."
Konsole oder Windowmanager fragt Nutzer. Nutzer bestätigt.
Konsole oder Windowmanager an Kernel und Datenbank: "Freigabe erhalten, Datenbank richte mal ne Konfiguration für Prozess mit SHA256 Prüfsumme n ein und merk dir die die Freigabe für das Netzwerk auf Port X für diesen Prozess für später."
Kernel an Prozess: "Hier, hast du ne Freigabe."
So müsste das sein, wenn das auf Userebene ordentlich integriert wäre, aber nichts davon ist der Fall.
Und wenn man später ein Update macht, müsste der Paketmanager die Prüfsummen in der hinterlegten Konfiguration auswechseln.
Und das war eben meine Frage. Bleibt das mittelfristig so ne aufgesetzte Krückenlösung wie jetzt, wo defaultmäßig
jederProzess erst einmal alle Rechte innerhalb der Zugriffssteuerunsebene des Nutzers hat, (übrigens eine mißerable Sicherheitsstragie!) und die nur dann eingeschränkt werden, wenn er die MAC Funktion tatsächlich nutzt?
Also der Nutzer eine für diesen Prozess händisch eingerichtet hat oder mit dem Paketsystem über eine extra optionales Paket installiert ist, also das nicht einmal mit dem Paket des Programms mitinstalliert wird.
Und eine Vielzahl an FOSS macht auch reichlich Gebrauch von bspw., Seccomp und Namespaces, liefert ein gehärtetes Unit für systemd, oder bringt auch schonmal ein Profil für AppArmor mit, was seit Debian 10 ohnehin werksseitig aktiviert wird. Nutzt man in Verbindung mit Firejail zudem das Programm "firecfg", dann kann man bis dato nahezu 900 Programme auf einen Schlag, automatisch in einer pro Programm fein abgestimmten Sandbox starten lassen. Durch die Nutzung von "firecfg" wird zudem ein speziell für Firejail spezifisches AppArmor-Profil forciert, was sowohl Firejail selbst einschränkt, als auch entsprechend konfigurierte Programme die mittels Firejail gestartet werden. Man sollte Firejail und AppArmor daher nicht einzeln betrachten, sondern als symbiotische Einheit.
Man muss firecfg eben extra aufrufen, es ist nicht anders herum. Das erstmal alles restriktiv verboten ist und erst dann auf Prozessebene freigeschaltet werden muss.
Die momentane Lösung entspricht also, wenn man es mit Firewallegeln vergleicht keinem
iptables -P INPUT DROP
sondern einem
iptables -P INPUT ACCESS
Allerdings kann man derartige Sicherheitsmechanismen nicht standardmäßig für alle festlegen,
Weil es nicht auf Userebene sauber integriert ist.
Das ist das Problem.
Es müsste so ablaufen, wie ich bspw. in dem obigen Beispielablauf aufgezeigt habe.
Dann könnte man jedes Programm diese Sicherheitsmechanismus nutzen lassen und jedes Programm hätte erst einmal die allergeringsten Rechte. Also ein DROP.
und zum anderen fortschrittliche Nutzer voraussetzen die auch verstehen was hier passiert.
So etwas kann man auch abstrahieren und für den Nutzer vereinfachen.
Wenn also Programm an Kernel fragt, brauche Zugriff auf Kernschnittstelle "§)7"§/§/& und Schnittstelle "!R$")"%4 oder versucht darauf zuzugreifen, dann fragt man den Nutzer natürlich nicht, soll Programm Zugriff auf Schnittstelle "§)7"§/§/& und "!R$")"%4 erhalten, sondern man abstrahiert das und fragt ihn:
"Progamm möchte auf die 2. angeschlossene Webcam zugreifen. Erlauben? Ja/Nein"
Und wer das dann immer noch ganz fein abstimmen möchte, der kriegt unter diesem Ja/Nein noch nen Erweiterten Dialog, wenn er auf erweitert klickt. Da kann er es dann ganz genau einstellen.
Doch der naive Vergleich mit dem Designfehler namens Android, ist hier völlig fehl am Platz, zumal Android vieles ist aber kein Vorbild für ein sicheres Betriebsystem.
Android trennt die Prozesse voneinander, nutzt also grundsätzlich MAC und kann den Nutzer auch intelligent fragen ob der Prozess Zugriff auf die Webcam, das Netzwerk oder Verzeichnis XY haben soll.
Das es da natürlich schwarze Schafe gibt, also Apps, die einfach um Erlaubnis für alles fragen und ansonsten den Dienst verweigern ist kein Problem von Android, sondern vom Appschreiber der das nicht richtig gebacken bekommen hat wie man das macht oder er macht es wissentlich absichtlich so.