Audit ergab: der Dienst laeuft korrekt als unprivilegierter User (nicht
root, kein sudo, nologin-Shell, bestaetigt per ps/id auf anode), aber
systemd-analyze security kam trotz der vier bestehenden Basis-Direktiven
(NoNewPrivileges/PrivateTmp/ProtectSystem=strict/ProtectHome) nur auf
8.3/10 "EXPOSED" - der volle Capability-Bounding-Set, kein
Syscall-Filter, keine Namespace-/Kernel-/Proc-Beschraenkungen.
Ergaenzt: CapabilityBoundingSet= (leer - der Dienst braucht keine
einzige Linux-Capability), SystemCallFilter=@system-service,
RestrictAddressFamilies (nur INET/INET6/UNIX), RestrictNamespaces,
RestrictSUIDSGID, LockPersonality, MemoryDenyWriteExecute,
ProtectKernel{Modules,Tunables,Logs}, ProtectControlGroups,
ProtectClock, ProtectHostname, ProtectProc=invisible, ProcSubset=pid,
PrivateDevices, RemoveIPC, RestrictRealtime, UMask=0077.
Vor dem Scharfschalten per systemd-run mit exakt dieser
Direktivenkombination gegen den echten Code getestet (nicht nur gegen
eine leere Testanwendung): Login/JWT-Signierung, Postgres-Lese-/
Schreibzugriff via psycopg, ausgehender HTTP-Aufruf via httpx an
provisioning-server, Fernet-Verschluesselung des WLAN-PSK - alles ohne
Fehler unter der vollen Sandbox.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Neuer, von provisioning-server (anode) getrennter Dienst, siehe ADR-0011:
FastAPI + Jinja2, eigene Postgres-DB (benutzer-Tabelle), eigenes
Service-Token (TUXFLOTTE_KUNDENPLATTFORM_TOKEN) für die Kommunikation mit
anode. Org-Zugehörigkeits-Prüfung passiert hier in der Anwendung vor jedem
Aufruf gegen anode.
Umfang v1: Login, Geräteliste, Auftragskatalog geräteweise aus-/abwählen
(inkl. der standardbrowser-Option für Brave). systemd-Unit läuft unter
eigenem unprivilegiertem System-User statt root.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
