Zukunft von AppArmor, firejail usw.? Prozesstrennung weiterhin explizit oder irgendwann implizit?
Verfasst: 05.03.2021 23:42:41
Ein modernes Betriebssystem trennt nicht nur die Benutzer voneinander und ist in der Lage ihnen einzelne Zugriffsrechte zuzuweisen, sondern ein modernes Betriebssystem ist auch in der Lage die Prozesse voneinander abzuschotten.
Diese Fähigkeiten wurden in den Linux Kernel generisch implementiert und nutzen kann man sie mit Zusätzen wie firejail und AppArmor.
Aber der große Nachteil ist, dass das alles aufgesetzt wirkt und es ist nicht fest ins System integriert ist.
Wer bspw. firejail nutzen möchte und dabei vergisst seinen Prozess mit einem firejail Befehl vor dem Aufruf des zu startenden Prozesses zu starten, der nutzt diese Prozesstrennung und Sandbox Funktion schlichtweg nicht.
Man muss also immer darauf achten, das man beim Starten:
eingibt.
Vergisst man das und gibt nur
in der Konsole ein, dann wird es ohne diese Prozesstrennung gestartet.
Nicht viel anders ist es mit den Konfigurationsdateien, die müssen vorher angelegt worden sein, damit das zu startende Programm mit firejail benutzt werden kann.
Bei AppArmor verhält es sich ähnlich, nur mit dem Unterschied, dass es da noch komplizierter zu konfigurieren ist.
In Debian kommen diese Konfigurationsdateien als extra Paket daher. Sie sind kein fester Bestandteil des Programmpakets.
Wer also nicht explizit firejail installiert und dafür sorgt, das sein Paket mit einer Sammlung an Konfigurationsdateien für firejail mitinstalliert wird, der muss ohne diese Funktion auskommen.
Alles wirkt also aufgesetzt und nicht integriert. Startet man ein neues Programm für das es keine Konfiguration gibt, wird man auch nicht danach gefragt eine einzurichten. Das Programm wird dann einfach ohne Sanboxfunktion mit vollen Rechten ausgeführt.
Prozesskontroll- und Anzeigeprogramme wie bspw. top und htop sind sich auch nicht bewusst, dass die mit firejail ausgeführten Prozesse in einer abgeschotteten Sandbox ausgeführt werden und als Threadname angezeigt wird auch nicht das Programm, sondern firejail selbst.
Android nutzt diese Prozesstrennung des Kernels übrigens ebenfalls, aber da wird es seit etwa Android 10 transparent für alle Prozesse durchgesetzt. Es wirkt nicht aufgesetzt sondern integriert.
Daher wollte ich mal den Thread zum Anlass nehmen um darüber zu debattieren wie bezüglich der Trennung von Prozessen die Zukunft von Debian und allgemein Linux aussehen soll und was da geplant ist?
Ob nun firejail oder AppArmor, wird das immer ein angeflanschter schlecht integrierter Bestandteil sein, der wie ein Fremdkörper wirkt und den man explizit ausführen muss um ihn zu nutzen, oder ist da zukünftig eine wesentliche Besserung in Sicht, so dass mittelfristig diese Schutzfunktion implizit verwendet wird und sich der Nutzer keine Gedanken mehr darüber machen muss?
Auch dann nicht, wenn er bspw. sein eigenes hello world Programm compiliert und das dann in einem Terminal ausführt, für das er natürlich nie eine firejail ode AppArmor Config angelegt hat.
Diese Fähigkeiten wurden in den Linux Kernel generisch implementiert und nutzen kann man sie mit Zusätzen wie firejail und AppArmor.
Aber der große Nachteil ist, dass das alles aufgesetzt wirkt und es ist nicht fest ins System integriert ist.
Wer bspw. firejail nutzen möchte und dabei vergisst seinen Prozess mit einem firejail Befehl vor dem Aufruf des zu startenden Prozesses zu starten, der nutzt diese Prozesstrennung und Sandbox Funktion schlichtweg nicht.
Man muss also immer darauf achten, das man beim Starten:
Code: Alles auswählen
firejail programm
Vergisst man das und gibt nur
Code: Alles auswählen
programm
Nicht viel anders ist es mit den Konfigurationsdateien, die müssen vorher angelegt worden sein, damit das zu startende Programm mit firejail benutzt werden kann.
Bei AppArmor verhält es sich ähnlich, nur mit dem Unterschied, dass es da noch komplizierter zu konfigurieren ist.
In Debian kommen diese Konfigurationsdateien als extra Paket daher. Sie sind kein fester Bestandteil des Programmpakets.
Wer also nicht explizit firejail installiert und dafür sorgt, das sein Paket mit einer Sammlung an Konfigurationsdateien für firejail mitinstalliert wird, der muss ohne diese Funktion auskommen.
Alles wirkt also aufgesetzt und nicht integriert. Startet man ein neues Programm für das es keine Konfiguration gibt, wird man auch nicht danach gefragt eine einzurichten. Das Programm wird dann einfach ohne Sanboxfunktion mit vollen Rechten ausgeführt.
Prozesskontroll- und Anzeigeprogramme wie bspw. top und htop sind sich auch nicht bewusst, dass die mit firejail ausgeführten Prozesse in einer abgeschotteten Sandbox ausgeführt werden und als Threadname angezeigt wird auch nicht das Programm, sondern firejail selbst.
Android nutzt diese Prozesstrennung des Kernels übrigens ebenfalls, aber da wird es seit etwa Android 10 transparent für alle Prozesse durchgesetzt. Es wirkt nicht aufgesetzt sondern integriert.
Daher wollte ich mal den Thread zum Anlass nehmen um darüber zu debattieren wie bezüglich der Trennung von Prozessen die Zukunft von Debian und allgemein Linux aussehen soll und was da geplant ist?
Ob nun firejail oder AppArmor, wird das immer ein angeflanschter schlecht integrierter Bestandteil sein, der wie ein Fremdkörper wirkt und den man explizit ausführen muss um ihn zu nutzen, oder ist da zukünftig eine wesentliche Besserung in Sicht, so dass mittelfristig diese Schutzfunktion implizit verwendet wird und sich der Nutzer keine Gedanken mehr darüber machen muss?
Auch dann nicht, wenn er bspw. sein eigenes hello world Programm compiliert und das dann in einem Terminal ausführt, für das er natürlich nie eine firejail ode AppArmor Config angelegt hat.