Installationsort Browser/Autoupdates und Sicherheit

[fossonly]

Tausende Prozesse die als Admin laufen. Auf der anderen Seite bekommen wir das unter Linux auch immer mehr. Und wir sehen wie die Angriffe auf Linux im Moment gerade durch die Decke gehen.

Ich sehe seit vielen Jahren den genau gegenteiligen Trend, nämlich das die Verwendung von Rootrechten konsequent eliminiert wird, und Alternativen wie, dauerhaft partiell vergebene wirklich notwendige Capabilities für Binaries, Polkit um partielle zeitlich beschränkte Privilegien an modulare Programme zu delegieren, oder indem in erhöhtem Maße ab Werk Seccomp und Namespaces zum Einsatz kommen. Selbst im Zusammenspiel mit systemd wächst die Anzahl der Programme, die über die eigenen Units ab Werk auf das einfach nutzbare Sandboxing zurückgreifen. Wo läuft also immer mehr mit Rootrechten? Auch im Bezug auf ganze DEs wie bspw. Gnome, wurde die Nutzung von Rootrechten drastisch reduziert, was unter anderem durch systemd für Xorg möglich wurde, und unter Wayland für grafische Programme direkt verboten wird. Viele Gnome eigene Programme sind heute auch längst modular designt, womit die GUI stets unter Nutzerrechten läuft, während mittels Polkit für administrative Aufgaben partielle Privilegien gewährt werden. Ich finde es auch nicht sonderlich erheblich das Angriffe auf Linux ansteigen, zumal sie mehrheitlich nicht erfolgreich sind, und die erfolgreichen sich meist ohnehin auf schändliche proprietäre Geräte beschränken, die sowohl jedes solide GNU/Linux beleidigen als auch jedes Mindestmaß an IT-Sicherheit ignorieren.

[wanne]

Wo läuft also immer mehr mit Rootrechten? Auch im Bezug auf ganze DEs wie bspw. Gnome, wurde die Nutzung von Rootrechten drastisch reduziert, was unter anderem durch systemd für Xorg möglich wurde

Nr 1. Der von dir genannte Systemd. Der hat alleine mehr Code als alles was früher abseits von Kernel als root gelaufen ist.

Viele Gnome eigene Programme sind heute auch längst modular designt, womit die GUI stets unter Nutzerrechten läuft, während mittels Polkit für administrative Aufgaben partielle Privilegien gewährt werden.

Nr 2. ist alles was so mit Gnome und die Freedesktop-Projekte der gleichen Entwickler kam. X11 Programme mit erhöhten Rechten waren schon immer ein nogo. Abseits von Gnome hat das nie jemand gemacht und Gnome war eine Nische. Aber ein Frontend mit einem Backend mit Root rechten hat eben defakto root rechte.
Aber mit NetworkManager, gvfsd... zieht das immer mehr auch auf professionellen Systemen ein, dass Otto-Normaluser mit defakto root rechten rum läuft. 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. SUSE ermöglich so schnell immer mehr Sachen als User dass die nicht mehr hinter her kamen das alles abzudichten. 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.
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.

[fossonly]

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.

[wanne]

Wieder diese absurden Vorurteile. Erstens ist systemd absolut modular, wo lediglich wenig Code tatsächlich unter Rootrechten agiert

Bulshit. /lib/systemd/systemd läuft als root und interpretiert damit so ein mal fast alles was unter /lib/systemd/ liegt als root. Und das ist (stand Debian 10) etwa 10 mal mehr Code als alle bash scripte unter Debian 8 unter /etc/init.d zusammen. – Und der Code ist um Größenordnungen schlechter gewartet als die Scripte zuvor. Systemd hat so viele Issues offen wie die Shellscripte aus früheren Zeiten insgesamt Zeilen.
Und ja: Das sind zum größten teil keine "Bugs" sondern halt meist stinken doofes Verhalten alla "0day" oder dass Hibernatete alternativlinuxe per default zerschossen werden. – Aber es gibt jetzt eine Option (die das alternativ System setzen muss) um das zu verhindern...
Die Shellscripte hatten vernünftiges Error-Handling. Das fehlt Systemd wegen falsch verstandener "Abwärtskompatibilität" vollständig. Die ini-Files sind sicherheitstechnisch ein Graus.

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.

