VS Codeのプロセスサンドボックス化への移行

セキュリティとVS CodeアーキテクチャにとってWin-Winの関係

2022年11月28日 Benjamin Pasero著、@BenjaminPasero

Electronのレンダラープロセスでサンドボックスを有効にすることは、Visual Studio Codeのような安全で信頼性の高いElectronアプリケーションにとって非常に重要な要件です。サンドボックスは、ほとんどのシステムリソースへのアクセスを制限することで、悪意のあるコードが引き起こす可能性のある損害を軽減します。2020年初頭に開始し、2023年初頭に完了する予定のこの取り組みにおいて、VS Codeでプロセスサンドボックスを有効にする方法について、このブログ記事で詳細な概要を説明します。プロセスサンドボックス化の課題を理解しやすくするために、この記事ではVS Codeのプロセスモデルの詳細と、この取り組みの中でそれがどのように進化したかについても説明します。

これはチームの努力の賜物でした。なぜなら、VS Codeのほぼすべてのコンポーネントで、根本的なアーキテクチャの変更とコードの修正が必要だったからです。VS Codeのプロセスアーキテクチャは見直され、その過程で大幅に強化されました。私たちは、その道のりにおける主要なマイルストーンを強調し、他の方々が学ぶための貴重な洞察を提供できればと考えています。過去数ヶ月間、プロセスサンドボックスモードはVS Code Insidersで正常に実行されており、この変更の影響についてのフィードバックを得ています。問題を見つけたり、エクスペリエンスを改善するための提案があったり、一般的な質問がある場合は、遠慮なくお問い合わせください。

VS Code、Electron、またはサンドボックスに慣れていない場合は、まずブログ記事の最後にある用語集のセクションを確認することをお勧めします。そこでは、使用されている用語の説明と、背景資料へのリンクが記載されています。

プロセスサンドボックスの概要

長い間、ElectronではHTMLとJavaScriptでNode.js APIを直接使用することができました。以下のコードスニペットは、ユーザーに「Hello World」と表示するだけでなく、ローカルディスク上のファイルに書き込みも行うWebページの簡単な例です。

ユーザーにWebページを表示する役割を担うElectronプロセスは、レンダラープロセスと呼ばれます。レンダラープロセスでサンドボックスモードを有効にすると、セキュリティを向上させ、Webモデルにより適合させるためにその機能が削減されます。HTMLとJavaScriptは引き続き許可されますが、Node.jsの使用は許可されません。レンダラープロセス内でシステムリソースへのアクセスが必要なコンポーネントは、サンドボックス化されていない別のプロセスに処理を委任する必要があります。

以下のコードはもはやNode.jsに依存せず、設定を更新する機能を提供するグローバル変数vscodeを使用しています。このメソッドの実装には、Node.jsにアクセスできる別のプロセスにメッセージを送信することが含まれます。そのため、もはや同期的ではなく非同期的に実行されます。

どのようにしてレンダラープロセスにvscodeグローバル変数が導入され、それがどのように実装されているかについては、以下のタイムラインのセクションで詳しく説明します。

レンダラープロセスからのNode.jsのブロックは、Electronで推奨されているセキュリティ勧告です。過去には、攻撃者がレンダラープロセスから任意のNode.jsコードを実行できるというセキュリティ問題がありました。サンドボックス化されたレンダラープロセスは、これらの攻撃のリスクを大幅に軽減します。

どのようにして実現したか？

レンダラープロセスからすべてのNode.js依存関係を削除するという大きな変更には、リグレッションやバグのリスクが伴います。以前は1つのプロセスで実行されていたコードを、複数のプロセスに分割して実行する必要があります。ネイティブでWebパッケージ化できないNodeモジュールも移動させる必要があります。Node.jsのBufferのような特定のグローバルオブジェクトは、Uint8Arrayのようなブラウザー互換のバリアントに置き換える必要があります。

下の図は、サンドボックスの取り組みが始まる前の私たちのプロセスアーキテクチャを示しています。ご覧のとおり、ほとんどのプロセスはレンダラープロセスからフォークされたNode.jsの子プロセス（緑色）です。ほとんどの（プロセス間通信）IPCはNode.jsソケットを介して実装されており、レンダラープロセスはNode.js APIの主要なクライアントです（例えば、ファイルの読み書きのため）。

