ローカルセキュリティ

10.1 基本方針

localhost だけで待ち受ければ絶対に安全というわけではない。悪意ある Web ページが、ローカルのポートへの到達を試みる可能性があるためである。そこで LMSP は、複数の対策を組み合わせる。

• サービスは、既定でループバックアドレスにバインドしなければならない。LAN モードが有効でない限り（10.5 節）、0.0.0.0 やその他のループバック以外のアドレスで待ち受けてはならない。
• サービスは、初回の実行時に、エントロピーの高いランダムなサービスシークレットを生成し、組み込みの既定値ではなくそれを使ってトークンを発行・検証するべきである。
• コアインターフェースへのすべてのリクエストは、4.2 節に挙げたブートストラップ用エンドポイントを除き、有効なベアラートークンを携えなければならない。ループバックから来たというだけでは、決して十分ではない。

10.2 ペアリングとトークン

クライアントは、ローカルのペアリングコードによって、自分専用のベアラートークンを得る。ユーザーは、サービスが提供する任意の方法でペアリングコードを表示させ、クライアントがそれを送信する。

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

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

サービスはトークンで応答する。token_type は常に Bearer である。

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

その後、クライアントはすべてのリクエストで Authorization: Bearer <token> を送る。

• ペアリングコードは、使い捨てでなければならず、5 分以内に期限切れとなるべきである。少なくとも 40 ビットのエントロピーを持つべきである。サービスは、失敗した試行にレート制限をかけなければならない。誤った、または期限切れのコードには、401 と unauthorized で応答する。
• トークンはクライアントごとに独立しているため、ユーザーは、他のクライアントに影響を与えずに 1 つのクライアントを失効させられる。サービスは、ユーザーがペアリング済みクライアントを一覧し、失効させられるようにするべきである。
• クライアントは、トークンを OS のキーチェーンや資格情報マネージャーに保存するべきである。サービスは、各トークンのハッシュだけを保存するべきである。
• トークンがない、無効、または失効している場合は、401、unauthorized、WWW-Authenticate: Bearer ヘッダーで応答する。有効なトークンであっても、エンドポイントが必要とするスコープを持たない場合は、403 と forbidden で応答する。

10.3 スコープ

権限は、別々のスコープに分けられている。モデルのダウンロード、モデルの削除、ツールの実行が、inference スコープに便乗することは決してない。

タスクと保存済みレスポンスは、それを作成したクライアントに属する。サービスは、他のクライアントからのリクエストに対し、それらが存在しないかのように応答するべきである（task_not_found または response_not_found）。

10.4 ブラウザーとネットワークの保護

• サービスは、既定でクロスオリジンのブラウザーリクエストを拒否し、明示的に設定された Origin の値だけを許可しなければならない。それ以外の Origin を持つリクエストには、403 と forbidden で応答する。
• オリジンが許可されている場合、サービスはその CORS プリフライトリクエストに応答し、Access-Control-Allow-Origin に、* ではなく、そのオリジンそのものを入れて送る。
• サービスは、DNS リバインディングを防ぐために、Host ヘッダーを検証しなければならない。受け付けるのは、サービスが提供するホスト名、すなわちループバックの名前とアドレス、および LAN モード用に設定された名前だけである。それ以外の値には、403 と forbidden で応答する。

10.5 LAN モード

LAN モードとは、ループバックアドレスの外でも待ち受けることを指す。

• サービスは、ユーザーが明示的にオンにしない限り、LAN モードを有効にしてはならない。
• LAN モードでは、サービスは認証を要求しなければならず、TLS も有効にするべきである。クライアントは、ユーザーが明示的に許可しない限り、ループバック以外のアドレスにプレーンな HTTP でトークンを送るべきではない。
• mDNS アドバタイズが許されるのは、LAN モードで、かつユーザーが LAN 発見もオンにしている場合だけである（3.2 節）。

10.6 ログとプライバシー

• モデルのパス、ログ、プロンプト、生成内容は、mDNS アドバタイズに含まれてはならない。
• 既定では、サービスはメタデータ（時刻、エンドポイント、ステータスコード、ID、トークン数、所要時間）だけを記録するべきである。完全なプロンプトや生成内容は記録するべきではない。
• ヘルスレスポンスとエラーの詳細は、モデルのパス、プロンプト、アクセストークン、その他の機微な情報を含んではならない。