曲者に権限が渡らない OSS 権限移譲プロセスが難しい

曲者に OSS の権限が付与され、悪意のあるコードを埋め込まるような事件をおこさない OSS 権限移譲フローを考えてみました。

TL;DR

基本的に OSS の権限譲渡を 選ばない方 が安全といえそうです。なぜなら、次のように権限譲渡の安全性を担保することはとても難しく、かつ高価につくからです。

代わりに、プロジェクトを停止するか、信頼できる人物に fork を依頼する（現状の project は archive）のが、責任回避の意味で有効だと思われます。

背景

「2018/11/27に判明したnpmパッケージ乗っ取りについて」が世間を騒がせていますが、個人的に驚いたのは件の package の元々の作者である方への非難の声が多いことでした。

個人的には、この事件の根本は npm 側の機能不足が問題という認識（postinstall フックなどの自動的なフックによって操作ユーザーの権限で任意のコマンドを実行できるのにサンドボックス機能を用意しなかったこと）ですが、世間的にはそうとみなさなず、軽々しく権限を譲渡するなという意見もかなり見受けられました。

では、軽々しくない権限譲渡とはどのようなものでしょうか。この条件がなかなか難しいように思えたので、その方法を考えてみました。

面識のある人物でセキュリティリテラシに問題がなければ信頼する

移譲先がすでに面識のある人物で、移譲先のアカウントが確かにその人物のものであれば信頼する。

面識のない人物は身辺調査で問題がなければ信頼する

移譲先が面識のない人物であれば、GitHub や SNS などで身辺調査をおこなう。身辺調査の内容は、GitHub の継続年数や著名な他プロジェクトへの貢献、SNS 上での発言からセキュリティリテラシの分析など。もし情報がない/不透明ならば信頼しない。

信頼した人物が3人未満にならないようにし、過半数の合意でリリースがおこなわれるようにする

上記2条件で信頼したとしても、まだ悪意のある人物な可能性を否定できないので、過半数が悪意のある人物になる確率が十分低くなるような（これはプロジェクトに要求される品質レベルによる）人数に同時に譲渡する。ただし、これは現在の GitHub の機能では不可能に見える。

条件1: 面識のある人物でセキュリティリテラシに問題がなければ信頼する

この条件では、移譲先がすでに面識のある人物で、移譲先のアカウントが確かにその人物のものであれば信頼できるとみなします。これは、ブラックハットは足のつきやすい顔出しのリスクを避けるだろう、という推測から設定しました。

ただし、この条件の確認に手間がかかる場合があります。というのも、別のアカウントと誤解させる目的で見分けのつきにくい文字置換がされたアカウント（@kuniwak → @kun1wak のような）を QR コードなどで提示された場合、なりすましの成立する可能性があります。

ここで、「所有しているリポジトリやそのスター数でわかるのでは？」と思われるかもしれませんが、スター数が数十程度であれば スパムアカウントによって自演が可能です。したがって、そのリポジトリのアクティビティが実体のあるアカウントによってなされたかどうかを確認しなければなりません。また、Issue や Pull Request の本文や差分は、他プロジェクトの物をそっくり盗用して同期するという方法は安価で実現できますから、本文などからだけでは判断できないのです。したがって、これを考慮したアカウントの本人確認はとても手間ですね。

また、面識があったとしても本人のセキュリティリテラシが低ければ、リスクは段違いに高くなります。したがって、本人にきちんとしたセキュリティリテラシがあることを確信できければなりません。これを確かめるのは非常に骨が折れますが、SNSや対面でセキュリティの質問をするしかないと思います。

条件2: 面識のない人物は身辺調査で問題がなければ信頼する

この条件では、移譲先が面識のない人物であれば GitHub や SNS などで身辺調査をおこない、問題がなければその人物を信頼できるとみなします。この身辺調査の内容は、GitHub の継続年数や著名な他プロジェクトへの貢献、SNS 上での発言からセキュリティリテラシの分析などが考えられるでしょう。そして、もし情報がない/不透明ならば信頼しないというのが原則になります。

面識のない人物であれば、面識のある人物よりリスクが高くなります。したがって、条件1よりも厳しい身辺調査が必要なのは明白です。例えば、GitHub アカウントに記載された SNS アカウントなどは容易に詐称可能で、その本人確認を安価にできないかもしれません¹。したがって、幸運にもこのような身辺調査が可能で問題がなさそうであれば、ようやく信頼できるとみなせるでしょう。

条件3: 信頼した人物が3人未満にならないようにする

上記の2条件で信頼できたとしても、まだ悪意のある人物な可能性を否定できません。そのため、権限をもつアカウントの過半数が悪意のある人物になる確率を十分低くできるような（これはプロジェクトに要求される品質レベルによる）人数に譲渡するといった方法が考えられるでしょう。

しかし、これは1つの悪意あるアカウントによって、他の善良なアカウントを締め出せるようなら意味がありません。これを防ぐ方法は、譲渡元の人物が Admin 権限を渡さないことが条件になります。しかし、少なくとも Write 権限を他者へ渡せなければ、実質的に負担が減らないず権限移譲をする意味がありません。そのため、悪意のある一人の人物によって悪性のコードを、短時間リリースされるリスクは呑まなければならないでしょう。これが GitHub における現状の権限移譲の限界かと思われます。

結論

ここから見えてくることは、権限譲渡の安全性を担保することはとても難しく、かつ安全を担保するプロセスはとても高価だということです。そのため、基本的には権限移譲を考えない方がセキュリティの観点からはよさそうです。

代わりに、信頼できる人物に fork を依頼（現状の project は archive）するという方法があります。ただし、この方法は本質的にはユーザーに信頼の判断を委ねるということになりますから、実質的な安全性は変わっていません。セキュリティ担保の責任の主体がユーザーへ移動するだけで、依然として信頼を確認することが難しいためです。

1. SNS の profile から GitHub へのリンクがなく、SNS での投稿に本人と GitHub アカウントとの関係を示唆するような投稿がない状況を想定しています。また、リンク先の SNS アカウントもなりすましという可能性さえありえます。 ↩