Was abgesichert ist – und was nicht
Ein eigenes Betriebssystem zu bauen heißt auch, für seine Sicherheit geradezustehen. Auf dieser Seite steht beides: die zehn Punkte, die wir abgestellt haben, und die drei, die noch offen sind – dazu ein vierter, der beim Nachprüfen für die Seite „AetherOS-Sicherheit“ aufgefallen ist. Die meisten Anbieter zeigen nur die erste Hälfte. Alles hier stammt aus der Sicherheitsliste des Projekts vom 21.07.2026, und unter jedem Punkt steht klein, in welcher Datei der Schutz sitzt – damit man ihn nachprüfen kann.
Was wir abgestellt haben
Die Kette, um die es ging: Eine fremde Webseite im eingebauten Browser hätte über die Programm-Brücke Systembefehle auslösen können. Eine solche Kette ist gefährlicher als jeder einzelne Fehler darin, weil sie aus einer harmlosen Webseite einen Zugriff auf den ganzen Rechner macht. Diese Kette ist an jedem Glied unterbrochen. Darunter folgen alle zehn Punkte einzeln – fünf in der Oberfläche, fünf im Linux-Unterbau.
Eine fremde Webseite lädt im eingebauten Browser. Die Brücke zum System dürfen jetzt nur noch die eigenen Aerona-Seiten benutzen, die von der Festplatte kommen – die fremde erreicht sie gar nicht erst. Und selbst die eigenen Seiten sprechen nur über eine feste Liste von Kanälen mit dem System.
Selbst wenn eine Eingabe durchkäme: Sie geht nicht mehr an eine Kommandozeile. Programme werden direkt gestartet, und jede Eingabe wird vorher geprüft. Eine Prozessnummer darf nur aus Ziffern bestehen, eine IP-Adresse muss wie eine aussehen – alles andere wird abgewiesen.
Öffnet eine Seite ein weiteres Fenster, bekommt es keine erweiterten Rechte: keine Brücke zum System, dafür eine eigene Sandbox. Und das Hauptfenster kann nicht mehr zu einer fremden Adresse wechseln – will es woandershin, wird das angehalten.
Jedes Glied allein reicht, um die Kette zu brechen. Dass alle drei zu sind, ist Absicht: Fällt eines Tages eines davon, halten noch zwei.
In der Oberfläche
Der eingebaute Browser kann fremde Seiten anzeigen. Die haben jetzt keinerlei Zugriff mehr auf Dateien, Zwischenablage oder Systembefehle – nur noch die eigenen Aerona-Seiten dürfen das. Zusätzlich gibt es eine feste Liste der Kanäle, über die selbst die eigenen Seiten mit dem System sprechen dürfen. An diesem Punkt hängt die ganze Kette oben, deshalb steht er zuerst.
IPC-Zero-Trust in preload.js
Beim Beenden von Programmen oder Sperren von Adressen wird nichts mehr an eine Kommandozeile weitergereicht. Betroffen waren drei Befehle: Programm beenden, Adresse sperren, Adresse wieder freigeben. Sie starten ihr Programm jetzt direkt und bekommen ihre Angaben als einzelne Teile statt als Befehlszeile. Jede Eingabe wird vorher geprüft – eine Prozessnummer etwa darf nur aus Ziffern bestehen.
execFile statt Shell in main-ipc-network.js
Öffnet eine Seite ein Zusatzfenster, bekommt dieses Fenster keine erweiterten Rechte mehr: keine Brücke zum System, dafür eine eigene Sandbox. Und das Hauptfenster kann nicht mehr von der eigenen App weg navigieren. Wie sich Hauptfenster und Zusatzfenster Schalter für Schalter unterscheiden, zeigt eine Tabelle auf der Seite „Sicherheit in AetherOS“.
setWindowOpenHandler und will-navigate in main.js
Vorher konnte man theoretisch Code statt einer Rechnung eingeben, weil die Rechnung mit eval ausgewertet wurde – einem Befehl, der jeden Code ausführt, den man ihm gibt. Jetzt wird jede Eingabe gegen eine feste Liste erlaubter Zeichen geprüft, bevor gerechnet wird. Betroffen waren zwei Stellen in den Desktop-Erweiterungen, eine davon in der Suche.
eval abgesichert in den Desktop-Erweiterungen
Suchverlauf, Adressen aus dem Netz und Suchanfragen werden entschärft, bevor sie angezeigt werden. Ohne das könnte ein gespeicherter Suchbegriff beim nächsten Öffnen wie ein Stück Seite behandelt werden und Code ausführen. Das übernimmt eine gemeinsame Funktion, die an allen Fundstellen benutzt wird.
aetherEscapeHtml in security-escape.js
Im Linux-Unterbau
Kein anderer Benutzer auf dem Rechner kann den X-Server mitbenutzen. Der X-Server zeichnet alles, was auf dem Bildschirm erscheint, und nimmt Tastatur und Maus entgegen. Starten darf ihn nur, wer direkt am Rechner angemeldet ist.
allowed_users=console
Die Firewall lehnt eingehende Verbindungen grundsätzlich ab, statt sie grundsätzlich zu erlauben. Was nicht ausdrücklich erlaubt ist, kommt nicht durch – so muss niemand eine Liste aller gefährlichen Verbindungen pflegen, die nie vollständig wäre. Sie ist im Unterbau eingeschaltet, nicht nur vorbereitet.
nftables mit Default-Deny
Im Live-System ist root gesperrt. Wer AetherOS installiert, vergibt ein echtes Passwort. Ein Konto mit allen Rechten und ohne Passwort wäre sonst der kürzeste Weg, einen Rechner ganz zu übernehmen.
passwd -l
Nach der Installation werden die Installer-Skripte und ihre Sonderrechte gelöscht. Auf einem Firmen-PC gibt es damit keinen Weg, über den Installer an Administratorrechte zu kommen. Ob die Rechte-Datei danach noch fehlerfrei ist, prüft das System mit visudo -c – eine kaputte Datei könnte sonst die Verwaltung des Rechners lahmlegen.
NOPASSWD-Eintrag entfernt, mit visudo -c geprüft
Das Ziel-Laufwerk wird streng geprüft: Es muss dem Muster eines Laufwerks folgen und wirklich ein Laufwerk sein. Das Boot- oder USB-Medium wird auch im automatischen Modus niemals überschrieben. Auch der Rechnername wird nach der Norm geprüft, damit sich darüber keine Befehle ins Einrichtungsskript schmuggeln lassen.
Regex- und Blockgerät-Prüfung, Hostname RFC-validiert
Was noch offen ist
Diese drei Punkte sind bekannt und nicht behoben. Wir schreiben sie hin, weil eine Sicherheitsseite ohne die offenen Punkte nichts wert ist. Offen sind sie aus drei verschiedenen Gründen: Einer braucht einen Umbau, einer einen Test auf echter Hardware, und der dritte lässt sich erst bei einer Auslieferung schließen.
Damit der eingebaute Browser Suchmaschinen oder Wikipedia in einem Rahmen anzeigen kann, ist eine Schutzregel des Browsers abgeschaltet. Aus demselben Grund entfernt das Hauptfenster bei jeder Antwort zwei Kopfzeilen, mit denen sich Seiten sonst gegen das Einbetten wehren. Seit fremde Seiten keinerlei Systemzugriff mehr haben, ist das kein Weg mehr zu höheren Rechten – aber sauber ist es nicht.
webSecurity: false in main.js
Die zusätzliche Abschottung des Browsers ist im Startskript deaktiviert. Die nötige Berechtigung wird beim Bauen bereits gesetzt – das Einschalten muss aber einmal auf echter Hardware getestet werden, sonst startet das System im Zweifel gar nicht. Ehrlich dazu: Zwei Stellen im Projekt widersprechen sich, ob die Berechtigung im Abbild vom Juli wirklich gesetzt ist; nachgeprüft ist das noch nicht (siehe „Sicherheit in AetherOS“).
--no-sandbox in xinitrc
Wer physisch am Rechner sitzt, kann beim Start die Boot-Einstellungen ändern. Ein Passwort dafür gehört pro Auslieferung vergeben und nicht in den Quellcode. Ein Passwort, das öffentlich im Code steht, schützt niemanden – deshalb gibt es heute bewusst keines.
GRUB-Superuser-Passwort
Und die Werkzeuge daneben?
Alles oben betrifft AetherOS. Für den übrigen Quellcode gibt es eine eigene Prüfung,
.claude/werkzeuge/sicherheit.js. Sie sucht nach acht Mustern: fünf
gefährlichen Electron-Schaltern, zwei Arten von Shell-Aufrufen und Zugangsdaten im
Klartext. Beim Lauf am 16.09.2026 hat sie 10.322 Quelldateien gelesen und 186 Stellen
der höchsten Stufe gemeldet.
Ihr erster Anlauf meldete 791 schwere Befunde, fast alle falsch: Suchmuster, die wie Shell-Aufrufe aussahen, und Übersetzungstexte, die von Electron erzählen. Eine Prüfung, die so lärmt, wird irgendwann abgeschaltet. Deshalb hat sie einen Selbsttest: Jede der acht Regeln muss an einer eigens gebauten Datei anschlagen, und die zwei bekannten Fehlalarme müssen stumm bleiben.
node .claude/werkzeuge/sicherheit.js probe
Die Werkzeuge, mit denen die Webseite gebaut wird, nutzen die klassische unsichere Bauart von Electron: Die Oberfläche hat direkten Zugriff auf das System. Jede der sieben Oberflächen braucht diesen Zugriff heute. Es sind Werkzeuge auf dem eigenen Rechner, die nichts aus dem Netz laden. Blind umgebaut wären es sieben kaputte Werkzeuge statt sieben sicherer.
contextBridge, danach jedes von Hand nachprüfen.nodeIntegration: true, contextIsolation: false
Der Übersetzer Lumina 2.0 läuft genauso. Anders als die Werkzeuge holt Lumina aber Seiten aus dem Netz: Die Suche läuft im Fenster selbst, und die Antworten werden dort als HTML eingesetzt. Ob fremder Inhalt auf diesem Weg etwas ausrichten kann, ist nicht untersucht. Deshalb steht es hier.
10_Aerona_Sprache/lumina/main.js
Auf die App Engine und ihre Apps fallen 123 der 186 Meldungen, darunter dieselben Electron-Schalter. Erschienen ist davon noch nichts, auf fremden Rechnern läuft also keine dieser Stellen. Die Zahl sagt nur, was die Prüfung meldet – welche Meldungen echte Lücken sind, ist damit noch nicht durchgesehen.
07_Aerona_App_Engine
Weiterlesen
Was im System abgesichert ist, was offen ist und was nur simuliert wird. Dort steht auch die Tabelle, welche Schalter im Hauptfenster und welche im Zusatzfenster gelten.
Firewall, Sandbox, Administratorrechte – die Begriffe dieser Seite, einfach erklärt. Dazu Passwörter und Phishing, also das, was man selbst in der Hand hat.
Die Werkzeuge hinter der Prüfung oben – und was sie gelehrt haben. Auch die Geschichte der 791 Fehlalarme steht dort.