Natilus kann jetzt also prinzipiell /sbin/init bearbeiten und hat damit volle root-rechte. Wer eine Lücke im Nautilus (der mit libs ein paar zig MiB Code hat) findet und ihn dazu bringt (statt der gewnüschten) kann beliebigen Code als root ausführen. Dann kommuniziert das Ding über dbus: Wer da Nachrichten manipulieren kann, bekommt root rechte und dazu kommt nochmal Polkit – Das dort Fehler instant zu root-Rechten führen dürfte allgemein klar sein.
Zum Vergleich früher: Ich hatte als ein 64kiB getty als von User angreifbaren Code mit root-Rechten laufen und fertig.
Partielle Ausweitung von Rechten ist der Tod von Security. Jedes Tool, dass rechte lediglich partiell ausweiten können soll wird instantan zu sicherheitsrelevantem Code. Meist ohne dass es je für so etwas gedacht war.

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.

Whooohoo wir haben noch nicht genug sicherheitsrelevanten der Lücken hat eingebaut lass nochmal tonnenweise drauf werfen.

wie früher unter Xorg den ganzen Dateimanager dauerhaft mit Rootrechten zu starten.

Das hat man nie ernsthaft gemacht.

und es bereits an ein Wunder grenzt das man über Windows hinausgekommen ist.

Offensichtlich hast du noch nie eine von innen gesehen. Sonst würdest du verstehen, warum der Satz so falsch ist.

aber heute ist Gnome eines der sicherheitstechnisch fortschrittlichsten DE.

Es ist vor allem am fortschrittlichsten dabei die Angriffsfläche immer noch größer zu machen. Das ist wirklich fortschrittlich weil alle anderen nachziehen. Aber eben sicher nicht der Sicherheit zuträglich.

[hikaru]

Deshalb weiß mein Standard- Browser (FF Beta), mit dem ich hier unterwegs bin noch nicht einmal dass es Banken gibt.
Die Letzte Überweisung via Browser hab ich so ungefähr vor 20 Jahre ausgeführt.
Wenn ich wirklich mal via Browser an mein Konto muss (tonnenweise Post abholen ),
mach ich das mit Chromium über diesen Weg:

Code: Alles auswählen

firejail --private=~/.privat-browser/Chromium   /usr/bin/chromium %U

Chromium wird auch ausschließlich dafür genutzt.
Alles andere geht über eine ziemlich kastrierte Win10 - VM via HBCI / Foto TAN mit einem Banking - Programm.

Halte ich beides für kreuzgefährlich.

Einen Browser für speziell diesen Zweck in eine Sandbox zu stecken, schön und gut. Aber ausgerechnet Chromium? Ich bin der Meinung, dass dessen Codebasis nicht unabhängig verständlich ist und die Debian-Maintainer des Pakets inkompetent sind. Davon, dass das "Open Source" ist hat man also nichts. Wenn Google da Schweinereien im Code versteckt hat, wird die wohl kaum einer entdecken. Mit Chromium würde ich maximal passiv auf Wikipedia surfen, dem Browser aber sicher keine persönlichen Daten anvertrauen, schon gar keine Banking-Logins.

Ähnlich sieht's mit Windows als Banking-VM aus. Eine dedizierte Banking-VM zu haben ist sinnvoll, aber darin dann ein Closed-Source-Betriebssystem zu betreiben, bei dem keiner auch nur prinzipiell prüfen könnte, dass es vertrauenswürdig arbeitet, führt das Ganze ad absurdum.

[willy4711]

Einen Browser für speziell diesen Zweck in eine Sandbox zu stecken, schön und gut. Aber ausgerechnet Chromium? Ich bin der Meinung, dass dessen Codebasis nicht unabhängig verständlich ist und die Debian-Maintainer des Pakets inkompetent sind.

Gegenvorschlag ?
Es gibt doch eh nur noch Browser, die entweder mit der Chromium Engine oder der FF Engine laufen.
Schützt mich z.B. Tor-Browser besser ? Läuft ja auch auf Basis von Firefox.
Den nochmal in Firejail eingesperrt, komme ich praktisch in keinen Ordner (selbst im /home oder andere gemountete Laufwerke )
Aber das ist in dieser Konfiguration (firejail --private=~/.privat-browser/........) bei allen Browsern gleich.

Wäre also die Frage, was überhaupt mit Sicherheit gemeint ist.

Ähnlich sieht's mit Windows als Banking-VM aus. Eine dedizierte Banking-VM zu haben ist sinnvoll, aber darin dann ein Closed-Source-Betriebssystem zu betreiben, bei dem keiner auch nur prinzipiell prüfen könnte, dass es vertrauenswürdig arbeitet, führt das Ganze ad absurdum.

