wanne hat geschrieben: 20.07.2020 11:43:22
Nr 1. Der von dir genannte Systemd. Der hat alleine mehr Code als alles was früher abseits von Kernel als root gelaufen ist.
Wieder diese absurden Vorurteile. Erstens ist systemd absolut modular, wo lediglich wenig Code tatsächlich unter Rootrechten agiert, und zweitens werden auch die ganzen ausgegliederten Module mit eingeschränkten Privilegien betrieben. Unter Debian kommt zudem nur ein kleiner Bruchteil der verfügbaren Module seitens systemd zum Einsatz. Selbst neu hinzugekommene Funktionen von systemd, wie kürzlich erst homed, repart und mehr, werden übergangsweise erst mal deaktiviert bis zur Serienreife. Zudem bildet systemd eine Basis um gerade erheblich zu reduzieren, dass Programme mit unnötig hohen Privilegien gestartet werden müssen, verglichen zu den unkontrollierten Gegebenheiten früherer Zeit, samt qualitativ sehr variabler Shellscripte.
Abseits von Gnome hat das nie jemand gemacht und Gnome war eine Nische.
Das ist bewiesenermaßen Unsinn. Genau genommen war Gnome das erste DE, dass möglicht gemacht hat Xorg ohne Rootrechte einzusetzen. Es hat eine halbe Ewigkeit gedauert bis andere DE hier mal nachgezogen sind, wobei manche heute noch nicht soweit sind.
Aber ein Frontend mit einem Backend mit Root rechten hat eben defakto root rechte.
Das widerspricht vollkommen der zugrundeliegenden Architektur des heutigen Gnome. Ich kann zwar nicht hundertprozentig sicher sagen, wie das noch vor Jahren ausgesehen hat, zumal ich damals noch nicht mit dem Design vertraut war, aber heute ist Gnome eines der sicherheitstechnisch fortschrittlichsten DE.
Aber mit NetworkManager, gvfsd... zieht das immer mehr auch auf professionellen Systemen ein, dass Otto-Normaluser mit defakto root rechten rum läuft.
Prinzipiell muss niemand den NetworkManager verwenden, auch wenn das angebliche Risiko dadurch fragwürdig erscheint. Und gvfsd dient der Verwaltung von Ressourcen, auf Basis eingeschränkt gewährter Privilegien. Ein Praxisbeispiel diesbezüglich wäre die partielle Ausweitung von Privilegien, mittels "admin:///Pfad_zur_Datei" unter Nautilus, um einzelne Dateien sicher ändern zu können die nur Root bearbeiten kann. Hierfür wird die Anfrage an Polkit delegiert, um ausschliesslich partielle Privilegien zum bearbeiten dieser einen Datei zu gewähren. So gesehen die Alternative unter Wayland, anstatt wie früher unter Xorg den ganzen Dateimanager dauerhaft mit Rootrechten zu starten.
Hier an der UNI haben sie aufgegeben und an den Poolrechnern SSH dicht gemacht, weil ein reibungsfreier Multiuserbetrieb auf nem modernen Linux nicht mehr zu gewährleisten war.
Das klingt schon sehr nach Unfähigkeit, wobei ich von einer Uni kaum groß etwas erwarte, und es bereits an ein Wunder grenzt das man über Windows hinausgekommen ist.
SUSE ermöglich so schnell immer mehr Sachen als User dass die nicht mehr hinter her kamen das alles abzudichten.
Ohne weitergehende Informationen ziemlich nichtssagend. Auch wenn das höchst sonderbar klingt.
Es reicht völlig das Frontend zu manipulieren um im Backend Aktionen als root hervorzurufen. Genau das ist der Windows-Way der da immer wieder angegriffen wird.
In welchem Zusammenhang? SUSE?
Vor 10 Jahren gab es 200-System Calls die du überwachen musstest und über die sich Angreifer erhöhte Rechte holen konnten. Jetzt hast du ein viele Tausend verschiedene dbus-Message Typen die von Programmen mit root-Rechten interpretiert werden. Das ist einfach eine so viel größere Angriffsfläche.
Natürlich wächst die Komplexität mit den gestiegenen Anforderungen. Und dennoch war dbus notwendig um einen sichereren IPC-Mechanismus zu etablieren. Und es ist ja nicht so als könne dbus nicht präventiv gehärtet werden, was bspw. ohne großen Aufwand mittels firejail oder AppArmor möglich ist. Selbst über flatpak wird das regulär abgesichert. Eigentlich sollten weitaus mehr Nutzer auf Sandboxing zurückgreifen, um viele potenzielle Angriffsvektoren erst gar nicht zu ermöglichen. Die Anzahl der Syscalls hat sich bis heute auch auf über 300 erweitert, und mit Stand Linux 5.9 kamen auch wieder neue Capabilities hinzu, womit es mittlerweile schon 40 sind.