Zukunft von AppArmor, firejail usw.? Prozesstrennung weiterhin explizit oder irgendwann implizit?

Alles rund um sicherheitsrelevante Fragen und Probleme.
Antworten
Cordess
Beiträge: 422
Registriert: 09.01.2006 00:37:22

Zukunft von AppArmor, firejail usw.? Prozesstrennung weiterhin explizit oder irgendwann implizit?

Beitrag von Cordess » 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:

Code: Alles auswählen

firejail programm
eingibt.

Vergisst man das und gibt nur

Code: Alles auswählen

programm
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.

schwedenmann
Beiträge: 5525
Registriert: 30.12.2004 15:31:07
Wohnort: Wegberg

Re: Zukunft von AppArmor, firejail usw.? Prozesstrennung weiterhin explizit oder irgendwann implizit?

Beitrag von schwedenmann » 05.03.2021 23:57:51

Hallo


Hägt ev. auch mit Punkt 7 im link zusammen

https://wiki.archlinux.org/index.php/fi ... leshooting


Zudem scheinen mit die profile von firejail,sagen wir mal nicht feingetunt zu sein.
Außerdem stellt sich mir die Frage,was solche Sicherheitssoftware auf einem nicht kritischen, oder in einer nicht kritischen Umgebung (homeserver,homepc) verloren hat.

mfg
schwedenmann

Cordess
Beiträge: 422
Registriert: 09.01.2006 00:37:22

Re: Zukunft von AppArmor, firejail usw.? Prozesstrennung weiterhin explizit oder irgendwann implizit?

Beitrag von Cordess » 06.03.2021 00:25:59

schwedenmann hat geschrieben: ↑ zum Beitrag ↑
05.03.2021 23:57:51
Hägt ev. auch mit Punkt 7 im link zusammen

https://wiki.archlinux.org/index.php/fi ... leshooting
Ja, das sind die Anfangswehen, zeigt aber auch, dass da noch viel Arbeit vorliegt und noch nichts wirklich integriert ist. Aber mir geht's ja jetzt mehr um die langfristige Ausrichtung und der Frage, ob es ewig aufgesetzt wirken wird?
Und hierbei ist es jetzt auch egal ob AppArmor oder firejail das Rennen macht, im Prinzip geht's also allgemein um eine transparente implizite Integration von mandatory access control.
Außerdem stellt sich mir die Frage,was solche Sicherheitssoftware auf einem nicht kritischen, oder in einer nicht kritischen Umgebung (homeserver,homepc) verloren hat.
Das fängt doch schon mit dem Browser an.
Der gehört in eine Sandbox.

Ebenso irgendwelche VoIP Software, IRC Programme, aber auch Spiele mit Netzwerkfunktion.
Also im Grunde alles, was sich auf einem Client irgendwie mit dem Netz verbindet oder dem man nicht den ganzen Nutzeraccount anvertrauen möchte, z.b. weil es proprietäre Software ist.

Aber da hört es nicht auf, denn es kann auch weitergehen mit Programmen die Dateien öffnen und verarbeiten sollen.
Denn diese Dateien könnten ja wiederum vom Netz sein. Man denke nur mal an E-Mail Anhänge.

Insofern würde es auch Sinn machen die Imageprogramme, PDF Reader usw. in eine Sandbox zu stecken, damit man mit denen die Bilder oder PDF Dateien usw. in den E-Mails anzeigen kann.

Im Grunde ist so eine Sandbox ein guter Schutz um Schäden zu minimieren. Das gilt auch für die Bedrohungslage durch Zero Day Lücken.
Und natürlich ist das alles daher auch für den Client relevant und nicht nur für Server.
Android macht es vor.

fossonly
Beiträge: 23
Registriert: 10.06.2020 10:40:38

Re: Zukunft von AppArmor, firejail usw.? Prozesstrennung weiterhin explizit oder irgendwann implizit?

Beitrag von fossonly » 06.03.2021 07:44:17

Fragwürdige Argumentation. Natürlich haben Firejail und AppArmor eine große Zukunft vor sich, und letztlich werden beide kontinuierlich weiterentwickelt. 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. Prinzipiell muss man keines von beidem nutzen, da praktisch jede Software die Schnittstellen diverser Sicherheitsmechanismen im Linux-Kernel direkt ansteuern kann. 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.