Das muss aber mal genauer definiert werden.
Meinst du, dass das Betriebssystem / Banking- Software meine Bankdaten abzieht/abziehen könnte ?
Ich meine, wäre das der Fall, wäre es schon längst bekannt geworden. Mir ist ein solcher Fall nicht bekannt.
Ich mache seit nunmehr 25 Jahren meine Bankgeschäfte über das Internet (anfangs noch mit BTX - Übertragung), und hatte
noch nie irgend ein Problem.

Für mich ist dabei wichtig, dass die Verbindung zu meiner Bank sicher ist, wenn ich Überweisungen mache. Nur in diesem Fall brauche ich
eine möglichst sichere, nicht abhörbare oder zu manipulierende Verbindung. HBCI mit PhotoTan ist nun mal nur über Banking Software zu realisieren.
Ich habe unter Linux noch nichts gefunden, was vernünftig mit diesem Verfahren funktioniert.

So jetzt zurück zum Installationsort Browser/Autoupdates und Sicherheit:

Grad meldet mit FF, das ein Update zu Verfügung stünde.
Hab mal wieder wegen der Prügel auf root:root gestellt. Und bin jetzt hilflos:
Wenn ich die neue Version mit Root-Rechten nach /opt/firefox kopiere, wird FF im Anschluss wahrscheinlich ein neues Profil anlegen wollen
werde es aber trotzdem erstmal testen.
Klappt das nicht, werde ich für das Update wieder in den "Usermodus" gehen und anschließend wieder auf Root.
Dann hoffe ich mal, dass während des FF-Updates nicht FF oder gar mein System kompromittiert ist.

[thoerb]

Wenn ich die neue Version mit Root-Rechten nach /opt/firefox kopiere, wird FF im Anschluss wahrscheinlich ein neues Profil anlegen wollen

Nein, denn das ist im Homeverzeichnis schon vorhanden.

[hikaru]

Gegenvorschlag ?

Firefox statt Chromium.

Meinst du, dass das Betriebssystem / Banking- Software meine Bankdaten abzieht/abziehen könnte ?

Denkbar.
Das Problem ist, dass du bei Closed Source nie sicher sein kannst, was sie macht, egal wie lange du schon (vermeintlich oder tatsächlich) problemlos damit arbeitest. Vielleicht ist der problematische Code hinter einer if-Abfrage versteckt, die nur an einem Freitag den 13. in einem Schaltjahr bei Vollmond wahr wird.

[thoerb]

Das Problem ist, dass du bei Closed Source nie sicher sein kannst, was sie macht, egal wie lange du schon (vermeintlich oder tatsächlich) problemlos damit arbeitest. Vielleicht ist der problematische Code hinter einer if-Abfrage versteckt, die nur an einem Freitag den 13. in einem Schaltjahr bei Vollmond wahr wird.

Wenn du so misstrauisch bist, dann darfst du dich aber auch in kein neues Auto, Flugzeug etc. mehr setzen.

[hikaru]

Wenn du so misstrauisch bist, dann darfst du dich aber auch in kein neues Auto, Flugzeug etc. mehr setzen.

Auto- und Flugzeughersteller haben für gewöhnlich ein Interesse daran, dass ich heil mein Ziel erreiche. Falls unterwegs mein Leben "abhanden" kommt habe ich nämlich zum letzten mal eines ihrer Produkte benutzt.
Einem Softwarehersteller kann es hingegen egal sein, ob unterwegs meine vertraulichen Daten "abhanden" kommen, denn es liegt in der Natur der Sache der IT, dass diese Daten mir nicht wirklich weggenommen, sondern kopiert werden. Ich merke also im Idealfall gar nichts davon.
Letztendlich ist es eine Spielart von "Gelegenheit macht Diebe" und der einzige Schutz dagegen ist, dem potenziellen Dieb auf die Finger zu schauen - was bei CS prinzipbedingt nur sehr schlecht geht, denn man müsste ihn auf frischer Tat ertappen. Bei FLOSS kann man ihn schon bei der Planung erwischen.

[thoerb]

Auto- und Flugzeughersteller haben für gewöhnlich ein Interesse daran, dass ich heil mein Ziel erreiche.

Das ist schon richtig was du sagst, aber leider ist das primäre Ziel erst mal ein Produkt auf den Markt zu bringen, die hohen Entwicklungskosten wieder rein zu holen und dann anschließend maximalen Gewinn damit zu machen. Bei Boeing ist das ziemlich schief gegangen. Aber das wird jetzt hier ziemlich OT.