私たちはすぐに、サンドボックス化された別のVS Codeアプリケーションをリリースすることなく、プロセスサンドボックスに取り組みたいと決めました。VS Codeのレンダラープロセスを段階的にサンドボックス対応にし、最後にスイッチを切り替えることを目指しました。過去数年間、私たちはサンドボックスの目標に貢献する変更を加えつつも、それを完全に有効にすることなく、VS Codeの月次安定版リリースを出荷してきました。まるで、飛行中の飛行機を根本的に再構築しているようなものです。そして私たちの場合、ユーザーはVS Codeへの変更にほとんど気づいていませんでした。

私たちの技術タイムライン

次のセクションでは、過去数年間にわたってサンドボックス化がどのように実現されてきたかを詳しく説明します。主なタスクはレンダラープロセスからすべてのNode.js依存関係を削除することでしたが、その過程でMessagePortを利用した効率的なサンドボックス対応IPCソリューションを見つけ出すことや、レンダラープロセスからフォークできた様々なNode.js子プロセスのための新しいホストを見つけることなど、さらなる課題が浮上しました。

ほとんどの場合、トピックの順序は実際のタイムラインに従っています。各セクションを簡潔に保つために、特定の技術的側面をより詳細に説明する他のドキュメントやチュートリアルへのリンクを掲載しています。そして、この作業を2020年初頭に計画したとはいえ、このタスクに貢献した以前の作業を省略するのは不公平です。詳しく見ていきましょう...

巨人の肩の上に立つ

2020年初頭にサンドボックス化を検討し始めたとき、私たちはすでにWebブラウザーで実行できるバージョンのVS Codeをリリースしていました。vscode.devをブラウザーで実行し、Visual Studio Code for the Webの動作を確認できます。VS CodeのWeb版を作成する過程で、私たちはメインのVS CodeユーザーインターフェースウィンドウであるワークベンチからNode.jsの依存関係を削除する方法を学びました。

Node.jsへの依存関係を削除するということは、代替案を見つけることを意味しました。たとえば、Node.jsのBuffer型への依存は、ブラウザー環境ではUint8ArrayにフォールバックするVSBuffer相当のものに置き換えられました。また、いくつかのNode.jsモジュール（oniguruma、iconv-lite）をWeb環境で実行できるようにパッケージ化することもできました。

しかし、VS Code for the Webが現実になる以前から、私たちはリモート開発のサポートを有効にしていました。これにより、SSH接続などを介してリモートホスト上のソースコードを編集できます（そして後にはGitHub Codespacesの原動力にもなりました）。リモート開発のためには、VS CodeのUI関連の部分はローカルで実行し、実際のファイル操作はリモートマシンで実行するソリューションを実装する必要がありました。このモデルは、特権操作を別のプロセスで実行する必要があるサンドボックス化されたワークベンチにも当てはまります。どちらの場合も、レンダラープロセスはIPCを介して特権ホストと通信し、操作を実行します。

レンダラーからの通信チャネルの有効化

レンダラープロセスがNode.jsを使用できない場合、作業はNode.jsが利用可能な別のプロセスに委任する必要があります。Webの文脈での一つの解決策は、サーバーがリクエストを受け入れるHTTPメソッドに依存することです。しかし、デスクトップアプリケーションでは、ポートでローカルサーバーを実行することがセキュリティ上の理由からファイアウォールによってブロックされる可能性があるため、これは最善の解決策とは思えませんでした。

Electronは、メインスクリプトが実行される前に実行されるプリロードスクリプトをレンダラープロセスにインジェクトする機能を提供します。これらのスクリプトは、Electron独自のIPCメカニズムにアクセスできます。プリロードスクリプトは、コンテキストブリッジAPIを介して、レンダラーのメインスクリプトで利用可能なAPIを拡張できます。プリロードスクリプトはElectronのIPCを直接使用できますが、メインスクリプトはできません。そのため、私たちは特定のメソッドを公開し、コンテキストブリッジを介してメインスクリプトに提供しています。冒頭で使用した例では、設定を更新するためのメソッドをプリロードスクリプトからメインスクリプトに公開する方法は次のようになります。

