Sicherheitsmodell

Setup führt Software aus, die Fremde geschrieben haben. Deshalb behandelt es jedes Repository, jedes Modell, jede Doku-Seite und jedes Rezept als feindlich. Wenn Setup ein Projekt ansieht, führt es nichts davon aus. Startest du eine App, läuft sie in einer Sandbox auf einem Runner, in einem privaten Netz ohne Weg in dein LAN oder auf den Rechner darunter.

Keine Sandbox ist perfekt. Diese Seite beschreibt, was Setup heute tut und was noch nicht gelöst ist, damit du entscheiden kannst, was du wo laufen lässt.

Wo fremder Code läuft

Der Setup-Server klont nie Repositories und startet nie Paketmanager auf analysiertem Code. Er hostet auch keine Sprachmodelle: Ein Rezept mit einem Modell zu entwerfen ist ein optionaler Schritt, der einen externen Anbieter aufruft.

Rezepte können keine gefährlichen Optionen verlangen

Ein Rezept hat für nichts davon ein Feld:

• Host-Pfade und Bind-Mounts
• privilegierten Modus oder zusätzliche Linux-Capabilities
• Geräte, außer einem GPU-Schalter
• das Host-Netz oder die PID- und IPC-Namespaces des Hosts
• Sysctls und Sicherheitsoptionen
• den Docker-Socket

Unbekannte Schlüssel werden entfernt, Pfade auf Traversal geprüft, und Image-Referenzen müssen einer strengen Grammatik entsprechen. Der Runner prüft jedes Rezept noch einmal, bevor er Docker anfasst.

Die Sandbox um jede App

Netz. Jede App bekommt ein eigenes internes Docker-Netz ohne Route ins Internet oder in dein LAN. Die Bridge dieses Netzes hat keine Adresse auf dem Host, deshalb sind auch Dienste auf dem Docker-Host selbst, etwa SSH, nicht erreichbar. Anfragen kommen nur über einen Ingress-Proxy pro App in einem separaten Netz herein, und nur an den HTTP-Port, den das Rezept freigibt.

Ausgehender Verkehr. Nur Dienste, deren Rezept egress: public angibt, erreichen das Internet, und nur über den Egress-Proxy der App. Der Proxy löst jeden Namen selbst auf, lehnt private, Loopback-, CGNAT-, Link-local- (einschließlich der Cloud-Metadatenadresse 169.254.169.254), Multicast- und reservierte Bereiche in IPv4 und IPv6 ab und verbindet sich dann mit genau der geprüften Adresse. DNS-Rebinding hilft also nicht. Er leitet nur HTTP und HTTPS weiter.

Container. Jeder Dienst verliert alle Linux-Capabilities bis auf sechs, die viele Images brauchen, etwa um zu ihrem eigenen Benutzer zu wechseln. Er läuft mit no-new-privileges, Dockers Standardprofilen für seccomp und AppArmor und mit Grenzen für CPU, Speicher, Prozesse und Log-Größe. Wird der Speicher knapp, beendet der Kernel zuerst Prozesse aus der Sandbox. Hat der Host gVisor oder Kata, nutzt der Runner es. Gespeichert wird nur in benannten Volumes, die zur App gehören.

Rohe Ports. TCP- oder UDP-Ports außerhalb von HTTP gibt es nur, wenn der Betreiber des Runners sie erlaubt (--allow-published-ports). Ein Weiterleiter reicht sie durch, der Dienst selbst kommt nie in ein routbares Netz.

Apps in der Testphase entfernen sich selbst, standardmäßig nach 60 Minuten.

Runner. Ein Runner, den du verbindest, führt nur Apps seines eigenen Workspaces aus. Die Runner der Setup Cloud teilen sich mehrere Workspaces. Was du auf dem Host selbst tun kannst, steht unter Runner und selbst hosten.

Secrets

App-Secrets, also Eingaben vom Typ secret, liegen mit AES-256-GCM verschlüsselt in der Datenbank von Setup. Die API gibt sie nie zurück; das Dashboard weiß nur, dass ein Wert gesetzt ist. Setup entschlüsselt sie, wenn ein Runner einen Job abholt, und schickt sie per HTTPS an ihn. Auf dem Runner stehen sie in der Compose-Datei der App im Datenverzeichnis (Dateimodus 0600) und in der Umgebung der Container. Wer auf diesem Host Zugriff auf Docker hat, kann sie also lesen.