[willy4711]

willy4711 hat geschrieben:
Wenn ich die neue Version mit Root-Rechten nach /opt/firefox kopiere, wird FF im Anschluss wahrscheinlich ein neues Profil anlegen wollen

Nein, denn das ist im Homeverzeichnis schon vorhanden.

Das ist mir schon Klar. Aber ich hatte es nun schon ein Paar mal. dass bei einer neuen Version (Kopierverfahren, nicht Update),
FF / Thunderbird sich weigerten, das alte Profil zu benutzen.
Aber nun habe ich "gesündigt". Grund: mir war nicht klar dass das Update von Firefox 79.0b9 (64-Bit) auf Vers. 79.0 (64-Bit) ging.
Hatte so was wie 80 erwartet.
Also habe ich das "Switch-User-Verfahren" zu meiner Schande angewendet.
Die nächsten Updates werden dann mit dem sicheren Kopierverfahren durchgeführt

Firefox statt Chromium.

Gut - mir ist das relativ egal, dachte nur, weil hier im Forum so viele Chromium benutzen, dass das auch was im Bezug
auf die Zugverlässlichkeit zu sagen hätte. Hatte den ja extra dafür installiert.

Nun wird es dann ein Fire-gejailter Tor- Browser.
Das ist wirklich Cool ---> komme noch nicht mal in mein /home ---> ist einfach leer

Das Problem ist, dass du bei Closed Source nie sicher sein kannst, was sie macht, egal wie lange du schon (vermeintlich oder tatsächlich) problemlos damit arbeitest. Vielleicht ist der problematische Code hinter einer if-Abfrage versteckt, die nur an einem Freitag den 13. in einem Schaltjahr bei Vollmond wahr wird.

Ok - werde dann an keinem Freitag, den 13. mehr Bankgeschäfte machen

Aber Spaß beiseite: Ich bin der Meinung, dass Ich Windows soweit wie möglich "kastriert" habe.
Die meisten Windows Programme (adds) sind ebenfalls deinstalliert- ein Konto hab ich da eh nicht.
Insgesamt 5 Programme sind dort installiert - Evince / FF / 7Zip/ Mein Banking sowie mein Steuer Programm.
Klar kann man immer sagen, Closed Source ist Böse - aber ich habe halt keine andere (sicherere / bessere) Lösung.

[uname]

Zurück zur Anfrage:

Verstehe ich nicht.
Ob nun Firefox aus dem /home oder aus /opt mit identischen Rechten gestartet wird ist aus meiner Sicht gehupft wie gesprungen.
Bitte um Aufklärung wo der Sicherheitstechnische Unterschied ist.

Warum steht da /home und /opt?

Oder meinst du die Installationsart vom Firefox?

Paketquelle (dann /usr/bin/firefox): https://packages.debian.org/buster/firefox-esr
Fremdquelle (dann /opt): https://wiki.debian.org/Firefox#From_Mozilla_binaries

Das wäre dann schon ein Unterschied.

[KP97]

... mir war nicht klar dass das Update von Firefox 79.0b9 (64-Bit) auf Vers. 79.0 (64-Bit) ging.
Hatte so was wie 80 erwartet.

Die Versionen mit ...0 b bezeichnen immer die Beta, der Vorläufer für die endgültige Stable, daher bleibt das Profil unangetastet.
Die Abfrage erfolgt u.a. auch wieder in der omni.ja. Wenn dort 79+ steht, wird auch alles, was 79 in der Bezeichnung hat, ohne Nachfrage ausgeführt.
Wenn es dann Vers. 80 wird, paßt die omni.ja nicht mehr und es wird ein neues Profil erstellt, wenn man manuell kopiert.

Wenn ich den Firefox über das Repo beziehe, werden die Programmdateien - wie alles andere auch - nach /usr installiert.
Das "hauseigene" automatische Update von Firefox ist disabled, da die Updates aus dem Repo kommen. Insofern ist alles auf der sicheren Seite.

Wenn ich den Firefox von der Homepage beziehe, und wenn ich nur alleine das System benutze, muß ich nicht nach /opt kopieren.
Dann muß es nicht global sein, ich muß keine Rechte von Systemverzeichnissen ändern und kann aus meinem Home auch Updates anstoßen.
Ich kann ebenso andere Versionen nutzen, indem ich ein weiteres Profil anlege.

So kann man sich aussuchen, was für einen persönlich bequemer bzw. sicher ist.

[OrangeJuice]

