nosuid が VPN ヘルパーの root 化を妨げる理由

ディスク暗号化と nosuid マウントは同じ発想の変形のように聞こえますが、両者にはまったく関係がありません。一方は保存中のデータを守り、もう一方はプログラムが起動する瞬間にカーネルが特権ビットを尊重するかどうかを決めます。期待する識別情報に到達できないヘルパーは、後者の話をしているのです。前者が原因だという思い込みが、壊れてもいないクライアントの再インストールへ人を向かわせます。

無関係な二つの性質

ディスク暗号化は、マシンの電源が切れているときに誰がブロックを読めるかに答えます。マウントオプションは、誰かがファイルを実行したときにカーネルがそのモードビットをどう扱うかに答えます。前者は後者を何も制約せず、完全に暗号化されたノート PC でもすべての制限を備えたファイルシステムをマウントできます。

両者を一つの性質として読むことが、暗号化されたホームが root アクセスを妨げるという説を生みます。その説が生き残るのは、二つの症状が同じマシンに現れるからであり、原因を共有しているからではありません。

実際に遷移を抑止するもの

execve のリファレンスは、set-user-ID 付きの実行ファイルが新しいプロセスの実効識別子をファイルの所有者に変える仕組みを説明しています。同じページには、その遷移を抑止する条件とグループ ID に対する同等の条件、すなわち no_new_privs の設定、nosuid 付きでマウントされたファイルシステム、トレースされているプロセスが並んでいます。ファイルケイパビリティも同じ条件で無視されます。この四つの規則で、この種の報告のほとんどが説明できます。

その一覧は、ls が表示するモードだけでは認可の全体像にならない理由を説明します。どの条件が特定の失敗メッセージを引き起こしたかまでは教えてくれず、アプリケーションが同じ文言で無関係な資格情報の操作を報告している可能性もあります。結論を出す前に、正確なプログラム、ランチャー、エラーの順序を記録してください。

サポート対象のパッケージがインストールした実行ファイル、その所有者、実際のパス、それを収めるファイルシステムのポリシーを特定します。ダウンロード用フォルダにある複製は、モードが何と言おうと、インストールされたヘルパーではありません。

してはいけないこと

検証していないバイナリに set-user-ID ビットを付け、制限が消えるまで動かし回すのは修理ではありません。理解していなかったポリシーを、監査できない特権で置き換えることになり、ヘルパーに同じ手法を使うのはよく知られた権限昇格の経路です。マウントから nosuid を外すのはさらに悪く、そのファイルシステム上のすべてのプログラムに影響し、一つだけでは済みません。

サポートされた方法は、クライアントが文書化しているヘルパーまたはサービスのインストールを管理者が実行し、ポリシーが期待する場所にバイナリを置くことです。これで特権の仕組みは二つではなく一つに保たれます。

実際の起動コンテキストを確認する

許可された修正のあとは、root シェルからではなく、製品が実行するのと同じ方法でヘルパーを実行してください。root での成功は通常の利用者がたどる経路について何も証明せず、この二つの状況の違いこそが失敗の主題でした。

次に、ヘルパーが存在する理由であるネットワーク操作を確認します。起動しても インターフェースを設定できない ヘルパーは、問題を一段階先へ移しただけで、解決してはいません。

findmnt -no TARGET,OPTIONS /home
getcap /usr/libexec/openvpn-helper 2>/dev/null; ls -l /usr/libexec/openvpn-helper

マウントオプションとヘルパーの所有権を同じメモに記録します。そうしなければ、次にこれをデバッグする人が暗号化の説を最初から繰り返すことになります。