【ITニュース解説】Where the Node.js Permission Model Stops at Process Boundaries

Node.jsは、サーバーサイドの開発で広く使われるJavaScriptの実行環境だ。しかし、Node.jsアプリケーションが稼働する際に、多くの場合、そのコードが必要とする以上のオペレーティングシステム（OS）の権限を持って実行されているという課題がある。たとえば、ビルドスクリプトがソースツリーの一部を読み込むだけの機能であるにもかかわらず、実際にはネットワーク接続を開いたり、関連性のないファイルを調べたり、別のプログラムを起動したりできるような状況だ。これは、もし悪意のあるコードが紛れ込んだ場合や、プログラミングミスがあった場合に、システム全体に予期せぬ影響を及ぼすリスクがあることを意味する。

このような問題を解決するために、Node.jsには「許可モデル（Permission Model）」が導入された。このモデルは、実行時にアプリケーションが持つ機能を限定するための仕組みだ。つまり、Node.jsアプリケーションが「何ができて、何ができないか」を細かく制御できるようになる。ただし、この許可モデルは、ファイル所有権やユーザー権限、コンテナ、ネットワーク分離といったOSが提供するセキュリティ機能を置き換えるものではない。あくまでNode.jsのプロセス内部で機能するポリシー層として、OSのサンドボックスを補完する形で動作する。

許可モデルを有効にするには、Node.jsを起動する際に--permissionというフラグを付ける。このフラグを使うと、ファイルシステムへの読み書き、ネットワークアクセス、子プロセスの起動、ワーカー・スレッドの利用、ネイティブアドオンの読み込み、WASI（WebAssembly System Interface）、FFI（Foreign Function Interface）、そして開発ツールとして使われるインスペクターといった、Node.jsの組み込み機能のいくつかがデフォルトで制限される。そして、これらの機能が必要な場合には、--allow-fs-read（ファイルシステム読み取り許可）、--allow-fs-write（ファイルシステム書き込み許可）、--allow-child-process（子プロセス起動許可）、--allow-worker（ワーカー・スレッド利用許可）、--allow-net（ネットワークアクセス許可）といった具体的なフラグを追加して、必要な権限だけを明示的に与える仕組みだ。

この設計は、アプリケーションが必要とするリソースが明確で、そのリストが短い場合に最も効果を発揮する。たとえば、テンプレートを読み込んで一時ディレクトリに書き込むだけのコンテンツ表示アプリケーションであれば、必要なパスだけを許可し、それ以外の権限は与えないように設定できる。もしコマンドラインツールが別のプロセスを起動する必要がある場合でも、--allow-child-processフラグを追加する前に、その必要性を十分に検討すべきだ。ワーカー・スレッドに関しても同様で、ワーカー・スレッドはメインスレッドとは独立して処理を実行できるため、その利用には注意が必要だ。

特に注意が必要なのが、Node.jsの許可モデルは、現在のNode.jsプロセスにのみ適用されるという点だ。もしNode.jsプロセスが子プロセスを起動し、その子プロセスが独自のNode.jsランタイムを実行する場合、子プロセスは親プロセスの制限を自動的に継承しない。つまり、親プロセスが子プロセスの起動を許可されていれば、子プロセスは親とは異なる、より広い設定で実行ファイルを実行したり、同じNode.jsを親の許可フラグなしで再起動したりできてしまう可能性がある。

これは、ビルドシステムや自動化システムにおいて重要な意味を持つ。例えば、メインプロセスが/srv/app/srcという特定のパスからの読み取りだけに制限されているとする。しかし、もしこのメインプロセスが/bin/sh（シェルプログラム）を起動できる場合、シェルのファイル読み取り能力は、Node.jsの許可リストではなく、OSのユーザー権限によって決定される。この問題を実質的に制御するためには、親プロセスが本当に子プロセスへのアクセスを必要としない限り、その権限を与えないことが重要だ。さらに、子プロセスを起動する場合は、OSのアカウントやコンテナのポリシーを使って子プロセスを制限する対策が必要になる。

ワーカー・スレッドについても同様に、その作成時に許可モデルの評価が必要だ。ワーカー・スレッドはメインスレッドとは別の実行コンテキストで動作し、ワーカー・スレッドの作成自体も許可の対象となる。そのため、メインスレッドだけをテストするだけでは、機能フラグの変更によってワーカー・スレッドが起動されるパスで発生する可能性のある問題を、見落としてしまうことがある。

適切なテスト戦略として、各スコープ（許可範囲）について「拒否されるはずの操作」を試すネガティブテストを含めるべきだ。具体的には、意図したフラグを付けてアプリケーションを起動し、許可されていない操作を実行してみて、それがエラーで失敗することを確認する。このエラーが監視システムで認識できるものであるかもチェックする。そして、ワーカーや子プロセスが作成された後でも、そのプロセスが必要なアクセス権しか持っていないことを検証する必要がある。

また、既存のハンドルにも注意が必要だ。許可モデルによるチェックは、ある操作が実行されようとしたときに適用される。そのため、ポリシーが変更されても、既に開かれているファイルディスクリプタ、ソケット、子プロセス、ワーカー・スレッドなどが自動的に閉じられるわけではない。もしアプリケーションの起動時に、広い権限で接続が確立された後で、ポリシーが制限されたとしても、既に開かれた接続は、その後のポリシーよりも広い権限を持ったまま動作し続ける可能性がある。

Node.jsのインスペクター（開発者ツール）にも関連する運用上の限界がある。ドキュメントには、通常の許可スコープではカバーされないパスであっても、同じユーザー（OSアカウント）で実行されている別のプロセスに影響を与える可能性があると記されている。複数のNode.jsサービスを単一のOSアカウントで実行しているチームは、その共有されたOSアカウントのIDがセキュリティ境界の一部であると認識すべきだ。サービスごとに個別のOSアカウントを割り当てることで、同じユーザーによる操作の影響範囲を減らし、プロセス制御の監査を容易にすることができる。

防御可能なデプロイメントチェックとして、アプリケーションの測定されたワークフローを満たす、最小限の許可リストを使用することが非常に重要だ。例えば、--allow-child-processや--allow-workerといったフラグは、アプリケーションがそのタスクをプロセス内で実行できない理由が、コードの所有者によって明確に説明された場合にのみ追加するべきだ。デプロイ時には、クリーンな作業ディレクトリからアプリケーションを実行し、絶対パスと相対パスの両方でテストを行い、再起動後も期待通りの動作をしているかを検証する。

最後に、デプロイの証拠として、実際に使用した起動コマンドをログに残すことが重要だ。開発者のシェル履歴にしか存在しない許可モデルの設定は、サービスが別の環境に移行した際に失われる可能性がある。デプロイの記録として、許可されたスコープの短いリストと、拒否されたテストの少ないリスト、そしてNode.jsコードが意図したパスから逸脱した場合でも有効なOSレベルの境界を確立しておくことが、セキュリティを維持する上で非常に有効な結果をもたらす。