Sicherheit und Datenschutz
Was in AetherOS abgesichert ist, was noch offen ist – und was ehrlich als Simulation gekennzeichnet wird. Die offenen Punkte stehen hier nicht im Kleingedruckten, sondern gleich an zweiter Stelle. Ein Schutz, von dem du nicht weißt, wo er aufhört, ist keiner.
Was abgesichert ist
In der Oberfläche
- Befehle an das System nur von eigenen, lokalen Seiten – mit fester Liste erlaubter Befehle: 23 Anfragen, eine Meldung und zwei Rückmeldungen
- Programme werden ohne Shell gestartet, und Eingaben wie Prozessnummern und Netzadressen werden vorher geprüft – so lässt sich kein zweiter Befehl anhängen
- Zusatzfenster laufen abgeschottet
- Texte werden vor dem Anzeigen entschärft, damit sich kein Code einschleusen lässt – etwa der Suchverlauf oder Netzadressen
Im Linux-Unterbau
- Firewall ab Werk: Eingehendes ist gesperrt, solange nichts erlaubt ist
- Der Administrator-Zugang root ist gesperrt
- Der Installer prüft Laufwerk und Rechnername und nimmt sich danach die Rechte wieder – auf dem installierten System bleibt kein Weg zu erhöhten Rechten über ihn
Apps
- .aero-Apps laufen abgeschottet und bekommen nur Rechte aus einer Liste von sieben
- Der Store-Katalog ist signiert, damit niemand unterwegs eine App in die Liste schmuggeln kann – mehr beim .aero-Format
Im eigenen Kernel
Der Compiler der Sprache .ae baut Schutzgitter in den Maschinencode ein. Sie sitzen im übersetzten Programm selbst, nicht in einer Schicht darüber. Im Real Mode, in dem der Kernel läuft, trennt der Prozessor Kernel und Programme nicht voneinander – umso mehr hängt an diesen Gittern. Mehr dazu bei der Sprache .ae.
Was noch offen ist
- Eine Schutzfunktion des Browser-Kerns (
webSecurity) ist noch abgeschaltet. Sie verhindert sonst, dass eine Seite Inhalte einer anderen Herkunft liest. - Die Oberfläche läuft noch ohne Sandbox. Eine Sandbox würde ihre Seiten zusätzlich vom übrigen System abschirmen, falls doch einmal fremder Code hineingerät.
- Der Bootloader hat noch kein Passwort. Wer am Rechner sitzt, kann also die Startparameter ändern.
- Einige feste Systembefehle laufen noch über eine Shell: Das Prüfwerkzeug des Projekts fand am 27. September 2026 zwölf solche Stellen in zwei Dateien – Herunterfahren, Neustart, Sperren, die Liste der Netzverbindungen, die Angaben zur Hauptplatine und die Laufwerkssuche des Installers. Keiner dieser Befehle enthält eine Eingabe von außen. Die Regel „ohne Shell“ gilt damit bisher für Programmstarts und alles mit Eingaben, nicht für jeden Befehl. Als dreizehnten Fund meldet das Werkzeug den abgeschalteten Schalter
webSecurityaus dem ersten Punkt.
Genau deshalb gehört AetherOS noch auf keinen fremden Rechner. Die drei ersten Punkte führt die Sicherheitsliste des Projekts seit dem 21. Juli 2026 als bewusst offen; der vierte ist beim Nachprüfen für diese Seite aufgefallen. Mehr dazu auf der Seite Sicherheit.
Warum das noch offen ist
Die Schutzfunktion
Der eingebaute Browser lädt fremde Seiten in Rahmen und braucht dafür die Lockerung. Aus demselben Grund entfernt das Hauptfenster bei jeder Antwort zwei Kopfzeilen, mit denen sich Seiten sonst gegen das Einbetten wehren. Die Brücke zum System gibt es nur für eigene Seiten, die von der Festplatte kommen – fremde Seiten kommen so nicht an Systembefehle, Zwischenablage oder Dateien. Geplant ist, fremde Inhalte in ein eigenes Fenster ohne Systemzugang auszulagern. Erst dann lässt sich die Schutzfunktion für die ganze Oberfläche wieder einschalten, zusammen mit eigenen Regeln dafür, welche Inhalte eine Seite laden darf.
Die Sandbox
Der Helfer für die Sandbox ist im Abbild schon vorbereitet. Die Ausnahme fällt erst nach einem Test auf echter Hardware weg – falsch eingestellt, startet die Oberfläche nicht. Eine Oberfläche, die gar nicht mehr startet, hilft niemandem – deshalb erst der Test, dann der Schalter.
Das Bootloader-Passwort
Es schützt davor, dass jemand am Rechner die Startparameter ändert. Empfohlen ist ein eigenes Passwort je Auslieferung. Im öffentlichen Quellcode steht es nicht. Ein Passwort, das im Quellcode stünde, wäre für jeden lesbar und damit keines; darum kommt es erst mit der Auslieferung.
Die Sicherheitsliste des Projekts trägt den Stand vom 21. Juli 2026. Zur Sandbox widersprechen sich zwei Stellen: Ein Kommentar in der Sitzung sagt, dem Helfer fehlten im Abbild die nötigen Sonderrechte; das Einrichtungsskript setzt sie aber. Welche Stelle für das Abbild vom Juli gilt, ist noch nicht nachgeprüft. Beide stehen am 27. September 2026 unverändert im Linux-Unterbau: der Kommentar in xinitrc, das Setzen der Rechte in aether-chroot-setup.sh. Klären lässt sich das erst an einem gestarteten Abbild.
Hauptfenster und Zusatzfenster im Vergleich
Die Oberfläche selbst braucht Lockerungen. Alles, was sie an Fenstern nach außen öffnet, bekommt sie ausdrücklich nicht mit. Der Grund: Die Seiten des Hauptfensters kommen von der Festplatte, fremde Seiten stehen dort nur in Rahmen ohne Brücke. In einem Zusatzfenster dagegen kann jede beliebige Webseite stehen. Die Schalter sind Einstellungen von Electron, dem Rahmen, auf dem die Oberfläche gebaut ist:
| Schalter | Hauptfenster | Zusatzfenster |
|---|---|---|
Seiten voneinander getrennt (contextIsolation) | an | an |
Node.js in der Seite (nodeIntegration) | aus | aus |
| Node.js in eingebetteten Rahmen | an | aus |
Schutzfunktion webSecurity | aus | an |
| Sandbox | – | an |
| Brücke zum System | ja, nur für eigene Seiten | keine |
Nur Webadressen
Ein Zusatzfenster geht nur für Adressen mit http oder https auf. Und das Hauptfenster bleibt bei seinen eigenen Seiten: Will es woandershin, wird das angehalten. So kann auch ein Link in einer fremden Seite das Hauptfenster mit seiner Brücke zum System nicht übernehmen.
Entwicklerwerkzeuge
Die gibt es nur im Entwicklermodus. Im Live-System und im Kiosk-Betrieb fehlen sie ganz. Wer sie öffnen kann, kann in der laufenden Oberfläche beliebigen Code ausführen – auf einem fremden Rechner soll das niemand können.
Wer was darf
Ohne Administratorrechte
Die Oberfläche läuft als Benutzer „aether“. Er ist Mitglied der Gruppen für Ton, Bild, Eingabegeräte, Netzwerk und Wechseldatenträger. Er darf also, was man am Rechner zum Arbeiten braucht; am System selbst ändern darf er nur, was die vier Ausnahmen daneben erlauben.
Vier Ausnahmen
Ohne Passwort darf er im Live-System genau vier Dinge mit erhöhten Rechten: den Installer starten, herunterfahren, neu starten und die Firewall-Regeln bedienen. Auf dem installierten System sind es drei – die Installationsskripte löscht der Installer am Ende. Die Liste dieser Ausnahmen wird beim Bau mit einem eigenen Prüfbefehl auf Fehler kontrolliert, bevor sie gilt.
Grafik nur am Gerät
Den Grafik-Server darf nur starten, wer direkt am Rechner angemeldet ist. Aus der Ferne lässt sich darüber also keine eigene Bildschirmsitzung aufmachen.
Eigenes Passwort
Beim Installieren lässt sich ein Passwort setzen. Es gilt dann für root und für den Benutzer „aether“. Die Oberfläche reicht es dem Installationsskript als Aufrufwert weiter. Im Live-System hat „aether“ dagegen gar kein Passwort. Dort ist root gesperrt, und erhöhte Rechte gibt es nur für die vier Ausnahmen.
Das Start-Kennwort
Der Aether Defender kann beim Hochfahren nach einem Kennwort fragen. Seit dem 10. September 2026 speichert er davon nur einen SHA-256-Abdruck; alte Einträge nimmt er noch an und ersetzt sie still. Ein Abdruck lässt sich prüfen, aber nicht zurück in das Kennwort verwandeln. Wer die gespeicherten Daten liest, kennt das Kennwort damit nicht unmittelbar – ein kurzes ließe sich aber durch Ausprobieren finden.
Die Firewall im Detail
- Eingehend: gesperrt. Durch kommen nur Antworten auf eigene Verbindungen, Verkehr innerhalb des Rechners und ICMP-Pakete wie Ping.
- Weiterleiten: gesperrt. AetherOS ist kein Router und reicht keine Pakete zwischen Netzen durch.
- Ausgehend: erlaubt. Sonst käme auch der eingebaute Browser nicht ins Netz.
Einen offenen Port gibt es damit nicht. Die Regeln stehen im Linux-Unterbau und werden beim Systemstart geladen. Die Regeln zu bedienen, gehört zu den Ausnahmen, die der Benutzer „aether“ ohne Passwort darf – im Live-System wie im installierten System, siehe „Wer was darf“.
Schutz beim Installieren
Der Installer löscht die gewählte Festplatte. Damit es die richtige ist und sich nichts einschleusen lässt, prüft er in mehreren Schritten. Ein Fehler an dieser Stelle lässt sich nicht rückgängig machen – deshalb kommen diese fünf Schritte, bevor er das erste Byte schreibt:
- Laufwerke kennzeichnen. In der Auswahl steht beim eigenen USB-Stick „NICHT WÄHLEN!“, bei Platten mit NTFS „WINDOWS-PLATTE!“. Modellnamen werden dabei auf harmlose Zeichen gekürzt. Ein Gerät kann sich also nicht mit einem präparierten Namen in die Befehle des Installers schreiben.
- Ziel prüfen. Es zählen nur übliche Laufwerksnamen und echte Laufwerke. Der Stick, von dem gestartet wurde, wird nie überschrieben – auch nicht im Automatikbetrieb.
- Nachfragen. Im geführten Ablauf fragt der Installer vor dem Löschen noch einmal ausdrücklich nach.
- Rechnername prüfen. Er darf nur Buchstaben, Ziffern und Bindestriche enthalten. Einen ungültigen Namen überspringt der Installer. Der Name landet später in Systemdateien; mit dieser Prüfung kann er dort nichts anderes auslösen.
- Laufwerk entriegeln. Vor dem Aufteilen schaltet er Auslagerungsspeicher ab, deaktiviert Linux-Datenträgergruppen, schließt verschlüsselte Bereiche und stoppt Verbünde mehrerer Platten – damit nichts das Laufwerk festhält.
Der Haken „Sichere Laufwerksbereinigung durchführen“ überschreibt nur die ersten 10 MiB der Platte – genug, damit die alte Aufteilung verschwindet, aber kein Löschen der ganzen Platte. Wer alte Daten wirklich unlesbar machen will, braucht dafür noch ein anderes Werkzeug. Der Name des Hakens verspricht mehr, als er hält; das steht hier, damit sich niemand darauf verlässt.
Ehrlich simuliert
Aether Defender
Eine große Oberfläche für Echtzeitschutz, USB-Wache und Berichte – aber er prüft den Rechner nicht wirklich. Die Einstellungen beantworten die Frage „Prüft er diesen Rechner?“ selbst mit „nein“. Mit rund 49.000 Zeilen macht er trotzdem fast ein Drittel der Skripte der Oberfläche aus – gebaut ist die Bedienung, nicht die Prüfung. Mehr beim Stand.
Firewall, VPN, Hotspot
Die Seiten dazu sagen jeweils, was sie sind und was nicht. Die Grundregeln der echten Firewall stecken im Linux-Unterbau, wie oben beschrieben. Ein Schalter, der Schutz vorspielt, wäre schlimmer als einer, der ehrlich fehlt.
Berechtigungen
Die Datenschutz-Seite fragt zehn Browser-Berechtigungen ab, ohne selbst eine Erlaubnis anzufordern. Sie zeigt also nur den Stand an. Erteilt oder entzogen wird dort nichts.
Updates und Sprache
Noch keine Update-Quelle
Eine Quelle für Updates soll kommen – heute gibt es keine. Deshalb gibt es auch keinen Knopf „Nach Updates suchen“, der nur so tun würde. AetherOS zeigt stattdessen seinen Baustand. Für die Sicherheit heißt das auch: Lücken, die später gefunden werden, lassen sich noch nicht über das Netz schließen – ein Grund mehr, warum AetherOS heute auf keinen fremden Rechner gehört.
Vorerst nur Deutsch
Die Oberfläche von AetherOS ist vorerst nur deutsch, ohne Sprachauswahl. Auch die Warnungen und Hinweise zur Sicherheit stehen deshalb nur auf Deutsch. Diese Webseite dagegen gibt es in 85 Sprachen.
Weiter
Das .aero-Format
Wie installierte Apps geprüft, signiert und abgeschottet werden. Mit der Liste der sieben Rechte, die eine App bekommen kann.
Was der Installer tut
Aufteilung der Platte, Startlader und die Schritte des Bauskripts. Dort steht auch, dass der Installer ein vorhandenes Windows ersetzt.
Sicherheit bei Aerona
Die Grundsätze für alle Teile – nicht nur für AetherOS. Mit dem, was im ganzen Ökosystem noch offen ist.