Allerdings kann man derartige Sicherheitsmechanismen nicht standardmäßig für alle festlegen, zumal damit außerordentliche Restriktionen einhergehen, die zum einen nicht mit jedem Use-Case kompatibel sind, und zum anderen fortschrittliche Nutzer voraussetzen die auch verstehen was hier passiert. 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. Und ganz gleich was unter Android standardmäßig bezüglich der Apps isoliert wird, dass ist nur ein noch komfortabler Bruchteil dessen was seitens Firejail und AppArmor radikal forciert wird. Mal ganz davon abgesehen das Android in peinlicher Weise horrende Sicherheitslücken sammelt, die bis zum heutigen Tage weit über jenen liegen, die bspw. Debian samt riesigem Repository in Gänze über drei Jahrzehnte jemals hatte. Und Android hat nur knapp 400 MB, aber derart viele und sich stets wiederholende Sicherheitslücken, dass Android nicht im mindesten fähig ist sensible Daten vertraulich zu verarbeiten, geschweige denn Apps insoweit abzuschotten das sie wirklich nur tun können was sie sollen. Praktisch hat Android nichts mit einem soliden GNU/Linux gemeinsam, auch wenn letzteres mittels Flatpak etwas ähnliches auf Lager hat wie Android mit seinem App-Konzept.

Cordess
Beiträge: 422
Registriert: 09.01.2006 00:37:22

Re: Zukunft von AppArmor, firejail usw.? Prozesstrennung weiterhin explizit oder irgendwann implizit?

Beitrag von Cordess » 06.03.2021 11:37:57

fossonly hat geschrieben: ↑ zum Beitrag ↑
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.

irgendwas
Beiträge: 278
Registriert: 04.04.2016 18:53:19
Lizenz eigener Beiträge: MIT Lizenz

Re: Zukunft von AppArmor, firejail usw.? Prozesstrennung weiterhin explizit oder irgendwann implizit?

Beitrag von irgendwas » 06.03.2021 18:05:38

Die Frage wäre bei den Entwicklern wohl am besten aufgehoben. Vielleicht gibt es gute Gründe, die dagegen sprechen und die zumindest hier keiner kennt.

Hast du dort schon mal nachgefragt?

Cordess
Beiträge: 422
Registriert: 09.01.2006 00:37:22

Re: Zukunft von AppArmor, firejail usw.? Prozesstrennung weiterhin explizit oder irgendwann implizit?

Beitrag von Cordess » 06.03.2021 18:30:04

Nein, ich bin in keiner Debian Mailingliste aktiv.
Und dann sind da ja noch die anderen Distributionen, die müssten ja alle an einen Strang ziehen um das entsprechend umzusetzen.
Das würde so etwas großes wie, sagen wir mal der Wechsel zu systemd werden.
Ich wüsste nicht, welche Distirbutionsübergreifende Diskussionsplattform hier die richtige wäre um alle zu erreichen. Da fängt es ja schon an.
Aber mich hätte jetzt interessiert ob die Debianentwickler hier mehr wissen und ob es hier entsprechende Pläne gibt und ja, ich gehe davon aus, dass deutschsprachige Debianentwickler hier mitlesen.

irgendwas
Beiträge: 278
Registriert: 04.04.2016 18:53:19
Lizenz eigener Beiträge: MIT Lizenz

Re: Zukunft von AppArmor, firejail usw.? Prozesstrennung weiterhin explizit oder irgendwann implizit?

Beitrag von irgendwas » 06.03.2021 20:59:12

Cordess hat geschrieben: ↑ zum Beitrag ↑
06.03.2021 18:30:04
Nein, ich bin in keiner Debian Mailingliste aktiv.
Und dann sind da ja noch die anderen Distributionen, die müssten ja alle an einen Strang ziehen um das entsprechend umzusetzen.
Nicht unbedingt. Debian (und die davon anleitenden Distributionen) können mehr oder weniger machen bzw. von Debian übernehmen was sie wollen.

Ich würde den Weg über die Debian Mailingliste gehen und anschließend hier verlinken.

