ワークスペースの信頼
2021年7月6日 Chris Dias 著、@chrisdias
1.57 アップデート以降、多くの Visual Studio Code ユーザーが「自分自身を信頼できるか？」という実存的な疑問に直面しています。
その質問にお答えすることはできませんが、ワークスペースの信頼の概念を導入した理由について詳しく説明します。
まず、少し背景について説明します。
猫とキーボード、そして悪質なもの
インターネットは、猫がキーボードをタイプしている動画など、楽しいものでいっぱいです。
開発者にとって、インターネットは、何時間も取り組んできた問題を解決するために役立ちたいと考えている善良な人々によって構築されたツール、パッケージ、オープンソースでもいっぱいです。VS Code のような開発ツールは、パッケージ マネージャー、コード リンター、タスク ランナー、バンドラーなどを統合して、常に進化するコミュニティの最新かつ最高の進歩を活用した、楽しい体験を提供します。
しかし、この豊富なエコシステムによってもたらされる生産性は、多くの場合、開発マシンに提供する広範なアクセスによってもたらされます。急速な進化と口コミによる共有および消費と組み合わせることで、開発ツールは悪用の魅力的な標的となります。特に、攻撃者は開発者のマシンを使用して攻撃をさらに拡散できることを考えると (たとえば、開発者のマシンに保存されている認証トークンや、開発者が作成したソフトウェアを介して)。
開発者であることはやりがいがありますが、危険なビジネスでもあります。プロジェクトに貢献するには、本質的にその作成者を信頼する必要があります。なぜなら、npm install や make の実行、Java や C# プロジェクトのビルド、自動テスト、またはデバッグなどのアクティビティはすべて、プロジェクトからのコードがコンピューター上で実行されることを意味するからです。
ワークスペースの信頼機能の目標は、適切なバランスを見つけることです。誰もが楽しめるようにしたいと考えている少数の「悪質なもの」から身を守りながら、開発を非常に楽しいものにするすべての素晴らしいものを引き続き確実に利用できるようにすることです。
ねえ、ただのエディターでしょ？
はい、VS Code はエディターです。ただし、最新のエディターのほとんどと同様に、より豊かな開発体験を提供するために、ワークスペースからコードを実行できます。
コードの実行とデバッグは明らかな例です。それほど明白ではないコード実行は、アプリを起動する前に実行される preLaunchTask である可能性があります。これは、ビルドとは関係のない任意のコードを実行する追加タスクを持つビルドを実行できます。暗号ウォレットの秘密キーを盗む npm モジュールはどうでしょうか？単純な編集を行うと、グローバルにインストールされているリンターではなく、悪意のあるリンターが node_modules フォルダーからロードされます。コードを読むことさえ欺瞞的である可能性があります。攻撃者は Unicode ハックを使用して、悪意のあるコードを平然と隠すことができます。まったくソースコードを開く必要さえなく所有されることさえあります。
ここでの意図は、(VS Code を含む) すべての優れたツールから遠ざけたり、キャリアを変更させたりすることではありません。インターネットから、信頼関係のない個人または組織によって書かれたコードをダウンロードする場合、多くの攻撃機会があるという認識を高めることです。
モグラ叩き
上記のすべてのシナリオで、ツールは設計どおりに機能しており、悪意のないコードベースでは、非常に生産的です。デバッグ前にアプリをビルドするように preLaunchTask を設定することは、変更を加えるたびにターミナルから手動でビルドする必要がないため、大幅な時間節約になります。リンターは、すべてのチームが好むコーディング ガイドラインとスタイル (はい、タブ vs スペース) をサポートするように高度にカスタマイズできます。プリコミット フックを使用すると、何かを忘れていないか、またはコミットする前にテストが実行されていることを確認できます。
さて、これらの攻撃すべてに同時にさらされる可能性は低いでしょう。実際、VS Code を介したエクスプロイトは (まだ) ありません。なぜなら、新しい機会が発生したときに私たちに気づかせてくれる専門家の素晴らしいコミュニティがあるからです。ワークスペースの信頼の前のアプローチは、脆弱性の時点でローカライズされた許可プロンプトで各シナリオに対処することでした。
たとえば、Jupyter 拡張機能は、ノートブックでビジュアライザーを開くと埋め込まれた JavaScript が実行される可能性があることをユーザーに警告しました。
ESLint の脆弱性は、ワークスペースがロードされたときに実行されるため、厄介なものでした (これが最初のモーダル ダイアログでした)。
これは、結局のところ、負け戦であることが判明しました。ユーザーは、ワークスペース全体に適用されない複数の (そしてわずかに異なる) 許可プロンプトによって中断されます。あなた、あなた、あなた、あなた、あなたではなく、あなた、ただし火曜日のみ信頼します。私たちにとって、それはモグラ叩きの絶え間ないゲームであり、脆弱性が露呈するたびに別のプロンプトでそれを塞ぎます。
そのため、VS Code を構築する際に従うパターンの 1 つは、ツールと拡張機能全体で同様に実装されているが、一貫性のないエクスペリエンスを見て、それをコアに取り込むことができるかどうかを確認することです。信頼プロンプトはこのパターンに従ったため、ツールと拡張機能の両方が利用できるエクスペリエンスと API を構築し、(うまくいけば) より明確なユーザー エクスペリエンスを実現することにしました。
信頼
さまざまな方法でコードが知らず知らずのうちに実行される可能性があることを理解できたので、なぜ最初にこの質問をしているのかについて、より良いアイデアが浮かんだのではないでしょうか。
VS Code はコードが悪意のあるものかどうか (ねえ、1 と 0 しか知らないんだ)、どこから来たのか、プロジェクトに貢献するつもりがあるかどうかなどを判断できないため、このワークスペースの作成者を信頼するかどうかを具体的に尋ねます。
一方、あなたは賢く、コードがどこから来たのかを知っています。あなた (オーケー)、あなたの会社 (おそらくオーケー)、あなたの友人カイ (場合による)、またはインターネット上の見知らぬ人 (間違いなくダメ)。
その知識は、ツールをよりスマートにするのに役立ちます。作成者を信頼している場合は、素晴らしいです！ツールと拡張機能は、魔法のような体験を提供するために自由に実行でき、二度とあなたを悩ませることはありません。
信頼していない場合は、VS Code に注意してください、コードを実行しないでくださいと伝えています。これが 制限付きモード と呼ばれるもので、潜在的に有害な機能が無効になっているため、より安全にコードを閲覧し、最終的には情報に基づいた決定を下すことができます。
でも、あのダイアログ！
モーダル ダイアログはかなり大きく、構成するためのアクションを実行しない限り、開く新しいフォルダーごとに表示され続けることは承知しています。
私たちはこの設計から始めたわけではありません。ESLint モーダル ダイアログの物語を見て、視覚的な手がかりと可能な限り遅延された単一の通知プロンプトを使用して、非ブロッキング エクスペリエンスを提供できるかどうかを自問しました。私たちは、目立たず、(本当に気づかないうちに) 制限付きモードで開始し、最後の瞬間に信頼を求めるようにしたかったのです。
ワークスペースを信頼するかどうかを知らせることができる「パッシブ」信頼通知を導入しました。設定ギア アイコンを拡張したり、新しいセキュリティ アイコンを導入したりするなど、ワークスペースが信頼されていないことを示すために、さまざまな UI 処理を繰り返しました。
Insiders ビルドを使用している場合は、ワークスペースの信頼について話しているように、VS Code の新しいエクスペリエンスに関する最新の反復処理を入手できます。Insiders は毎日出荷され、VS Code を構築するために使用しています。
ユーザー (あなた!) が、ワークスペースの信頼を許可または拒否するタイミングを自分の条件で決定できるようにするというアイデアです。ツールまたは拡張機能が本当にアクセスを必要とする場合にのみ、ワークスペースを信頼するかどうかを尋ねる通知が表示されます。
さて、多くの人が同意してくれると思いますが、VS Code は、いわゆる「通知疲れ」に少し苦しんでいます (改善に取り組んでいることを約束します 😊)。私たちのテストでは、人々は単に通知を無視していることがわかりました。ユーザーは、ギアや新しいセキュリティ アイコンの通知を見ていませんでした。使用状況データは、パッシブ通知による信頼の付与率が非常に低いことを示していました。ユーザー調査では、人々が何かを壊してしまったと思い込み、トラブルシューティングに時間を費やして、期待される状態に戻ろうとしているのを見ました。
私たちは目立たず、可能な限り遅延させることを意図していましたが、実際には、制限付きモードでは、製品が壊れているように感じられ、人々は自分のせいだと思っていました。私たちにとっても、どちらにとっても良い状況ではありません。
ユーザーによる制御
フォルダーを信頼するかどうかの決定は、VS Code の機能に根本的な影響を与えるため、すべての調査の後、フォルダーを開こうとしたときにすぐに信頼の質問をすることが正しいと判断しました。モーダル ダイアログは邪魔になるため、いくつかの質問に答えて、最終的には日々の作業でプロンプトが表示される頻度を大幅に減らすことができるように、ダイアログを強力にすることでバランスを取ろうとしています。
私たち自身のドッグフーディングや他の開発者とのインタビューを通じて、人々は通常、すべてのソースを配置するプライマリ フォルダーを持っており、それを信頼できると考えていることがわかりました。したがって、ダイアログから直接親フォルダーを信頼する機能を追加しました。それを信頼すると、すべてのサブフォルダーもワンクリックで信頼され、信頼プロンプトが二度と表示されなくなります。
ワークスペースの信頼エディター
ワークスペースの信頼エディターは、信頼するものをさらに制御できるようにし、ニーズに合わせて機能を構成しやすくするために 1.58 リリースで更新される予定です。
また、動作をカスタマイズできるため、信頼エディターにアクセスする方法はたくさんあります 😊。制限付きモード ステータス バー メッセージ、制限付きモード バナーの 管理 リンク、ギア メニューをクリックするか、コマンド パレット (F1) を開き、ワークスペース: ワークスペースの信頼の管理 コマンドを使用します。
ワークスペースの信頼エディターから、現在のフォルダー、親フォルダー (およびすべてのサブフォルダー)、およびマシン上の任意のフォルダーを信頼できます。
また、すべてのワークスペースの信頼設定にすばやくジャンプして、エクスペリエンスを微調整することもできます。
ワークスペースの信頼の利用方法
歯をフロスするのは誰もが好きではありませんが、正しいことだとわかっているので、とにかく行います。セキュリティについて考えたい人もいませんが、正しいことだとわかっています。エクスペリエンスをカスタマイズすることで、開発エクスペリエンスを楽しいものに保ちながら、開発に内在する脅威から身を守ることもできます (楽しいフロス?!?)。
VS Code チームのほとんどの人は、信頼するソースに取り組むトップレベル フォルダーから始めます。たとえば、私の Mac では、GitHub の Microsoft 組織からプルするすべてのソースを ~/src フォルダーに配置します。~/src を信頼できるフォルダーとして指定すると、その下のすべてが本質的に信頼されます。~/src/vscode や ~src/vscode-docker などを開くと、組織が記述および消費するコードを信頼しているため、完全に信頼された状態で開かれます。
~/scratch (「scratchpad」の略、明らかに好きなものにすることができます) という別のフォルダーがあり、その他すべてを配置し、デフォルトで信頼されていないと想定しています。次に、フォルダーごとに信頼の決定を行います。
ワークフローをスムーズにするために、"security.workspace.trust.startupPrompt" 設定を "never" に設定しています。
この設定では、モーダル ダイアログによってプロンプトが表示されず、ワークスペースは制限付きモードで直接開きます。~src/scratch フォルダーは信頼されていないとすでに判断しているため、サブフォルダーを開くたびにプロンプトを表示する必要はありません。読んだり書いたりしているコードを信頼すると判断した場合は、2 回のクイック クリック (VS Code の上部にある制限付きモード通知、次に信頼ボタン) でフォルダーで有効にできます。
Windows マシンでは、状況が少し面白くなります。通常、Windows Subsystem for Linux (WSL) で実行されている Ubuntu イメージで作業し、WSL 拡張機能を使用しています。Linux の ~/src フォルダーと、Windows 側の d:\src フォルダーを信頼しています。
チームの一部の人はさらに一歩進んで、上部の制限付きモード バナーもオフにします ("security.workspace.trust.banner": "never")。ステータス バー通知のみを残します。私にとっては、これはやりすぎです。上部のバナーは私を正直に保ち、インターネットからプルしているときに警戒することを思い出させてくれます。
オープンソースは素晴らしい
VS Code は「実際の」ジョブを完了するために使用するツールであり、導入する速度低下や障害は、次のユニコーンの構築と立ち上げを遅らせるだけであることを認識しています。多くの方が Twitter、Reddit、および Issues でご連絡をいただき、率直なフィードバックに感謝いたします。皆様のご意見に基づいて、1.58 リリースで提供される修正と改善を多数行いました。今後ともご意見をお待ちしております。
今後を見据えて、拡張機能の作成者が任意のコード実行を回避し、制限付きモードで実行する場合により多くの機能を提供できるように支援したいと考えています。当社のロードマップには、拡張機能エコシステムに追加のセキュリティをもたらすために Visual Studio Marketplace チームと協力して行っている作業 (これを「信頼済み拡張機能」と呼んでいます) が記載されています。これには、検証済みの発行元、署名、およびプラットフォーム固有の拡張機能が含まれます。簡単に言えば、ワークスペースの信頼は、優れた拡張機能が適切な決定を下すのを支援すると考えることができます。信頼済み拡張機能は、悪質な拡張機能から保護するのに役立ちます。
VS Code をオープンに構築することの利点の 1 つは、コミュニティが可能な限り最高のエクスペリエンスを作成するのに役立つことです。そのため、可能な限り目立たず、安全を確保しながら、フローをどのように改善できるかをお知らせください。既存の Issue にコメント (丁寧に!) したり、新しい Issue を送信したり、@code にツイートしてください。お待ちしております！
ありがとうございます。
Chris と VS Code チームより
安全にコーディングを楽しみましょう！