Runner-Tokens und API-Schlüssel werden einmal angezeigt und nur als Hash gespeichert. Ein API-Schlüssel lässt sich auf einen Workspace beschränken, hat nie globale Admin-Rechte und kann keine Schlüssel verwalten. Mehr unter MCP und API-Schlüssel.

Verbundene Konten werden genauso verschlüsselt, nie geloggt und nie von der API zurückgegeben. Sie verlassen den Setup-Server nur in einem Job, der bei einem externen Dienst Ressourcen anlegt oder entfernt, als Umgebungsvariablen eines fest gepinnten OpenTofu-Containers. Dieser Container führt keinen analysierten Code aus und erreicht das Internet nur über einen Egress-Proxy. App-Sandboxen bekommen diese Zugangsdaten nie; eine App bekommt nur den Schlüssel oder das Projekt, das Setup für sie angelegt hat. Mehr unter Integrationen.

Der Modellschlüssel des Assistenten wird genauso verschlüsselt, wenn ein Workspace einen eigenen hinterlegt.

Konten und Workspaces

Du meldest dich mit E-Mail und Passwort (die Adresse muss bestätigt sein), einem Anmeldelink, einem Einmalcode per E-Mail oder einem Passkey an und kannst die Zwei-Faktor-Authentifizierung einschalten. Anmelden mit Google, GitHub und Apple erscheint, wenn die Setup-Instanz es eingerichtet hat. Setzt du dein Passwort zurück, werden alle anderen Sitzungen abgemeldet.

Alles gehört zu einem Workspace: deinem persönlichen oder einer Organisation mit Inhabern, Admins und Mitgliedern. Nur Admins fügen Runner hinzu oder ändern sie, verbinden oder trennen Konten und hinterlegen den Schlüssel für den Assistenten. Will ein Agent etwas Destruktives tun, braucht er dafür eine ausdrückliche Bestätigung.

Öffentliche Statusseiten sind standardmäßig aus und existieren nur für behaltene Apps. Sie zeigen den Namen der App, ihren Zustand, die tägliche Verfügbarkeit und wann die letzte Störung begann und endete. Workspace, Runner, Logs und Fehlertexte zeigen sie nie, und die Adresse der App erscheint nur, wenn der Inhaber einen zweiten Schalter umlegt.

Bekannte Lücken

Diese Punkte sind offen. Zu jedem steht, was du heute tun kannst.

• Builds erreichen dein LAN. RUN-Schritte brauchen Internet, um Abhängigkeiten zu installieren, und Build-Container erreichen auch das lokale Netz des Runners. Sperr auf dem Host die privaten Bereiche für Build-Container (Befehle) oder betreib den Runner in einer VM. Builds der Setup Cloud in MicroVMs auszuführen ist geplant, aber nicht gebaut.
• Geteilter Kernel. Unter runc teilen sich Container den Kernel des Hosts. Installier gVisor auf Hosts, die dir wichtig sind; der Runner findet und nutzt es. Jeder Runner zeigt im Dashboard seine Isolation, etwa „Gehärtete Container“ oder „gVisor-Sandbox“.
• Ressourcenerschöpfung. Jeder Container hat Grenzen, aber ein bösartiges Image kann sein ganzes Kontingent ausschöpfen. Den Speicherplatz für Volumes begrenzt der Runner nicht; liegt /var/lib/docker auf einem eigenen Dateisystem, bleibt eine volle Platte vom Rest des Hosts fern.
• Sicherungen bleiben auf dem Runner. Sie sind Archive im Datenverzeichnis des Runners, von Setup nicht verschlüsselt und bisher nirgendwohin kopiert. Leg das Datenverzeichnis auf eine verschlüsselte Platte.
• Die Module für externe Dienste sind jung. Das meiste, was Setup bei anderen Diensten anlegen kann, ist nach der Dokumentation des Anbieters geschrieben und lief noch nie gegen ein echtes Konto. Das Dashboard kennzeichnet jedes davon.

Eine Sicherheitslücke melden

Schreib an security@setup.run, vertraulich und nicht in einem öffentlichen Issue. Schritte zum Nachstellen helfen sehr.