Edit: Das bestimmte Sicherheitsfunktionen nicht per Default aktiviert sind oder "DAU-freundlich" implementiert werden, ist nichts außergewöhnliches. Beispiel: Ich kenne nur sehr wenige Unternehmen, die SRP/SAFER per Gruppenrichtlinien umsetzten, obwohl es das Feature seit Windows XP gibt und Ransomware wirksamen eindämmen würde. Aber die wenigsten Windows-Admins kennen das Feature bzw. führen es erst ein, wenn es zu spät ist.
Zuletzt geändert von irgendwas am 07.03.2021 16:38:37, insgesamt 1-mal geändert.

fossonly
Beiträge: 23
Registriert: 10.06.2020 10:40:38

Re: Zukunft von AppArmor, firejail usw.? Prozesstrennung weiterhin explizit oder irgendwann implizit?

Beitrag von fossonly » 07.03.2021 09:20:05

Deine Argumentation basiert nach wie vor auf Halbwissen und Wunschdenken, und Du wirfst Sachverhalte durcheinander die mit realen Gegebenheiten nicht vereinbar sind. Zuallererst muss man auf technischer Basis begreifen worüber man hier spricht, sonst macht eine Diskussion wenig Sinn. Und nein, man kann ein hochkomplexes Thema wie Sandboxing nicht einfach derart massiv abstrahieren, dass keine Komplexität mehr beim Nutzer ankommt. Nicht ohne merkliche Abstriche in der Sicherheit, die mit der erheblichen Vereinfachung (oberflächliches Sandboxing) unweigerlich einhergehen würden.

Cordess
Beiträge: 422
Registriert: 09.01.2006 00:37:22

Re: Zukunft von AppArmor, firejail usw.? Prozesstrennung weiterhin explizit oder irgendwann implizit?

Beitrag von Cordess » 07.03.2021 22:22:43

fossonly hat geschrieben: ↑ zum Beitrag ↑
07.03.2021 09:20:05
Deine Argumentation basiert nach wie vor auf Halbwissen und Wunschdenken,...
Hör mal zu Junge.

Dein Diskussionsstil ist unter aller Sau. Du kannst gerne sachlich auf das Thema eingehen und deine bloßen Behauptungen begründen, aber dein Ad Hominem, also persönliche Angriffe gegen meine Person, kannst du dir sparen.

Mach das nochmal und du landest bei mir auf der Ignoreliste.

Bis jetzt kamen von dir nur Unterstellungen und heiße Luft, aber nichts fundiertes und nichts sachliches. Und nichts davon wurde technisch begründet, also fasse dich mal selber an die Nase anstatt hier nur rumzuschwurbeln und andere persönlich anzugreifen.

Benutzeravatar
TRex
Moderator
Beiträge: 8038
Registriert: 23.11.2006 12:23:54
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: KA

Re: Zukunft von AppArmor, firejail usw.? Prozesstrennung weiterhin explizit oder irgendwann implizit?

Beitrag von TRex » 07.03.2021 22:41:36

Cordess hat geschrieben: ↑ zum Beitrag ↑
07.03.2021 22:22:43
Hör mal zu Junge.
Cordess hat geschrieben: ↑ zum Beitrag ↑
07.03.2021 22:22:43
Ad Hominem, also persönliche Angriffe gegen meine Person
Case closed?

Jemandem hingegen zu sagen, dass die Argumentation nicht stichhaltig ist, fällt meines Erachtens nach nicht darunter.
Jesus saves. Buddha does incremental backups.
Windows ist doof, Linux funktioniert nichtDon't break debian!Wie man widerspricht

Cordess
Beiträge: 422
Registriert: 09.01.2006 00:37:22

Re: Zukunft von AppArmor, firejail usw.? Prozesstrennung weiterhin explizit oder irgendwann implizit?

Beitrag von Cordess » 07.03.2021 23:22:32

