VPN の APT ソース:何を許すのか、どう制限するか

VPN クライアントのダウンロードは一度きりの判断だが、その APT リポジトリの追加は違う。後者は将来のソフトウェアがどこから来てよいかをパッケージマネージャーに伝えるもので、ダウンロードではなく権限の恒久的な移譲である。ベンダーがリポジトリを適切に維持しているなら正しい取り決めになりうる。それでも意識的な判断に値し、ほとんどのインストール手順はこれを飛ばしている。

署名が保証するのはアーカイブであり、そのコードではない

APT は署名されたリポジトリのメタデータを検証し、そのメタデータ内のチェックサムを取得したパッケージに対して信頼する。これが証明するのはアーカイブが鍵の保有者の公開したものと一致するということであり、中のコードについては何も示さない。正しく署名されたパッケージでも安全でないメンテナスクリプトを含みうるし、そのスクリプトはパッケージのインストール中に root として実行される。apt-secure のマニュアルは、アーカイブの認証とソフトウェアのレビューの間にまさにこの線を引いている。

したがって有用な問いは、署名が有効かどうかではない。壊れた署名はどのみちインストールを止めるのだから、問いはこれから誰の署名を信頼するかである。盗まれた署名鍵は盗まれたパッケージより悪い。攻撃者は最初の悪いリリースの後もずっと有効なメタデータを作り続けられるからであり、修復は鍵の交換だけで、それはベンダーが独立に検証できる経路で新しい鍵を公開するかどうかにかかっている。

だからこそ鍵の身元はリポジトリの URL と同じだけの注意に値する。古いフォーラムの回答にあるアドレスから取った鍵は発行者について何も証明しないが、HTTPS は電話に出た相手までの転送を守るだけである。転送の安全性と発行者の身元は別の問いであり、証明書が解くのは前者だけだ。

鍵をシステムではなくソースに限定する

現代の APT はソース固有の Signed-By 参照を受け付ける。運用者が管理する鍵は /etc/apt/keyrings/ の下に置け、ソースの項目はそのアーカイブを認証してよい鍵を名指しする。これは同じ鍵をグローバルに信頼された集合へ放り込むより狭い。そこでは決して許可するつもりのなかったソースまで保証しかねないので、世代の異なる手順の断片を混ぜるのではなく、インストールされている APT の版とベンダーの現在の指示に従うこと。

curl -fsSL https://repo.example.com/vpn-key.gpg -o /etc/apt/keyrings/vpn.gpg
echo "deb [signed-by=/etc/apt/keyrings/vpn.gpg] https://repo.example.com/debian stable main" > /etc/apt/sources.list.d/vpn.list

検証を無効にしたり未知のアーカイブを信頼済みにしたりして署名の失敗を直してはならない。それは見える誤りを目に見えない誤りに置き換えるだけで、目に見えないほうは誰かがソース一覧を監査するまで続く。鍵が合わないなら、正しい直し方は正しい鍵を見つけることであり、検査を外すことではない。

リポジトリの詳細と鍵の身元は、プロジェクトか管理された管理者から得る。ブログ記事からコピーした鍵は著者性についての主張であり、その証拠ではない。ベンダーが交換用の経路を公開したら鍵と同時に記録しておくべきで、その経路こそが次の交換を可能にする。

ソースの固定はパッケージの許可リストではない

鍵を一つのソースに限定すると、その鍵が認証できるアーカイブが限定されるのであって、そのアーカイブが公開してよいパッケージが限定されるのではない。リポジトリは望んだ VPN クライアントよりはるかに多くを配りうるし、どの適格な版が勝つかは APT の候補選択と優先度が決める。確定する前に、依存関係も同じアーカイブから来るのだから、依存関係の一覧も含めて提案された取引を確認すること。鍵の範囲は「このパッケージだけ」を表現できない。

より強い統制が必要なら、パッケージ名や版に関する方針として表し、その方針を構成管理の下に置く。取引を読むのに一分、半年後に予期しないパッケージを見つけるのに一度の見直しがかかる。

予期しないパッケージは進むべき時ではなく止まるべき時であり、アーカイブの所有者への問いはなぜそれが必要かである。一つのクライアントの周りに十数のパッケージを公開するのは、デスクトップスイートを出すベンダーには普通のことだ。それはインストール手順が示唆したより広い面でもあり、記録する価値があるのはこの部分である。どちらの結果も署名を疑う理由にはならず、どちらも自分が何を受け入れたかを書き留める理由になる。

権限とその外し方を記録する

アーカイブの所有者、対応する OS のリリース、鍵の交換経路、削除の手順を書き留める。この四つの事実が、クライアントの廃止やベンダーの鍵交換のときに後任が必要とするものだ。それらがなければ、次の人は経緯のないソース行と鍵ファイルを引き継ぐことになる。

削除は飛ばされがちな手順なので、インストールの時点で書いておく。ソースの項目とその専用鍵を一緒に消し、ファイルを消す前にその鍵が他所で参照されていないか確認する。その確認なしに共有鍵を消すと、片付けが無関係な障害に変わり、日常的な変更としては最悪の結果になる。そのうえで、項目が消えた後も通常の更新が解決することを確かめる。

リポジトリを外した後に残るものが一つある。そこから既にインストールされたパッケージは何かが置き換えるまで動き続け、正直な問いは、どんな権限を足したのか、その役割がどれほど狭く表現されていたのかである。