Segurança local | LMSP 1.0 Rascunho

10.1 Linha de base

Escutar apenas em localhost não é segurança absoluta: uma página web maliciosa ainda pode tentar alcançar portas locais. Por isso o LMSP combina várias medidas.

Um serviço DEVE se vincular por padrão aos endereços de loopback. Ele NÃO DEVE escutar em 0.0.0.0, nem em qualquer outro endereço que não seja de loopback, a menos que o modo LAN esteja ativado (seção 10.5).
Na primeira execução, um serviço DEVERIA gerar um segredo de serviço aleatório de alta entropia e usá-lo, em vez de qualquer valor padrão embutido, para emitir e verificar tokens.
Toda requisição à interface principal DEVE carregar um token de portador válido, exceto nos endpoints de bootstrap listados na seção 4.2. Vir do loopback nunca basta por si só.

10.2 Pareamento e tokens

Um cliente obtém seu próprio token de portador com um código de pareamento local. O usuário pede ao serviço que mostre um código de pareamento, da maneira que o serviço oferecer, e o cliente o envia:

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

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

Campo da requisição	Significado
`client_name`	Nome de exibição do cliente, mostrado ao usuário.
`pairing_code`	O código que o usuário obteve do serviço.
`scopes`	Lista opcional de escopos solicitados. O padrão é `["inference"]`.

O serviço responde com um token. O token_type é sempre Bearer:

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

O cliente então envia Authorization: Bearer <token> em todas as requisições.

Um código de pareamento DEVE ser de uso único e DEVERIA expirar em até 5 minutos. Ele DEVERIA ter pelo menos 40 bits de entropia. Um serviço DEVE limitar a taxa de tentativas malsucedidas. Um código errado ou expirado é respondido com 401 e unauthorized.
Os tokens são independentes por cliente, de modo que o usuário pode revogar um cliente sem afetar os demais. Um serviço DEVERIA permitir que o usuário liste e revogue os clientes pareados.
Um cliente DEVERIA guardar seu token no chaveiro ou no gerenciador de credenciais do sistema operacional. Um serviço DEVERIA armazenar apenas um hash de cada token.
Um token ausente, inválido ou revogado é respondido com 401, unauthorized e um cabeçalho WWW-Authenticate: Bearer. Um token válido que não tem o escopo exigido por um endpoint é respondido com 403 e forbidden.

10.3 Escopos

As permissões são divididas em escopos separados. Baixar modelos, excluir modelos e executar ferramentas nunca pegam carona no escopo de inferência.

Escopo	Permite
`inference`	Ler o catálogo de modelos, criar respostas e tarefas, e ler e cancelar as tarefas do próprio cliente.
`models:manage`	Carregar e descarregar modelos.
`models:install`	Reservado. Baixar e excluir modelos.
`tools:execute`	Reservado. Executar ferramentas no lado do serviço.

As tarefas e as respostas armazenadas pertencem ao cliente que as criou. Um serviço DEVERIA responder a uma requisição de outro cliente como se elas não existissem (task_not_found ou response_not_found).

10.4 Proteções de navegador e de rede

Um serviço DEVE rejeitar por padrão as requisições de navegador entre origens diferentes e permitir apenas os valores de Origin configurados explicitamente. Uma requisição com qualquer outro Origin é respondida com 403 e forbidden.
Quando uma origem é permitida, o serviço responde às suas requisições preflight de CORS e envia Access-Control-Allow-Origin com exatamente essa origem, nunca com *.
Um serviço DEVE validar o cabeçalho Host, para impedir o DNS rebinding. Ele aceita apenas os nomes de host que atende: os nomes e endereços de loopback, mais quaisquer nomes configurados para o modo LAN. Qualquer outro valor é respondido com 403 e forbidden.

10.5 Modo LAN

O modo LAN significa escutar além dos endereços de loopback.

Um serviço NÃO DEVE ativar o modo LAN a menos que o usuário o ative explicitamente.
No modo LAN, um serviço DEVE exigir autenticação e DEVERIA também ativar o TLS. Um cliente NÃO DEVERIA enviar um token por HTTP simples para um endereço que não seja de loopback, a menos que o usuário permita explicitamente.
O anúncio mDNS só é permitido no modo LAN, quando o usuário também ativou a descoberta na LAN (seção 3.2).

10.6 Logs e privacidade

Caminhos de modelos, logs, prompts e conteúdo gerado NÃO DEVEM aparecer nos anúncios mDNS.
Por padrão, um serviço DEVERIA registrar apenas metadados (horários, endpoints, códigos de status, IDs, contagens de tokens e durações). Ele NÃO DEVERIA registrar prompts completos nem conteúdo gerado.
As respostas de integridade e os detalhes de erro NÃO DEVEM conter caminhos de modelos, prompts, tokens de acesso nem outras informações sensíveis.