TRex hat geschrieben: ↑ zum Beitrag ↑
07.03.2021 22:41:36
Jemandem hingegen zu sagen, dass die Argumentation nicht stichhaltig ist, fällt meines Erachtens nach nicht darunter.
Er hat schon oben mit dem Unsinn angefangen.
Man denke da nur mal an folgenden Satz oben:
Fragwürdige Argumentation
In seinem nächsten Kommentar greift er dann nochmal auf der persönlichen Ebene ohne Anlass an.
Normale Menschen diskutieren über die Sache, dafür habe ich den Thread auch eröffnet, sie machen den Diskussionpartner aber nicht zum Thema.
Auch kennt er mich nicht, deswegen sind seine Unterstellungen eine Beleidigung.

Guckt man sich dann noch an, was er zur Sache zu sagen hat. Dann sind das wolkige Behauptungen, verpackt in Aussagen die zwar technisch klingen sollen, aber nie konkret werden und auch nichts konkretes an sich haben. Also so ne Art BWL-Manager-Speech wo man dann mit blumigen Wörtern wie "Cloud", "Synergien", "Systemimmanent", "face to face", "Web 2.0" , "Chancen" irgendwelche heiße Luft versprüht aber nichts konkretes sagt, also Bullshitbingo macht. Das tut er um seine eigenen technischen Defizite zu verschleiern. Im Grunde hat er aber auf der technischen Ebene gar nichts sinnvolles gesagt.

Beispiel:
und Du wirfst Sachverhalte durcheinander die mit realen Gegebenheiten nicht vereinbar sind.
Zuerst die beleidigende Behauptung, dann gefolgt von einer wolkigen Behauptung ohne Begründung. Warum, weshalb, das wird nicht erwähnt, da wird er nicht konkret und liefert auch kein Beispiel oder technische Begründung. Und wenn er das liefern hätte können, dann wäre seine Beleidigung auch nicht nötig, denn jemand der sich auskennt, hat so etwas nicht nötig.

Dann geht's weiter:
Zuallererst muss man auf technischer Basis begreifen worüber man hier spricht, sonst macht eine Diskussion wenig Sinn.
Wieder eine Unterstellung und beleidigende Behauptung. Gefolgt von einer Schlussfolgerung, deren Basis eine Behauptung ist. Wieder keine konkrete technische Argumentation des weshalbs und warums.

Dann geht's weiter:
Und nein, man kann ein hochkomplexes Thema wie Sandboxing nicht einfach derart massiv abstrahieren, dass keine Komplexität mehr beim Nutzer ankommt.
Wieder heiße Luft. Dass das Thema Sandboxing hochkomplex sein soll, dass behauptet er, stellt es aber auf kein technisches sachliches argumentativ begründetes Fundamant, zudem suggeriert er mit dieser Behauptung, dass ich das nicht wüsste, worin die nächste Beleidigung enthalten ist.
Ein Beispiel, warum man es nicht abstrahieren könne, liefert er auch nicht um seine bloße Behauptung und nichts anders ist es, zu untermauern. Und dann müsste er es so untermauern, dass es ihm Rahmen der Frage in den Kontext passt. Also begründen, warum es überhaupt ein Problem für die Thematik darstellt.

Und am Satzende ist es wieder eine Unterstellung. Denn ich sprach lediglich davon Komplexität zu abstrahieren, so macht man das in der Informatik. Er macht aber daraus ein "dass gar keine Komplexität mehr ankommen soll", was natürlich blödsinniges Geschwurbel ist, denn derartiges hat keiner gefordert oder behauptet.

Und auch der Schlusssatz ist lediglich eine Behauptung unterhalb der von ihm selbstausgedachten Unterstellung, dass gar keine Komplexität beim Nutzer ankommen dürfe, was aber niemand behauptet hat.
Und nein, man kann ein hochkomplexes Thema wie Sandboxing nicht einfach derart massiv abstrahieren, dass keine Komplexität mehr beim Nutzer ankommt.
Sein ganzer Beitrag ist also nur Schrott. Denn er besteht nur aus Beleidigungen, Unterstellungen und Behauptungen. Und die Behauptungen die er in den Raum stellt, begründet er nicht technisch und auch nicht anhand von Beispielen oder dem wieso, weshalb warum. Und das, weil er es nicht kann. Er will hier wohl nur schlau klingen, sich wichtig machen und blast deswegen heiße Luft herum.

