セキュリティ対策サマリー

July 28, 2026 · View on GitHub

この文書では、TeX Workspace Secure で実施した主なセキュリティ対策と、それによって抑えようとしているリスクをまとめています。

このセキュアビルドは、上流版との幅広い機能互換を保つことを目的としていません。企業での TeX 編集とビルドに必要な機能に絞り込み、より小さく、監査しやすい拡張にすることを目指しています。

以下のスコアは、この拡張の脅威モデルに合わせた CVSS 風の優先度の目安です。公式の CVSS スコアではありません。

これらの対策は、リスクを下げることを目的としたものであり、安全性を保証するものではありません。導入先での検証、配備判断、運用、インシデント対応の責任は、利用者側にあります。

主なリスクと対策

1. 共同編集機能とネットワーク経由の実行機能を削減

CVSS 風スコア: 7.4 / 10

リスク:

  • ネットワーク通信やメッセージ処理を伴う機能が増えると、文書の解析処理や webview、通信処理まわりの不具合が、セキュリティ上の問題になりやすくなります。
  • 内部プレビューの仕組みがあると、信頼しなければならない実装範囲が、編集とコンパイルの中核部分を超えて広がります。
  • 共同編集やプレビュー機能があると、ワークスペース内の内容をきっかけに、拡張が高い権限で動いてしまう経路が増えます。

対策:

このセキュアビルドでは、Live Share 連携、内部 PDF プレビューサーバー、ブラウザベースのプレビュー機能、外部 PDF ビューア実行、外部 SyncTeX コマンド経路を無効化しました。その代わりに、ファイル再読み込みと forward/reverse SyncTeX を bundled webview 内で扱う、ローカルなタブ表示の最小 PDF ビューアだけを残しています。webview がローカルリソースとして参照できる範囲は、同梱アセットと選択した PDF のあるディレクトリに限定します。reverse SyncTeX が返したソースは、実ファイルパスを解決し、その PDF を所有するワークスペース内に留まることを確認できた場合だけ開きます。

また、Restricted Mode にも限定的に対応しています。Restricted Mode では、このローカルタブビューアとその再読み込みは利用できますが、ビルド、clean、kill、出力ディレクトリの表示は、ワークスペースを信頼するまで無効のままです。

ページ描画の自動回復は最大 2 回に制限します。既存のページ数とメモリの上限を維持し、プレビューサーバー、ネットワーク要求、外部ビューアへのフォールバックは追加しません。

2. ワークスペース起点の外部コマンド実行を抑制

CVSS 風スコア: 8.6 / 10

リスク:

  • リポジトリ側が、ビルド時に任意のローカルバイナリやシェル引数を実行するコマンドを定義したり、利用者をそこへ誘導したりできます。
  • チーム全体の設定同期やワークスペース設定のコピーにより、危険なコマンド実行パターンが見えにくいまま定着するおそれがあります。
  • 脅威モデルが「信頼できない文書を開く」から「文書の内容によって、信頼されたローカルプロセスが起動される」へと変わります。

対策:

このセキュアビルドでは、自動ビルドを無効化し、カスタムのビルドレシピとツールを無視し、外部ビルドコマンドも使わないようにしています。手動ビルドは固定の pdfLaTeX / LuaLaTeX 内部レシピだけに限定し、ワークスペースの内容や設定からビルドコマンド経路を切り替えられないようにしています。どちらの固定レシピも latexmk-no-shell-escape を渡し、TeX の \write18 によるコマンド実行も無効化します。

さらに、formatter や linter の補助コマンドに渡す引数についても、ワークスペーススコープの上書きは反映しないようにし、trusted workspace であってもコマンドラインの形を密かに変えられないようにしています。通常設定と言語別設定には同じ上書き防止ルールを適用します。

Restricted Mode では、外部 formatter、kpsewhich、native forward SyncTeX helper を起動しません。forward SyncTeX は bundled parser を使用します。

あわせて、セキュアな build と clean の経路では、ルート解決も固定の内部ポリシーで行い、常に解決済みの main root を対象に実行するようにしています。PDF 出力先と補助ファイルの配置先も、その root ファイルのディレクトリに固定し、ワークスペース設定による出力先の上書きは実行経路に反映しません。

3. セキュアビルドではマジックコメントを無効化

CVSS 風スコア: 7.7 / 10