プリロードスクリプトは、特権コードを非特権コードから分離するための基本的な構成要素です。たとえば、ディスク上のファイルに書き込むことは、新しい内容を含むIPCメッセージがメインスクリプトからプリロードスクリプトへ、そしてそこからNode.jsにアクセスできるメインプロセスへと移動することを意味します。

メッセージポートによる高速なプロセス間通信

プリロードスクリプトの導入により、レンダラープロセスがElectronのメインプロセスと通信して作業をスケジュールする方法ができました。しかし、Electronアプリケーションでは、メインプロセスに過剰な負荷をかけないことが重要です。なぜなら、メインプロセスはキーボードやマウスからのユーザー入力を処理する役割も担っているからです。メインプロセスがビジー状態になると、ユーザーインターフェースが応答しなくなる可能性があります。

これは以前にも見られた問題でした。サンドボックス化に取り組む前から、私たちはパフォーマンスを多用するコードをバックグラウンドプロセス、すなわちVS Codeの共有プロセスにオフロードすることに関心がありました。このプロセスは隠しウィンドウであり、すべてのワークベンチウィンドウとメインプロセスが通信できます。例えば、拡張機能をインストールすると、リクエストが共有プロセスに送信され、操作全体が実行されます。

しかし、共有プロセスとの通信はNode.jsソケットを介して実装されていました。これには、通信にメインプロセスが一切関与しないため、オーバーヘッドがゼロであるという利点がありました。欠点は、Node.jsソケット通信はサンドボックス化されたレンダラーでは使用できないことです。なぜなら、どのNode.js APIも使用できないからです。

メッセージポートは、2つのプロセス間にIPCチャネルを確立することで、それらを接続する強力な方法を提供します。完全にサンドボックス化されたレンダラープロセスでさえ、メッセージポートはブラウザーでWeb APIとして提供されているため、使用できます。Node.jsソケット通信をメッセージポートに置き換えることで、メインプロセスを巻き込むことなくパフォーマンスを維持するという側面を保ちながら、サンドボックス互換のIPCソリューションを実現できました。

プロセス境界を越えて、特にプリロードスクリプトを持つサンドボックス化されたレンダラープロセスにメッセージポートを渡すことは複雑です。その手順は以下の図に示されています。

• 共有プロセスはメッセージポートP1とP2を作成し、P1を保持します。
• P2はElectron IPCを介してメインプロセスに送信されます。
• メインプロセスはP2を要求元のレンダラープロセスに転送します。
• P2はそのレンダラープロセスのプリロードスクリプトに到達します。
• プリロードスクリプトはP2をレンダラーのメインスクリプトに転送します。
• メインスクリプトはP2を受け取り、それを使って直接メッセージを送信できます。

レンダラーのオリジンの変更

Webブラウザーでは、URLを入力するとコンテンツが読み込まれて表示されます。Electronでは、URLを入力する代わりに、アプリケーションがどのコンテンツを読み込んで表示するかを決定します。したがって、VS Codeを開くと、ワークベンチのコンテンツを表示するために事前に設定されたURLを持つウィンドウが読み込まれます。

VS Codeでは、このURLはディスク上の実際のファイルを指すローカルファイルプロトコル（file://<ディスク上のファイルへのパス>）を使用していました。サンドボックス化作業の一環として、このアプローチには深刻なセキュリティ上の影響があったため、見直しました。Chromiumはローカルファイルプロトコルに対して、HTTPSプロトコルと比較して緩やかなセキュリティ上の仮定を置いています。たとえば、ローカルファイルプロトコルのURLに対しては厳密なオリジンチェックが適用されません。

Electronでは、レンダラープロセスにコンテンツを読み込むために使用できるカスタムプロトコルを登録できます。カスタムプロトコルは、セキュリティに関してHTTPSプロトコルと同じように動作するように設定できます。私たちはこのアプローチを使用して、コンテンツを提供するローカルWebサーバーを実行する必要をなくしました。

すべてのレンダラープロセスにカスタムのvscode-fileプロトコルを導入することで、ファイルプロトコルの使用をすべて廃止することができました。これはHTTPSのように動作するように設定されており、VS Code for the Webの実際の動作に近づいたことを意味します。

コードローダーの適応

歴史的に、私たちのすべてのTypeScriptコードはAMDモジュールにコンパイルされ、長年にわたって維持してきたカスタムローダーで読み込まれてきました。私たちはAMDから脱却し、ESMを採用する計画ですが、その作業はまだ初期段階です。