Darauf habe ich keine Lust und muss ich mir von dem auch nicht anhören. Wenn er etwas beitragen möchte und etwas sinnvolles beizutragen hat, dann soll er es auf der Sachebene machen und das mit einem technischen Fundament begründen und nicht bloße Behauptungen in den Raum stellen und heiße Luft versprühen und den anderen dabei einfach nur beleidigen.
Diese Diskussion ist zum Erötern da, zum Aufstellen von pro und Contra, Vorschlägen, Begründungen, Lösungen wie man es umsetzen könnte usw. aber nicht für Ad Hominem und leerem Geschwurbel.

irgendwas
Beiträge: 278
Registriert: 04.04.2016 18:53:19
Lizenz eigener Beiträge: MIT Lizenz

Re: Zukunft von AppArmor, firejail usw.? Prozesstrennung weiterhin explizit oder irgendwann implizit?

Beitrag von irgendwas » 07.03.2021 23:34:31

Das Eingangsposting hat interessant angefangen. Dann wurde das Thema mit deinen letzten beiden Beiträgen gegen die Wand gefahren. :roll: Ich bin raus. Viel Spaß noch.

P.S. Eine Verlinkung zur Mailingliste ist (aus meiner Sicht) nicht mehr notwendig.

Cordess
Beiträge: 422
Registriert: 09.01.2006 00:37:22

Re: Zukunft von AppArmor, firejail usw.? Prozesstrennung weiterhin explizit oder irgendwann implizit?

Beitrag von Cordess » 07.03.2021 23:51:21

irgendwas hat geschrieben: ↑ zum Beitrag ↑
07.03.2021 23:34:31
Das Eingangsposting hat interessant angefangen. Dann wurde das Thema mit deinen letzten beiden Beiträgen gegen die Wand gefahren. :roll: Ich bin raus. Viel Spaß noch.
Na dann nimm doch den, der hier nicht auf die Sache eingeht, sondern nur beleidigt und wahrscheinlich im Thread eigentlich nur von Anfang an die Absicht hatte nur zu trollen und den Thread zu sabotieren auch noch in Schutz. :facepalm:

Da kann man dir dann auch nicht helfen, dann bist du halt raus und der Thread ist ohne dich noch da.
Rückendeckung wäre nett gewesen, aber wahrscheinlich hast du die persönlichen Angriffe gar nicht bemerkt und darin liegt das Problem, aber es ist nicht meines, sondern halt deines. Ich tippe mal auf fehlende Sensibilität für so etwas.

Wenn hier alle so komisch drauf sind. Der Mod hat ja auch keine Rückendeckung gegeben und den Beleidiger "fossonly" mit schlechtem Diskussionsstil auch nicht ermahnt, dann ist hier ohnehin keine sinnvolle erwachsene Diskussion durchführbar.

Zum Ad Hominem noch eine Lernstunde:
https://www.youtube.com/watch?v=H-8DkXxhZf0

eggy
Beiträge: 3331
Registriert: 10.05.2008 11:23:50

Re: Zukunft von AppArmor, firejail usw.? Prozesstrennung weiterhin explizit oder irgendwann implizit?

Beitrag von eggy » 08.03.2021 00:31:13

irgendwas hat geschrieben: ↑ zum Beitrag ↑
07.03.2021 23:34:31
Das Eingangsposting hat interessant angefangen. Dann wurde das Thema mit deinen letzten beiden Beiträgen gegen die Wand gefahren. :roll: Ich bin raus.
Seh ich auch so. Ich hatte sogar schon angefangen, Belege für meine Argumente zusammen zu suchen, aber wenn Du (@Cordess) auf Sachen, die Du nicht hören willst, so reagierst, hab ich wenig bis überhaupt keine Lust begründete Aussagen zu treffen.

