Sicherheit

Max' Vorgabe: nullos soll von Grund auf sicherer werden als Linux, macOS, Windows, Android und iOS. Und dabei kinderleicht bleiben.

Die Idee: Jedes Programm hat einen Ausweis

Neben spec liegt eine kleine Datei ausweis. Da steht drin, was das Programm darf – auf Deutsch, eine Zeile pro Recht. Zum Beispiel dl (Herunterladen):

datei lesen      argumente
datei schreiben  argumente
geräte           zufall
netz verbinden   alles
netz lauschen    nein
prozesse         nein

Der Kernel soll das beim Start erzwingen. Fehlt der Ausweis, darf ein Programm nur Ein- und Ausgabe – sicher ab Werk. Das ist wie pledge/unveil bei OpenBSD, nur Pflicht statt freiwillig. Die ersten Ausweise gibt es schon (in den Karten unter „mehr“). Erzwingen tut der Kernel sie noch nicht. kommt noch

Was dazukommt

• Kein allmächtiger root. Systemordner und Startdateien sind auch für den Admin schreibgeschützt; Änderungen nur über signierte Updates.
• Selbst einschränken: Ein Programm kann sich jederzeit weniger Rechte geben, nie mehr – erst Datei öffnen, dann „kein Netz mehr“, dann fremde Daten lesen.
• Jede Sperre erklärt sich – statt „Permission denied“ ein Satz, was fehlt, und wie man's erlaubt.

Alles kommt noch – der Plan hat 40 nummerierte Maßnahmen (S1–S40) in docs/sicherheit-architektur.md.

Was es schon gibt

• Eigenes TLS 1.3 (lib/tls): X25519, AES-GCM, ChaCha20-Poly1305, Zertifikatsketten mit RSA, ECDSA und Ed25519, auch für IPv6-Adressen. dl holt damit HTTPS – auch auf nullos selbst.
• Eigenes SSH, Client und Server.
• Firewall ab Werk an: eingehend alles zu, ausgehend und Antworten erlaubt, IPv4 und IPv6 gleich. Regeln als kurze Sätze, fw warum erklärt jede Entscheidung, Profile zuhause/unterwegs/server. Gefuzzt mit 2 Millionen Läufen ohne Fund.
• Fuzz-Tests für TLS, SSH, PPP und den Compiler: Zufallsdaten und Fälschungen gegen die Zerleger, mit libFuzzer, AFL++ und Speicherprüfern (tools/fuzz.sh).
• Krypto nur nach Norm, geprüft gegen die offiziellen Testvektoren.
• Sicherer Zufall im Kernel: ChaCha20 mit BLAKE2s-Becken, beim Start gegen die RFC-Testvektoren geprüft.
• SMEP/SMAP: Der Kernel kann Programmspeicher weder ausführen noch versehentlich lesen (wenn die CPU es kann).
• Programmspeicher fasst der Kernel nur an einer Prüfstelle an – geprüft mit kaputten Zeigern und Längen für rund 40 Aufrufe.
• W^X: Nichts ist zugleich beschreibbar und ausführbar. Stapelschutz im Kernel mit Wachseite – und in den Programmen: Der Kernel gibt jedem Programmstart 16 Byte frischen Zufall mit, daraus macht die libc den „Kanarienvogel“.
• Der Compiler härtet selbst: cc kennt die Schalter aus dem OpenSSF-Leitfaden – Stapelschutz, Nullen von Variablen und Registern, endbr64, Format-Prüfung, -pie.
• Speicherprüfer über alles: tools/check-asan.sh lässt alle Werkzeug-Tests mit ASan/UBSan laufen.
• Der Abgleich sucht in allem Code nach strcpy, sprintf, gets & Co.

Ehrlich: was noch fehlt

Laut docs/sicherheit-stand.md: Es gibt noch keine Benutzer (alles läuft als Benutzer 0), und der Ausweis wird noch nicht erzwungen. Und weil es keine Rechte gibt, kann noch jedes Programm die Firewall ausschalten (Fund F20). Deshalb gilt: nullos noch nicht ungeschützt ins Netz hängen.

Regeln für jeden Code

• Jede Eingabe von außen ist verdächtig – Länge, Bereich, Format prüfen, bevor man sie benutzt.
• Kein strcpy/sprintf/gets; Überlauf vor dem Rechnen prüfen; jeder malloc wird geprüft.
• Nie fremde Daten als Format-String; keine Shell-Befehle aus Textbausteinen.
• Geheimnisse nach Gebrauch löschen, Vergleiche in konstanter Zeit, nie Schlüssel im Repo.
• Wer Netzdaten zerlegt, hat wenig Rechte. Parser bekommen Fuzz-Tests.

Ganz: docs/sicherheit.md, docs/sicherheit-architektur.md, docs/kernel-prinzipien.md.