私たちのコードローダーは、いくつかの明確に定義された変数を調べて実際の実行環境を特定することにより、Node.jsとWebの両方の環境をサポートしています。サンドボックス化されたレンダラーは本質的にWeb環境のようなものなので、ローダーがサンドボックスをサポートするために必要な変更はほとんどありませんでした。

これらの変更が完了すると、サンドボックスモードを有効にしたVS Codeの初期バージョンを実行できるようになりました。しかし、まだレンダラープロセスをNode.jsの依存関係から解放していなかったため、コンソールにエラーが出力されるだけで、空白のページが表示されるだけでした。

導入を支援するツール

サンドボックスを有効にしてVS Codeを実行する方法ができたので、Node.jsに依存するソースコードから「サンドボックス対応」のコードへの移行を容易にするためのツールに投資したいと考えました。VS Code for the Webへの投資を考えると、Node.jsコードがWeb版に出荷されるのを防ぐための静的解析ツールがすでに導入されていました。このツールは、ランタイム要件を持つ一連のターゲット環境を定義していました。私たちのツールは、許可されていないターゲット環境でNode.jsのグローバルオブジェクト（Bufferなど）、Node.js API、またはnodeモジュールの使用を検出し、報告することができます。サンドボックス化の作業のために、私たちはNode.jsの使用を一切許可しない新しいターゲット環境electron-sandboxを追加しました。コードをこの環境に移行することで、徐々にコードをサンドボックス対応にすることができました。

以下のスクリーンショットでは、browserターゲット環境のファイルがNode.jsのAPIに依存していることを示す警告マーカーがエディターに表示されています。この警告によりビルドが失敗し、このコードが誤ってリリースにプッシュされるのを防ぎます。

私たちのプロセスエクスプローラーと問題報告ユーティリティは、electron-sandboxのターゲット要件に準拠した最初のツールでした。ワークベンチウィンドウが採用を完了するずっと前に、これらのウィンドウを完全にサンドボックス化して実行することができました。

レンダラーからのプロセスの移動

前のトピックで詳しく説明したように、Node.jsの機能の一部を別のプロセスに移動し、IPCを使用して作業をスケジュールし、結果を受け取ることは、簡単に行うことができます。

しかし、ワークベンチ内のNode.jsに依存するコンポーネントの中には、子プロセスをフォークするものなど、より複雑なものがあります。具体的には、

• 拡張機能ホスト
• 統合ターミナル
• ファイル監視
• 全文検索
• タスク実行
• デバッグ

VS Codeはリモートシナリオで実行できるため、検索、デバッグ、タスク実行といった一部のタスクをリモートで実行するためのメカニズムがすでにありました。これらのコンポーネントは、コードがある場所のローカルで自然に実行される拡張機能ホストプロセス内で動作できます。そのため、VS Codeがリモートに接続せずにローカルで実行されている場合でも、これらの子プロセスの所有権をレンダラープロセスから拡張機能ホストに移動することができました。

拡張機能ホストについては、より野心的な計画がありました。Electronに新しい「ユーティリティプロセス」APIを追加する必要があったため、これらの変更については後ほど独自のセクションで説明します。

統合ターミナルとファイル監視は、共有プロセスのチャイルドプロセスになるように移動しました。ファイル監視や統合ターミナルを必要とするウィンドウは、メッセージポートを介して共有プロセスと通信し、これらのサービスを取得します。

下の図は、レンダラープロセスでサンドボックスを有効にした後の2022年後半の私たちのプロセスアーキテクチャを示しています。すべてのNode.jsプロセスは、共有プロセスのチャイルド、またはメインプロセスからのユーティリティプロセスのいずれかに移動しました。メッセージポートは、メインプロセスに負担をかけることなく、効率的な直接のプロセス間通信に使用されます。

Chromiumのコードキャッシングの調整

また、サンドボックスを有効にしてもパフォーマンスの低下が起こらないようにしたかったのです。私たちは、起動からエディターに点滅するカーソルが表示されるまでの時間を測定しました。その中で、V8 JavaScriptエンジンがメインのワークベンチスクリプト（約11.5MBの最小化されたコード）を読み込み、解析し、実行するのにかなりの時間が費やされていました。アップデートがインストールされない限り、起動のたびに同じスクリプトが読み込まれます。この動作を考慮すると、V8はコードキャッシングを使用して、次回より速く読み込めるように最適化されたバージョンのスクリプトをディスクに保存できます。