Daher nur die Kurzfassung:
Was Du vorschlägst, ist aus Usersicht ne Zumutung: stellt Dir mal Oma Irmtraud vor, wie Karl Klammer sie fragt, ob die SHA Summe für die Register reinitialisiert werden dürfen oder die Photonenkanonen steuerboardseitig nachgeladen werden sollen ... so kommt sowas nämlich beim Enduser an, und das dann im Sekundentakt. Juchyuu.
Und auch aus Systemsicht ne Katastrophe. Zähl mal wie viele, wirklich teure, Kontextswitche so ein Ansatz benötigt. Ich würde sagen, zieht man das konsequent durch .. 5% bis 10%, oder wenns ganz arg beschissen läuft vielleicht sogar bis 20% der Gesamtleistung des Systems - aller Systeme. Weltweit. Aber wir haben's ja, weg mit der Energie, die nachfolgenden Generationen werden das schon irgendwie fixen. Polemik, ja klar. Aber wie war das bei Spectre und Meltdown? Gleiche Größenordnung. Minimum.
usw.
Also ja, das Thema Sandboxing ist hochkomplex. Schon daher, weil hier alle Systemkomponenten und das Problem von Semantischen Entscheidungen zusammenfallen. Also bitte, nicht gleich einschnappen, wenn Dir jemand das mal offen sagt. Klingt auf dem Papier zwar alles hübsch einfach, aber sobald man mal unter die Haube schaut, wird klar, warum das alles andere als trivial ist. Als Einstieg: versuchs mal mit den Büchern von A. Tanenbaum.

Cordess
Beiträge: 422
Registriert: 09.01.2006 00:37:22

Re: Zukunft von AppArmor, firejail usw.? Prozesstrennung weiterhin explizit oder irgendwann implizit?

Beitrag von Cordess » 08.03.2021 01:03:51

eggy hat geschrieben: ↑ zum Beitrag ↑
08.03.2021 00:31:13
Seh ich auch so. Ich hatte sogar schon angefangen, Belege für meine Argumente zusammen zu suchen, aber wenn Du (@Cordess) auf Sachen, die Du nicht hören willst, so reagierst,
Du schreibst viel Halbwissen und Wunschdenken, die Diskussion ist hier doch Perlen vor die Säue.


So gefällt es dir zu diskutieren? Na dann wohl bekommst. 8O

Was Du vorschlägst, ist aus Usersicht ne Zumutung: stellt Dir mal Oma Irmtraud vor, wie Karl Klammer sie fragt, ob die SHA Summe für die Register reinitialisiert werden dürfen oder die Photonenkanonen steuerboardseitig nachgeladen werden sollen ... so kommt sowas nämlich beim Enduser an, und das dann im Sekundentakt. Juchyuu.
Warum sollte das passieren, und warum im Sekundentakt?

Die Regel wird EINMAL angelegt, man wird EINMAL gefragt wenn es nicht das Paket gleich mitliefert. Dann kommt dass in die Datenbank und man wird nie wieder danach gefragt.
Das passiert dann auch nicht im Sekundentakt.
Und auch aus Systemsicht ne Katastrophe. Zähl mal wie viele, wirklich teure, Kontextswitche so ein Ansatz benötigt.
Die Konfigurationsabfragen? Einmal, dann nie wieder.

Und zum Rest, Guck dir doch mal an, wie es im Kernel Quellcode umgesetzt wurde. Da ist das performant und effizient und so bleibt das auch.
Schließlich geht's hier aus Usabilitysicht lediglich um die Konfiguration.

Der Perfomance Impact durch die Abschottung der einzelnen Prozesse untereinander hält sich in Grenzen, dafür gewinnt man an Sicherheit.
Auf die schnelle habe ich folgenden Benchmarkvergleich gefunden, leider etwas alt und da geht's noch um irgendeine Änderung, aber besser als nichts:
https://www.phoronix.com/scan.php?page= ... 5-72-Tests