リスク:

  • 文書側が、利用者の想定しない実行ファイルやビルド手順へ拡張を誘導できます。
  • 設定ファイルを確認していても、TeX コメントに埋め込まれた実行ファイル選択のロジックは見落としやすくなります。
  • コマンドの由来や責任の境界が、統制された環境では追いにくくなります。

対策:

TeX ソース内のコメントからルート、ツール、レシピの選択を変更できるマジックコメントを、このセキュアビルドでは無視するようにしています。%!TEX root や各種ビルド制御マジックコメントによって、セキュアな build/viewer フローの挙動が変わることはありません。

4. 必須ではないコマンドの入口を削減

CVSS 風スコア: 5.8 / 10

リスク:

  • 機能が増えるごとに、解析、プロセス起動、文書処理の実装を個別に見直し、保守する必要が生じます。
  • 利便機能は保存時やバックグラウンドで動作しやすく、利用者から見た挙動が分かりにくくなります。
  • 中核の編集・コンパイルに不要な機能へまでレビュー工数が分散します。

対策:

文字数カウント、数式プレビューパネル、自動 lint 実行など、中核機能に必須ではない利便機能を削除または無効化しています。texdoc と外部 formatter は trusted workspace を要求し、workspace スコープの実行ファイル上書きをブロックします。texdoc は明示的なコマンドとしてのみ実行されます。

ルート解析、プロジェクト状態確認、依存関係レポート、ラベル改名、不足パスの Quick Fix は、プロジェクト内のファイルだけを対象とし、TeX や外部の補助プロセスを起動しません。改名やパス置換は、エディタ上で明示的に選択した場合だけ適用します。パス候補は、実ファイルパスが現在のワークスペース内に留まる、既存の同名ファイルに限定します。

5. vsls 固有の処理と古い互換コードを削減

CVSS 風スコア: 6.1 / 10

リスク:

  • 主機能を無効化したつもりでも、古いコード経路が到達可能なまま残ることがあります。
  • 複数機能をまたぐ互換ロジックは理解しづらく、レビューで見落とされやすくなります。

対策:

Live Share の URI 処理や、すでに無効化した共同編集機能、ブラウザビューア、外部ビューア処理のためだけに残っていた互換コードを削除しています。

6. 開発依存関係の状態を改善

CVSS 風スコア: 4.9 / 10

リスク:

  • 開発ツールチェーンの既知の問題が、ローカルのパッケージ作成、CI パイプライン、メンテナの作業環境に影響するおそれがあります。
  • 本番向けの依存関係が安定していても、保守の面で見たセキュリティ態勢は時間とともに劣化します。

対策:

開発依存関係を更新し、必要な箇所には個別の上書きを加えることで、ローカルでの監査結果を問題のない状態に保ちながら、リリース用ツールも動作するようにしています。native addon の guardrail は install script だけでなく N-API prebuild family も検出します。pdfjs-dist の optional Node.js canvas backend は個別にレビューし、browser 用 VSIX payload から .vscodeignore で除外されている場合に限って許可します。

この fork が目指すセキュリティ方針

TeX Workspace Secure は、企業利用で価値の高い次の機能を残すことを意図しています。

  • 編集支援
  • 補完とスニペット
  • ルートファイルの検出
  • ビルドの制御
  • ログ解析

不要な攻撃面を残してまで、上流版との機能の同等性を優先しない、という方針です。

この fork だけでは保証しないこと

  • 任意の TeX ツールチェーンそのものを安全にするものではありません。
  • ワークステーションの保護、サンドボックス化、企業ポリシーによる制御の代わりになるものではありません。
  • ホスト側に入っている LaTeX の実行ファイル、スクリプト、パッケージの検証を不要にするものではありません。
  • 将来の上流依存関係や変更が、常に無リスクであることを保証するものではありません。

推奨する運用前提

  • 承認済みの TeX ツールチェーンを使い、継続的にパッチを適用すること。
  • ワークスペース内のファイルはレビュー前提で扱い、初期状態では信頼しないこと。
  • ワークスペース側のコマンド設定変更より、中央管理された設定を優先すること。
  • Restricted Mode は確認作業のための状態と考え、閲覧や編集支援だけを使い、build、clean、kill、出力ディレクトリ表示は信頼付与後にだけ有効化すること。
  • プレビューサーバー、ブラウザビューア、共同編集機能、自動プロセス実行を再導入する変更は、個別に再評価すること。