Chromium自体も、Webページの読み込み時間を短縮するためにコードキャッシングを使用しています。これは私たちのソリューションと同じV8エンジンの最適化をトリガーしますが、Chromiumの実装は、特定の期間に頻繁にアクセスされるWebページに対してのみ行われます。私たちのアプリケーションはWebページではなくデスクトップアプリケーションであるため、常にコードキャッシングを使用するソリューションが必要でした。

私たちは起動時にコードキャッシングを有効にしましたが、これはすぐに起動時間を改善するための最良の解決策となりました。残念ながら、私たちの解決策はNode.jsに依存しており、サンドボックス化されたレンダラープロセスでは適用できませんでした。

Electronでコードキャッシングオプションを公開することにより、bypassHeatCheckオプションを使用する際に、Chromiumで強制的にコードキャッシングをトリガーできます。さらに、ユーザーが新しいバージョンのVS Codeを実行していることを検出した場合に、以前に生成されたコードキャッシュを破棄することで、追加の保護層を加えました。

新しいElectron API: UtilityProcess

最後の、そしておそらく最も複雑なタスクは、拡張機能ホストをどこに移動させるかの解決策を見つけることでした。共有プロセスと同様に、通信はNode.jsソケットを介して実装されていました。ウィンドウごとに1つの拡張機能ホストプロセスがあり、拡張機能は必要なだけ子プロセスを自由に生成できます。

私たちは、ファイルウォッチャーや統合ターミナルのように拡張機能ホストを共有プロセスに移動させることも考えましたが、この機会を利用して、ホストとして隠しウィンドウを必要としない、より柔軟なものを構築すべきだと感じました。

そのために、サンドボックス化されたレンダラーで動作しつつ、現在の動作のほとんどを維持する、堅牢でスケーラブルなソリューションを求めていました。

• 子プロセスの生成をサポートする分離されたプロセス
• 完全なNode.jsサポート
• サンドボックス化されたプロセスとの直接IPCにメッセージポートを使用

当時、Electronはこれらの要件をサポートするAPIを提供していなかったため、私たちはElectronに新しいユーティリティプロセスAPIをコントリビュートしました。このAPIにより、拡張機能ホストをレンダラープロセスから、メインプロセスから作成されるユーティリティプロセスへと移動させることができました。メッセージポートを使用することで、メインプロセスがすべてのユーザー入力を処理するなど、他のプロセスに影響を与えることなく、レンダラーと拡張機能ホスト間で直接通信できます。

Electronのwebview要素からの移行

サンドボックスを有効にするために必ずしも必要ではありませんでしたが、この機会にVS CodeでのElectron webviewタグの使用を見直し、VS CodeがWebでどのように動作するかに、より密接に合わせるためにiframeタグに置き換えることにしました。どちらのタグも、ワークベンチが拡張機能からの信頼できないコードをホストし、そのコードの実行による影響からワークベンチを隔離できる点で似ています。たとえば、Markdownファイルのプレビューを開くと、その内容は組み込みのMarkdown拡張機能によって提供されるこのような要素内にレンダリングされます。

ほとんどの場合、webviewタグをiframeタグに置き換えるだけで済みました。しかし、iframeには1つの機能が欠けていました。それは、コンテンツ内のテキスト検索を実行し、ハイライトする機能です。この機能は、Markdownドキュメントをプレビューする際に検索をサポートするために不可欠でした。Chromium内部ではこの機能が実装されていましたが、Web APIとしてはエクスポートされていませんでした。私たちはElectronでAPIを公開するために必要な変更を行い、webview要素のすべての使用を廃止することができました。

レンダラープロセスの再利用の有効化

サンドボックス化されたレンダラープロセスのパフォーマンス上の利点の一つは、Electronにおけるそのライフサイクル挙動です。従来、レンダラープロセスは別のURLへのナビゲーションが発生するたびに終了し、再起動していました。VS Codeの場合、これはワークスペースを変更したりウィンドウをリロードしたりするたびにレンダラープロセスが再作成されることを意味し、一部の環境や設定では遅くなる可能性がありました。