Für mehr Sicherheit ist das akzeptabel. Auf Vielkernern wird das kaum ins Gewicht fallen.
Ich würde sagen, zieht man das konsequent durch .. 5% bis 10%, oder wenns ganz arg beschissen läuft vielleicht sogar bis 20% der Gesamtleistung des Systems - aller Systeme. Weltweit.
Nach obigem Benchmark sind es 5 %, also in den meisten Fällen kaum relevant.
Im normalen Alltag wird das nur selten relevant, da die meisten Rechner sowieso im IDLE laufen. Vor allem auf dem Desktop.
Lediglich die Gamerfraktion wird sich darüber ärgern und die Wissenschaftler können es auf ihren abgeschotteten Supercomputern auch abschalten. Die Gamer natürlich auch, Bootoption dann apparmor=0.
Aber wir haben's ja, weg mit der Energie, die nachfolgenden Generationen werden das schon irgendwie fixen.
Sieh es mal so, das sind dann ein paar Bitcoinminer weniger, die die Ahnungslosigkeit der Nutzer ausnutzen können.
Also spart man auch Energie und solange auf der Welt gemined wird, ist das ohnehin kein Thema.
Polemik, ja klar. Aber wie war das bei Spectre und Meltdown? Gleiche Größenordnung. Minimum.
Die Welt dreht sich weiter. Die Sensibilisierung für Sicherheitslücken stieg.
Also bitte, nicht gleich einschnappen, wenn Dir jemand das mal offen sagt.
Das hat er nicht. Er ist nicht auf der Sachebene eingestiegen, sondern er hat auf der persönlichen Ebene angegriffen und sich somit von der Diskussion selbst disqualifiziert.
Denn er hat nichtmal kapiert, dass man im Brainstorming Hypothesen ans schwarze Brett schreiben darf und derjenige, der dann den, der es aufs schwarze Brett geschrieben hat, angreift, sich selbst disqualifiziert.
Als Einstieg: versuchs mal mit den Büchern von A. Tanenbaum.
Habe ich schon vor 20 Jahren gelesen. Kenne ich in und auswendig. Nichts neues für mich, aber ich wünsche dir natürlich viel Spaß bei nächsten Kapitel.

Zum Letzten Satz, ja, das ist doch die Form des Diskussionsstil nach dem du gebeten hast und du und irgendwas so gerne verteidigen. Toll oder, macht gleich Lust auf mehr. Also viel Spaß mit Kapitel 2 im Tanenbaum Buch.

eggy
Beiträge: 3331
Registriert: 10.05.2008 11:23:50

Re: Zukunft von AppArmor, firejail usw.? Prozesstrennung weiterhin explizit oder irgendwann implizit?

Beitrag von eggy » 08.03.2021 04:55:35

Cordess hat geschrieben: ↑ zum Beitrag ↑
08.03.2021 01:03:51
Du schreibst viel Halbwissen und Wunschdenken
Wo?

irgendwas
Beiträge: 278
Registriert: 04.04.2016 18:53:19
Lizenz eigener Beiträge: MIT Lizenz

Re: Zukunft von AppArmor, firejail usw.? Prozesstrennung weiterhin explizit oder irgendwann implizit?

Beitrag von irgendwas » 08.03.2021 05:40:42

Cordess hat geschrieben: ↑ zum Beitrag ↑
07.03.2021 23:51:21
Rückendeckung wäre nett gewesen
Bei deiner sehr aggressiven Schreibweise? Nein danke.

Ich finde in fossonly's Beiträgen keine Beleidigungen oder persönliche Angriffe. Keine Ahnung wo deine persönliche Schmerzgrenze liegt, aber anscheinend sehr weit unten. Vielleicht interpretierst du auch etwas hinein, dass fossonly gar nicht geschrieben/gemeint hat? Ich weiß es nicht und es ist mir inzwischen eigentlich auch völlig egal.

Entspann dich und lies die Beiträge nochmal ganz in Ruhe. Wenn du dann von jemanden Quellenangaben/Belege möchtest, dann bitte freundlich darum.

Vorschlag an die Moderation:
Diese Beiträge löschen
viewtopic.php?p=1266501#p1266501
viewtopic.php?p=1266502#p1266502
viewtopic.php?p=1266505#p1266505
viewtopic.php?p=1266506#p1266506
viewtopic.php?p=1266507#p1266507
viewtopic.php?p=1266512#p1266512

debianoli
Beiträge: 4068
Registriert: 07.11.2007 13:58:49
Wohnort: Augschburg

Re: Zukunft von AppArmor, firejail usw.? Prozesstrennung weiterhin explizit oder irgendwann implizit?

Beitrag von debianoli » 08.03.2021 06:51:03

Sagt mal, muss das Theater sein?

Man kann auch dezent zurückschießen, ohne gleich in die Volleskalation zu gehen.

Normalerweise würde ich den Ratschlag "tief durchatmen, ein Bier in der Kneipe trinken und dann am nächsten Tag antworten" geben. Aber das geht ja gerade leider nicht.