Das ist mir schon Klar. Aber ich hatte es nun schon ein Paar mal. dass bei einer neuen Version (Kopierverfahren, nicht Update),
FF / Thunderbird sich weigerten, das alte Profil zu benutzen.

Da hilft doch meistens schon das hier(-P kannst du weglassen, wenn du nur ein Profil hast):

Code: Alles auswählen

firefox -P -allow-downgrade
thunderbird -P -allow-downgrade

Dann ruhig unter about:support noch unter "Chronik- und Lesezeichendatenbank", "Integrität überprüfen".

Ansonsten kannst du dir unter /opt/firefox einen Ordner mit dem Namen "distribution" anlegen, darin eine policies.json(Addon: Enterprise Policy Generator). Damit kann man dem Firefox auch das Updaten verbieten. "about:policies" zeigt dir an ob die Regeln aktiviert sind und wenn irgendwelche Fehler vorliegen und Regeln nicht übernommen werden.

[wanne]

Ich meine, wäre das der Fall, wäre es schon längst bekannt geworden.

So unbekannt ist das jetzt nicht. Ich finde jetzt nicht mehr auf Anhiet die passende Statistik. Der Diebstahl von Zugangsdaten bei Steam im Schnitt etwa so oft wie Fahrräder. Ich nehme an, dass das für Bankdaten ähnlich aussieht.

Ich bin der Meinung, dass dessen Codebasis nicht unabhängig verständlich ist und die Debian-Maintainer des Pakets inkompetent sind.

Ich dresche ja auch gerne auf Chrome ein und freiwillig versteht das wirklich keiner aber Google hat halt tatsächlich den Vorteil, dass sie hohe Bugbounties ausschreiben und auch wirklich auszahlen. In sofern gibt es eine ganze Reihe von Leuten die da jetzt wirklich mehr oder minder professionell den Code nach Bugs durchsuchen. – Und vor allem: Sie machen das unabhängig. Es wird sogar ausdrücklich dazu geraten das öffentlich zu melden und danach bekommt man das Geld. Google hat also keine Möglichkeit auf die Finder Einfluss zu nehmen, weil sie die gar nicht kennen bevor sie das an Mitre melden. Und Mitre veröffentlicht dann instant, dass was gefunden wurde.

[willy4711]

Die Versionen mit ...0 b bezeichnen immer die Beta, der Vorläufer für die endgültige Stable, daher bleibt das Profil unangetastet.
Die Abfrage erfolgt u.a. auch wieder in der omni.ja. Wenn dort 79+ steht, wird auch alles, was 79 in der Bezeichnung hat, ohne Nachfrage ausgeführt.
Wenn es dann Vers. 80 wird, paßt die omni.ja nicht mehr und es wird ein neues Profil erstellt, wenn man manuell kopiert.

Danke für die Erklärung. demnach wäre ja beim nächsten Update erst der Versionssprung fällig
Das nächste Beta- Update wäre dann auf die Version 80.0b1
Du sagst, dass das in der onmi.ja steht. Aber das muss es ja auch im Profilverzeichnis geprüft werden ?
Forschung:
Das wäre (wahrscheinlich) Diese Datei:
~/.mozilla/firefox/nsp5foa6.default-beta/compatibility.ini

Code: Alles auswählen

[Compatibility]
LastVersion=79.0_20200720193547/20200720193547
LastOSABI=Linux_x86_64-gcc3
LastPlatformDir=/opt/firefox_beta
LastAppDir=/opt/firefox_beta/browser

Die Zahlen sind die Buil.ID
Weiter geforscht:

Die Build-ID bekomme ich aus den jeweiligen Verzeichnis der Version. Für meine 79.0 Version wäre das:
https://ftp.mozilla.org/pub/firefox/can ... 4_info.txt

Dann sollte die alles entscheidende Zeile (hoffentlich) in der compatibility.ini so aussehen:

Code: Alles auswählen

LastVersion=80.0b1_xxxxxxxxxxxxxxxxx/x=Wenn Version verhanden

Wäre ja - wenn dem so ist - relativ einfach die eine Zeile umzuschreiben.
Leichter jedenfalls, als das Profilverzeichnis zu kopieren.

Das wäre auch insofern gut, dass ich alle befriedigen könnten, die in mir einen prinzipienlosen Unsicherheits-Junkie
vermuten

Dann wird als Root nach /opt/firefox kopiert,das dann natürlich immer Root gehört.
Keiner braucht mehr Angst haben, dass mein System korrumpiert wird
---Zumindest nicht aus der Ecke -----