タラバガニー設計局stalins.clubNOTE/notes/installer-code-execution-as-trust-boundary

installer scriptを許すほどpackage managerのtrust surfaceは広がる

tool version managerやbinary package managerが多様なsoftwareを扱おうとすると、「downloadしてarchiveを展開するだけではinstallできないtool」をどう扱うかという問題にぶつかる。

最も柔軟なのはpackage/pluginごとに任意のinstall scriptを実行させる方法である。しかしその瞬間、registry metadataは単なるdataではなく、local machineでcode executionを誘発するprogram distribution mechanism に近づく。

aquaはupstream releaseを正規化するパッケージマネージャーと捉えられる のaquaはこの境界をかなり意識した設計を採っている。公式ドキュメントはinstall processを基本的に「downloadし、$AQUA_ROOT_DIRへunarchiveする」ものに限定し、任意のexternal commandは実行しないとしている。Go/Cargoやverification tool等には例外があるが、この制約をsimple、secure、dependencyが少ない、troubleshootingしやすいという利点として説明している。

これはaqua Registryはupstream releaseの不統一を正規化するのようなrelease差異を、なるべくdeclarative metadataだけで吸収する設計でもある。

対照的にasdf pluginはshell scriptを中心としたextension modelを採る。miseは現在、asdf pluginをlegacy扱いし、新規registry entryではsupply-chain securityを理由にaquaまたはgithub backendを推奨している。miseのdocumentationは、asdf pluginがtool vendorとは無関係な単独maintainerにより書かれている場合が多いこともriskとして挙げている。

ここで重要なのは「shell scriptだから危険、YAMLだから安全」という単純な話ではない。declarative installerでもdownload URLやexecutable selectionを書き換えられれば攻撃は可能である。違いは registry authorに与えるcapabilityの大きさ にある。

任意script modelでは、pluginが理論上できることは非常に広い。

  • arbitrary command execution
  • filesystemの任意位置へのwrite
  • credential/environment variableのread
  • network access
  • shell/toolchain依存の追加

一方、download/unarchive modelをpackage manager実装側で固定すれば、registry entryが表現できる操作をURL selection、archive extraction、file exposure等へ狭められる。security reviewでは「plugin sourceを全文auditする」代わりに、schemaで許可されたoperationだけを確認できる。

ただし制約にはcompatibility costがある。特殊なpost-install処理、environment variable設定、source build、platform独自処理が必要なtoolを扱いにくくなる。miseのdocumentationも、aqua/githubでは扱えないcomplex install setupのためにasdf/vfox等が必要な場合があるとしている。

したがってinstaller architectureには、概ね次のtrade-offがある。

expressivenessを上げるほどpackage coverageは増えるが、registry/plugin authorへ渡すexecution authorityも増える。

この観点では、package managerのsecurityを「署名verificationの有無」だけで評価するのではなく、package definitionがどの程度のside effectを表現できるかを見る必要がある。さらに、そのdeclarative metadata自体を誰が更新できるかは package registry metadata自体がsupply-chain trust boundaryになる の問題になる。

#security #ツールチェーン

出典

▸ ノート一覧に戻る