Benutzeravatar
novalix
Beiträge: 1908
Registriert: 05.10.2005 12:32:57
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: elberfeld

Re: Zukunft von AppArmor, firejail usw.? Prozesstrennung weiterhin explizit oder irgendwann implizit?

Beitrag von novalix » 08.03.2021 14:27:19

Erstaunlich, dass hier SELinux noch nicht zur Sprache gekommen ist. Das ermöglicht doch mal einen Blick über den Zaun auf das Nachbargehöft RPM-basierter Distros.
Red Hat hat ja schon Mitte der 0-er Jahre begonnen aktivierte rule sets per default aus zu rollen, zunächst in Fedora. Novell/Suse hat damals mit AppArmor dagegen gehalten. [*]

Die Diskussion und die Bemühungen zur Umsetzung sind also locker schon 15 Jahre alt.

Wer jemals ein z.B. CentOS administriert hat, ist mit an Sicherheit grenzender Wahrscheinlichkeit schon mal in die Situation gekommen, dass eine installierte Software den Dienst verweigert hat, weil irgendwas in den rules geklemmt hat.
Solche Probleme zu lösen ist selbst für erfahrene Admins oft nicht trivial. Da wird ganz offensichtlich sehr viel copy and paste aus stackoverflow betrieben, um irgendwie weiter zu kommen.
Ich behaupte mal, dass auf RH-basierten Systemen das pauschale Abschalten der SELinux-Struktur der meist abgesetzte Einzelbefehl ever ist.

Sicherheit von Computersystemen findet man nicht ausschließlich auf Datenblättern. Entscheidend ist, was zur Anwendung kommt.

[*] Debian hatte damals mit etch ebenfalls SELinux standardmäßig installiert, allerdings ohne aktivierte rule sets.
Das Wem, Wieviel, Wann, Wozu und Wie zu bestimmen ist aber nicht jedermannns Sache und ist nicht leicht.
Darum ist das Richtige selten, lobenswert und schön.

smiler
Beiträge: 117
Registriert: 31.03.2004 21:26:06

Re: Zukunft von AppArmor, firejail usw.? Prozesstrennung weiterhin explizit oder irgendwann implizit?

Beitrag von smiler » 08.03.2021 15:33:47

novalix hat geschrieben: ↑ zum Beitrag ↑
08.03.2021 14:27:19

Wer jemals ein z.B. CentOS administriert hat, ist mit an Sicherheit grenzender Wahrscheinlichkeit schon mal in die Situation gekommen, dass eine installierte Software den Dienst verweigert hat, weil irgendwas in den rules geklemmt hat.
Solche Probleme zu lösen ist selbst für erfahrene Admins oft nicht trivial. Da wird ganz offensichtlich sehr viel copy and paste aus stackoverflow betrieben, um irgendwie weiter zu kommen.
Ich behaupte mal, dass auf RH-basierten Systemen das pauschale Abschalten der SELinux-Struktur der meist abgesetzte Einzelbefehl ever ist.
haha, ja, kann ich so bestätigen aus meiner Erfahrung...
Wobei ich dazu sagen muss, dass es in den letzten Jahren um einiges besser geworden ist als noch zu rhel 5 Zeiten. Im Regelfall kommt man auch mit eingeschaltetem selinux heutzutage sehr weit. Das mitgelieferte Ruleset ist ziemlich gut geworden.
Nur bei sehr exotischen Pfaden und Applikationen ist noch Nacharbeit notwendig, die unter Umständen aber die betreffende Person in ziemliche Verzweiflung stürzen kann. Die helfenden Tools sind schon nicht schlecht, aber wenn man nicht täglich damit zu tun hat steht man relativ schnell hilflos da und es läuft auf stackoverflow hinaus...
Die zu findende Doku ist meiner Meinung nach definitv nicht ausreichend um da unterstützend zu sein.
Inzwischen ist selinux auf der überwiegenden Zahl der Server, die ich mit betreue aktiviert, bis auf einige Altlasten und besonders exotische Systeme/Applikationen.
Bin eigentlich ein Freund von selinux, aber im "realen Einsatz" gibt es bei der Usability noch Raum für Verbesserungen

Antworten