Eingezäunt vom
Betriebssystem.
Ein Browser führt unvertrauenswürdigen Code aus dem gesamten Web aus. Also nimmt Searxly das Schlimmste an: die App ist von macOS sandboxed, gegen Code-Injection gehärtet, und die wenigen privilegierten Jobs, die sie braucht, werden in einen separaten Helper ausgelagert. Selbst wenn eine Seite durchrutschte, bleibt sie eingesperrt.
Die riskante Arbeit lebt nicht im Browser.
Die lokale Suchmaschine zu betreiben heißt, einen Prozess zu starten und ein paar Konfigurationsdateien zu schreiben — genau die Rechte, die ein sandboxed Browser nicht haben soll. Also sind diese Jobs in einen kleinen, isolierten XPC-Helper ausgelagert. Die Haupt-App fragt; der Helper erledigt die Arbeit über einen engen, typisierten Kanal.
typisiert · eng
~/searxng-localDer Helper exponiert eine feste Menge an Methoden — die lokale Engine starten/stoppen, prüfen, ob sie läuft, eine Datei unter einem Ordner lesen/schreiben/löschen. Es gibt keine allgemeine „irgendwas ausführen“-Tür.
Von jeder Seite gehärtet.
App Sandbox
Das Haupt-Target läuft im macOS App Sandbox — derselben Isolation, die der Mac App Store verlangt. Der Browser kann weder Ihren Home-Ordner lesen noch mit beliebigen Prozessen sprechen; er bekommt nur die Capabilities, die er deklariert.
Hardened Runtime
Schutz gegen Code-Injection, unsignierten Speicher und Library-Validierung ist an, damit ein anderer Prozess keinen Code in Searxly injizieren kann. Die verbleibenden Ausnahmen existieren nur, weil WebKits JavaScript-Engine sie wirklich braucht.
XPC-Privilege-Split
Das Starten der lokalen Engine und Konfigurationsschreibungen laufen über einen eigenen XPC-Service, nicht über den Browser. Die Haupt-App hält keine direkten Process()- oder Dateisystem-Rechte — eine harte Regel, keine Konvention.
Eingeschränkter Dateizugriff
Die Dateimethoden des Helpers sind auf den Local-Search-Projektordner beschränkt. Er legt die Verzeichnisse, die er besitzt, selbst an und rührt sonst nichts auf der Platte an.
Least-Privilege-Entitlements
Entitlements sind auf das beschränkt, was jede Capability braucht — Loopback, um die lokale Engine zu erreichen, und den Keychain-Scope, den die Wallet braucht — und werden bei jeder Ergänzung geprüft.
Signiert & prüfbar
Builds sind code-signiert und der Quellcode ist veröffentlicht, sodass das Laufende gegen das Geschriebene geprüft werden kann. Vertrauen hängt an Signaturen, nicht an unserem Wort.
Wenn eine Seite feindlich wird.
Ein WebKit-Exploit versucht, Ihre Dateien zu lesen oder Befehle auszuführen.
Der Prozess hat keine Datei- oder Prozessrechte zum Missbrauchen — das OS verweigert sie, egal was die Seite tut.
Malware auf dem Mac versucht, eine dylib in den Browser zu laden.
Library-Validierung und Code-Injection-Schutz blockieren das Laden unsignierten Codes in den Prozess.
Kompromittierter Code versucht, den Helper zu zwingen, beliebige Befehle auszuführen.
Der Helper exponiert nur eine Handvoll spezifischer Methoden, mit Datei-Ops auf einen Ordner beschränkt — es gibt keinen „irgendwas ausführen“-Einstieg.
Kompromittierung annehmen, Wirkungsradius begrenzen.
Der Browser wird als der gefährlichste Code auf Ihrem Mac behandelt — und entsprechend eingesperrt.