サンドボックス化されたレンダラープロセスは、URLをナビゲートしても生存し続けます。別のワークスペースを開いたり、現在のワークスペースをリロードしたりするのが、より機敏になります。しかし、これが機能するためには、レンダラープロセスで実行されるネイティブNode.jsモジュールをコンテキストアウェアにする必要があります。サンドボックス化を有効にするために最終的にすべてのネイティブモジュールをレンダラープロセスから移動させましたが、それでも私たちは早期にレンダラープロセスの再利用をテストしたかったため、すべてのネイティブモジュールをコンテキストアウェアにしました。

すべてをまとめる

最後のステップは、ユーザー設定を介して条件付きでサンドボックスモードを有効にすることでした。すべてのユーザーに対してサンドボックスモードを有効にするのではなく、まずはInsiders版で検証する時間を設けたいと考えました。window.experimental.useSandbox設定により、サンドボックスはInsidersではデフォルトで有効になり、Stable版でも有効にできます。

私たちは実験インフラストラクチャを使用して、2023年初頭にStable版へのサンドボックス有効化を段階的に展開する予定です。これにより、問題がないか確認しながら、ユーザー数を増やしてサンドボックスモードをテストおよび検証することができます。

実験段階が終了すると、サンドボックスモードはすべてのユーザーでデフォルトで有効になり、非サンドボックスモードは削除されます。後のイテレーションで計画されている作業もまだ残っています。例えば、共有プロセスは隠しウィンドウであり、必要以上にリソースを使用するため、ユーティリティプロセスに変換したいと考えています。

これは、VS Codeチーム全体の助けとモチベーションがあってこそ可能だった素晴らしい旅でした。これらの変更を段階的にリリースし、プロセスサンドボックスを必要とする新しいElectronのバージョンに備えることができたのは素晴らしいことでした。私たちはプロセスアーキテクチャを大幅に改善し、Webモデルにより密接に連携させ、将来のための堅牢な基盤を築くことができました。

使用されている用語

Electronは、デスクトップ版VS Codeをサポートされているすべてのプラットフォーム（Windows、macOS、Linux）で実行可能にする主要なフレームワークです。これは、ChromiumとブラウザーAPI、V8 JavaScriptエンジン、Node.js API、さらにクロスプラットフォームのデスクトップアプリケーションを構築するためのプラットフォーム統合APIを組み合わせています。

このブログ記事では、Electronのプロセスサンドボックスを単に「サンドボックス」と呼びます。

Chromium、ひいてはElectronが提供するプロセスモデルを理解することは重要です。このブログ記事では、以下のプロセスを頻繁に参照します。

• メインプロセス - アプリケーションのメインエントリーポイント。
• レンダラープロセス - ユーザーが対話できるウィンドウ。

メインプロセスは常に1つですが、レンダラープロセスは開かれるウィンドウごとに作成されます。プロセスモデルの詳細については、Electronのプロセスモデルドキュメントおよび、このChrome Developersのブログ記事で詳しく知ることができます。

「共有プロセス」はElectronに特有のものではなく、VS Codeの実装詳細です。これはNode.jsが有効化された隠されたElectronウィンドウであり、他のすべてのウィンドウが拡張機能のインストールなどの複雑なタスクを実行するために通信できます。

「拡張機能ホスト」は、インストールされたすべての拡張機能をレンダラープロセスから隔離して実行するプロセスです。開かれたウィンドウごとに1つの拡張機能ホストが存在します。

VS Codeの「ワークベンチ」ウィンドウは、ユーザーがファイルの編集、検索、デバッグなどを行うために操作するメインウィンドウです。このブログ記事では、単に「ワークベンチ」と呼びます。他のウィンドウには、ヘルプメニューからアクセスできるプロセスエクスプローラーと問題報告があります。

私たちは「IPC」という用語をプロセス間通信を指すために使用します。IPCは、あるプロセスが別のプロセスと通信するための方法です。

私たちは「Insiders」と呼ばれるVS Codeのナイトリーバージョンをリリースし、一部のユーザーで最新の変更をテストしています。VS Codeチームの全員がInsiders版を使用しており、皆さんもぜひ試してみて、問題があれば報告していただければ幸いです。

ハッピーコーディング！

Benjamin Pasero、@BenjaminPasero