Lokale Sicherheit

10.1 Grundlage

Das ausschließliche Lauschen auf localhost ist keine absolute Sicherheit: Eine bösartige Webseite kann trotzdem versuchen, lokale Ports zu erreichen. LMSP kombiniert deshalb mehrere Maßnahmen.

• Ein Dienst MUSS sich standardmäßig an die Loopback-Adressen binden. Er DARF NICHT auf 0.0.0.0 oder einer anderen Nicht-Loopback-Adresse lauschen, solange der LAN-Modus nicht aktiviert ist (Abschnitt 10.5).
• Beim ersten Start SOLLTE ein Dienst ein zufälliges Dienstgeheimnis mit hoher Entropie erzeugen und damit, statt mit einem eingebauten Standardwert, Tokens ausstellen und prüfen.
• Jede Anfrage an die Kernschnittstelle MUSS ein gültiges Bearer-Token tragen, außer bei den in Abschnitt 4.2 aufgeführten Bootstrap-Endpunkten. Von Loopback zu kommen genügt allein nie.

10.2 Kopplung und Tokens

Ein Client erhält sein eigenes Bearer-Token mit einem lokalen Kopplungscode. Der Nutzer lässt sich vom Dienst auf dessen Weise einen Kopplungscode anzeigen, und der Client reicht ihn ein:

POST /lmsp/v1/pair
Content-Type: application/json

{
  "client_name": "example-client",
  "pairing_code": "K7QD-4M2X",
  "scopes": ["inference"]
}

Der Dienst antwortet mit einem Token. Der token_type ist immer Bearer:

{
  "client_id": "cli_01J8MAT3W6X9B2D5F8H1K4N7QZ",
  "access_token": "lmsp_example_3f9a1c52e7d84b60",
  "token_type": "Bearer",
  "scopes": ["inference"]
}

Danach sendet der Client mit jeder Anfrage Authorization: Bearer <token>.

• Ein Kopplungscode MUSS nur einmal verwendbar sein und SOLLTE innerhalb von 5 Minuten ablaufen. Er SOLLTE mindestens 40 Bit Entropie enthalten. Ein Dienst MUSS fehlgeschlagene Versuche begrenzen. Ein falscher oder abgelaufener Code wird mit 401 und unauthorized beantwortet.
• Tokens sind pro Client unabhängig, sodass der Nutzer einen Client widerrufen kann, ohne die anderen zu beeinträchtigen. Ein Dienst SOLLTE dem Nutzer erlauben, gekoppelte Clients aufzulisten und zu widerrufen.
• Ein Client SOLLTE sein Token im Schlüsselbund oder in der Anmeldeinformationsverwaltung des Betriebssystems aufbewahren. Ein Dienst SOLLTE nur einen Hash jedes Tokens speichern.
• Ein fehlendes, ungültiges oder widerrufenes Token wird mit 401, unauthorized und einem WWW-Authenticate: Bearer-Header beantwortet. Ein gültiges Token, dem der von einem Endpunkt benötigte Scope fehlt, wird mit 403 und forbidden beantwortet.

10.3 Scopes

Berechtigungen sind in getrennte Scopes aufgeteilt. Modelle herunterzuladen, Modelle zu löschen und Tools auszuführen läuft nie über den Inferenz-Scope mit.

Aufgaben und gespeicherte Antworten gehören dem Client, der sie erstellt hat. Ein Dienst SOLLTE auf die Anfrage eines anderen Clients antworten, als gäbe es sie nicht (task_not_found oder response_not_found).

10.4 Schutz von Browser und Netzwerk

• Ein Dienst MUSS Cross-Origin-Browseranfragen standardmäßig ablehnen und nur ausdrücklich konfigurierte Origin-Werte zulassen. Eine Anfrage mit einer anderen Origin wird mit 403 und forbidden beantwortet.
• Ist ein Origin erlaubt, beantwortet der Dienst dessen CORS-Preflight-Anfragen und sendet Access-Control-Allow-Origin mit genau diesem Origin, nie mit *.
• Ein Dienst MUSS den Host-Header validieren, um DNS-Rebinding zu verhindern. Er akzeptiert nur Hostnamen, die er bedient: die Loopback-Namen und -Adressen sowie alle für den LAN-Modus konfigurierten Namen. Jeder andere Wert wird mit 403 und forbidden beantwortet.

10.5 LAN-Modus

LAN-Modus bedeutet, über die Loopback-Adressen hinaus zu lauschen.

• Ein Dienst DARF NICHT den LAN-Modus aktivieren, es sei denn, der Nutzer schaltet ihn ausdrücklich ein.
• Im LAN-Modus MUSS ein Dienst eine Authentifizierung verlangen und SOLLTE außerdem TLS aktivieren. Ein Client SOLLTE NICHT ein Token über unverschlüsseltes HTTP an eine Nicht-Loopback-Adresse senden, es sei denn, der Nutzer erlaubt es ausdrücklich.
• Die mDNS-Ankündigung ist nur im LAN-Modus erlaubt, wenn der Nutzer außerdem die LAN-Erkennung eingeschaltet hat (Abschnitt 3.2).

10.6 Protokollierung und Datenschutz

• Modellpfade, Logs, Prompts und generierte Inhalte DÜRFEN NICHT in mDNS-Ankündigungen erscheinen.
• Standardmäßig SOLLTE ein Dienst nur Metadaten protokollieren (Zeiten, Endpunkte, Statuscodes, IDs, Token-Zahlen und Dauern). Er SOLLTE NICHT vollständige Prompts oder generierte Inhalte protokollieren.
• Health-Antworten und Fehlerdetails DÜRFEN NICHT Modellpfade, Prompts, Zugriffstokens oder andere sensible Informationen enthalten.