Vertrauen in Arbeitsbereiche
6. Juli 2021 von Chris Dias, @chrisdias
Kann ich mir selbst vertrauen? Dies ist die existenzielle Frage, mit der sich viele Benutzer von Visual Studio Code seit dem Update 1.57 auseinandersetzen.
Wir können diese Frage zwar nicht für Sie beantworten, aber wir können Ihnen mehr darüber erzählen, warum wir das Konzept des Workspace Trust eingeführt haben.
Aber zuerst ein wenig Hintergrund.
Katzen und Tastaturen und schlechte Äpfel
Das Internet ist voller schöner Dinge, wie Videos von Katzen, die auf Tastaturen tippen.
Für Entwickler ist es auch voller Werkzeuge, Pakete und Open Source, die von guten Leuten erstellt wurden, die Ihnen helfen wollen, das Problem zu lösen, an dem Sie stundenlang gearbeitet haben. Entwicklungswerkzeuge wie VS Code integrieren Paketmanager, Code-Linters, Task-Runner, Bundler usw., um angenehme Erfahrungen zu bieten, die die Kraft der neuesten und besten Fortschritte aus der sich ständig weiterentwickelnden Community nutzen.
Die Produktivität, die dieses reiche Ökosystem bietet, ist jedoch oft das Ergebnis des breiten Zugangs, den wir unseren Entwicklungsmaschinen gewähren. Kombiniert man dies mit der rasanten Entwicklung und der viralen Verbreitung und dem Konsum, sind Entwicklerwerkzeuge ein attraktives Ziel für Ausnutzung, insbesondere wenn man bedenkt, dass Angreifer unsere Maschinen nutzen können, um weitere Angriffe zu verbreiten (z. B. über Authentifizierungstoken, die auf Entwicklermaschinen gespeichert sind, oder sogar über die vom Entwickler erstellte Software).
Entwickler zu sein ist lohnend, aber es ist auch ein riskantes Geschäft. Um zu einem Projekt beizutragen, müssen Sie seinen Autoren inhärent vertrauen, da Aktivitäten wie das Ausführen von npm install oder make, das Erstellen eines Java- oder C#-Projekts, automatisiertes Testen oder Debugging bedeuten, dass Code aus dem Projekt auf Ihrem Computer ausgeführt wird.
Unser Ziel mit der Funktion Workspace Trust ist es, die richtige Balance zu finden, um die wenigen "schlechten Äpfel" abzuwehren, die es allen verderben wollen, und gleichzeitig sicherzustellen, dass wir all die schönen Dinge haben können, die die Entwicklung so unterhaltsam machen.
Hey, das ist nur ein Editor, oder?
Ja, VS Code ist ein Editor. Wie die meisten modernen Editoren kann er jedoch Code aus dem Arbeitsbereich auf Ihre Veranlassung ausführen, um eine reichhaltigere Entwicklungsumgebung zu bieten.
Das Ausführen und Debuggen von Code ist ein offensichtliches Beispiel. Codeausführung, die möglicherweise nicht so offensichtlich ist, könnte die preLaunchTask sein, die vor dem Starten der App ausgeführt wird und einen Build ausführen kann, der eine zusätzliche Aufgabe hat, die beliebigen, nicht mit dem Build zusammenhängenden Code ausführt. Was ist mit dem npm-Modul, das Ihre Krypto-Wallet-Privatschlüssel stiehlt? Machen Sie eine einfache Bearbeitung und ein bösartiger Linter wird aus dem node_modules-Ordner geladen, anstatt dem global installierten. Selbst das Lesen des Codes kann täuschend sein, Angreifer können Unicode-Hacks verwenden, um bösartigen Code im Klartext zu verstecken. Heck, Sie müssen nicht einmal Quellcode öffnen um kompromittiert zu werden.
Die Absicht ist hier nicht, Sie von all den großartigen Tools da draußen (einschließlich VS Code) abzuschrecken oder Sie zu einem Berufswechsel zu bewegen. Es geht darum, Bewusstsein dafür zu schaffen, dass es viele Angriffsmöglichkeiten gibt, wenn Sie Code aus dem Internet herunterladen, der von einer Person oder Organisation geschrieben wurde, zu der Sie keine Vertrauensbeziehung haben.
Whack-a-Mole
In all den oben genannten Szenarien funktionieren die Tools wie vorgesehen und in nicht bösartigen Codebasen sind sie äußerst produktiv. Das Einrichten einer preLaunchTask zum Erstellen der App vor dem Debugging ist eine großartige Zeitersparnis, da Sie sie nach jeder Änderung nicht mehr manuell über das Terminal erstellen müssen. Linter sind hochgradig anpassbar, um die bevorzugten Kodierungsrichtlinien und Stile jedes Teams zu unterstützen (ja, Tabs vs. Leerzeichen). Pre-Commit-Hooks lassen Sie überprüfen, ob Sie etwas vergessen haben, oder stellen Sie sicher, dass Tests vor dem Commit ausgeführt werden.
Es ist unwahrscheinlich, dass Sie gleichzeitig allen diesen Angriffen ausgesetzt wären. Tatsächlich gab es (noch) keine Ausnutzung durch VS Code, da es eine großartige Community von Experten gibt, die uns auf neue Möglichkeiten aufmerksam machen. Unser Ansatz vor Workspace Trust bestand darin, jedes Szenario an der Schwachstelle mit einer lokalisierten Berechtigungsaufforderung anzugehen.
Zum Beispiel warnte die Jupyter-Erweiterung Benutzer, dass eingebettete JavaScript ausgeführt werden kann, wenn Sie die Visualisierungen in einem Notebook öffnen.
Die ESLint-Schwachstelle war eine Doozy, weil sie beim Laden des Arbeitsbereichs ausgeführt wird (dies war unser erstes modales Dialogfeld).
Dies erweist sich als ein aussichtsloser Kampf. Benutzer werden mit mehreren (und leicht unterschiedlichen) Berechtigungsaufforderungen unterbrochen, die nicht für den gesamten Arbeitsbereich gelten. *Ich vertraue dir, dir, dir, dir, dir nicht, und dir, aber nur dienstags*. Für uns ist es ein ständiges Spiel von Whack-a-Mole, bei dem jede Schwachstelle, sobald sie aufgedeckt wird, mit einer weiteren Aufforderung behoben wird.
Eines der Muster, dem wir bei der Entwicklung von VS Code folgen, ist es, Erfahrungen zu betrachten, die im Tool und in den Erweiterungen ähnlich, aber inkonsistent implementiert werden, und zu sehen, ob wir sie in den Kern integrieren können. Die Vertrauensabfrage folgte diesem Muster, daher beschlossen wir, eine Erfahrung und eine API zu entwickeln, die sowohl das Tool als auch die Erweiterungen nutzen könnten, mit einer (hoffentlich) klareren Benutzererfahrung.
Vertrauen
Jetzt, da Sie einige der verschiedenen Möglichkeiten verstehen, wie Code ausgeführt werden kann, ohne dass Sie es wissen, haben Sie hoffentlich eine bessere Vorstellung davon, warum wir diese Frage im Voraus stellen.
Wir fragen ausdrücklich, ob Sie den Autoren dieses Arbeitsbereichs vertrauen, denn VS Code kann nicht erkennen, ob der Code bösartig ist oder nicht (hey, wir kennen nur 1en und 0en), woher er stammt, ob Sie beabsichtigen, zum Projekt beizutragen, usw.
Sie hingegen sind schlau und wissen, woher der Code stammt: Sie (*ok*), Ihr Unternehmen (*wahrscheinlich ok*), Ihr Kumpel Kai (*abhängig*), oder eine zufällige Person im Internet (*auf keinen Fall*).
Diese Kenntnisse helfen, das Werkzeug intelligenter zu machen. Wenn Sie dem Autor vertrauen, großartig! Die Werkzeuge und Erweiterungen erhalten grünes Licht, um ihre Arbeit zu tun und eine magische Erfahrung zu bieten, und wir werden Sie nicht wieder belästigen.
Wenn nicht, sagen Sie uns damit: Sei vorsichtig, VS Code, führe keinen Code aus. Das nennen wir Eingeschränkter Modus, bei dem potenziell schädliche Funktionen deaktiviert sind, damit Sie den Code sicherer durchsuchen und schließlich eine fundierte Entscheidung treffen können.
Aber dieses Dialogfeld!
Wir hören Sie, das modale Dialogfeld ist ziemlich groß und taucht bei jedem neuen Ordner, den Sie öffnen, immer wieder auf, es sei denn, Sie ergreifen Maßnahmen zur Konfiguration.
Dieses Design hatten wir nicht von Anfang an. Wir haben uns die ESLint-Dialogsaga angesehen und uns gefragt, ob wir eine nicht-blockierende Erfahrung mit visuellen Hinweisen und einer einzigen Benachrichtigungsaufforderung, die so lange wie möglich verzögert wird, bereitstellen könnten. Wir wollten unauffällig sein, im eingeschränkten Modus starten (ohne dass Sie es wirklich bemerken) und im letzten Moment nach Vertrauen fragen.
Wir haben eine "passive" Vertrauensbenachrichtigung eingeführt, mit der Sie uns mitteilen konnten, ob Sie dem Arbeitsbereich vertrauen. Wir haben verschiedene UI-Behandlungen durchlaufen, um zu signalisieren, dass der Arbeitsbereich nicht vertrauenswürdig war, einschließlich der Ergänzung des Einstellungen-Zahnrad-Symbols und der Einführung eines neuen Sicherheitssymbols.
Wenn Sie die Insiders-Builds verwenden, erhalten Sie die neuesten Iterationen neuer Erfahrungen in VS Code, so wie wir über Workspace Trust sprechen. Insiders wird täglich veröffentlicht und wir nutzen es, um VS Code zu entwickeln.
Die Idee ist, dass ein Benutzer (Sie!) entscheiden kann, zu Ihren Bedingungen, wann er dem Arbeitsbereich Vertrauen gewährt oder verweigert. Wenn das Tool oder eine Erweiterung wirklich Zugriff benötigte, würden wir dann eine Benachrichtigung anzeigen, ob Sie dem Arbeitsbereich vertrauen.
Ich bin sicher, viele von Ihnen werden zustimmen, dass VS Code unter etwas leidet, das wir "Benachrichtigungsmüdigkeit" nennen (ich verspreche, wir arbeiten daran 😊). In unseren Tests haben wir gesehen, dass die Leute die Benachrichtigung einfach ignorierten. Benutzer sahen die Benachrichtigung weder am Zahnrad noch an den neuen Sicherheitssymbolen. Nutzungsdaten zeigten eine sehr geringe Rate der Vertrauensgewährung über die passive Benachrichtigung. In Benutzerstudien beobachteten wir, wie die Leute ihre gesamte Zeit damit verbrachten, zu denken, sie hätten etwas kaputt gemacht, und dann Zeit mit der Fehlersuche verbrachten, um zu ihrem erwarteten Zustand zurückzukehren.
Wir beabsichtigten, unauffällig zu sein und so lange wie möglich zu verzögern, aber die Realität war, dass das Produkt im eingeschränkten Modus fehlerhaft wirkte und die Leute dachten, es sei ihre Schuld. Weder für uns noch für Sie ein guter Zustand.
Sie ins Boot holen
Die Entscheidung, einem Ordner zu vertrauen, hat grundlegende Auswirkungen auf die Fähigkeiten von VS Code. Daher haben wir nach all der Forschung entschieden, dass es richtig ist, die Vertrauensfrage sofort zu stellen, wenn Sie versuchen, einen Ordner zu öffnen. Da das modale Dialogfeld störend ist, versuchen wir, die Dinge auszugleichen, indem wir das Dialogfeld leistungsfähig machen, damit Sie ein paar Fragen beantworten können und am Ende die Aufforderung im täglichen Gebrauch viel seltener sehen.
Durch unser eigenes Dogfooding sowie durch Interviews mit anderen Entwicklern haben wir festgestellt, dass die Leute im Allgemeinen einen primären Ordner haben, in dem sie alle ihre Quellen ablegen und diesen als vertrauenswürdig betrachten. Daher haben wir die Möglichkeit hinzugefügt, den übergeordneten Ordner direkt aus dem Dialogfeld zu vertrauen. Sie können ihm und allen Unterordnern mit einem Klick vertrauen und sehen dann die Vertrauensaufforderung nicht mehr.
Workspace Trust Editor
Der Workspace Trust Editor gibt Ihnen zusätzliche Kontrolle darüber, was Sie vertrauen, und wird in der Version 1.58 aktualisiert, um die Konfiguration der Funktion an Ihre Bedürfnisse anzupassen.
Und da Sie das Verhalten anpassen können, gibt es viele Möglichkeiten, zum Trust Editor zu gelangen 😊. Klicken Sie auf die Statusleistenmeldung Eingeschränkter Modus, den Link Verwalten im Banner des eingeschränkten Modus, das Zahnradmenü oder öffnen Sie die Befehlspalette (F1) und verwenden Sie den Befehl Arbeitsbereiche: Arbeitsbereich vertrauen verwalten.
Aus dem Workspace Trust Editor können Sie dem aktuellen Ordner, dem übergeordneten Ordner (und allen Unterordnern) sowie jedem Ordner auf dem Computer vertrauen.
Sie können auch schnell zu allen Workspace Trust-Einstellungen springen, um die Erfahrung zu optimieren.
Wie wir Workspace Trust verwenden
Niemand mag Zahnseide, aber wir tun es trotzdem, weil wir wissen, dass es richtig ist. Niemand möchte über Sicherheit nachdenken, aber wir wissen auch, dass es richtig ist. Indem Sie die Erfahrung anpassen, können Sie Ihre Entwicklungserfahrung angenehm gestalten und sich gleichzeitig vor den inhärenten Bedrohungen der Entwicklung schützen (Spaß beim Zahnseidebenutzen?!?).
Die meisten Leute im VS Code-Team beginnen mit einem Ordner auf oberster Ebene, in dem sie Quellen bearbeiten, denen sie vertrauen. Zum Beispiel lege ich auf meinem Mac alle Quellen, die ich von der Microsoft-Organisation auf GitHub herunterlade, in meinen ~/src-Ordner. Ich bezeichne ~/src als vertrauenswürdigen Ordner und alles darunter ist inhärent vertrauenswürdig. Wenn ich ~/src/vscode oder ~src/vscode-docker usw. öffne, werden sie mit vollem Vertrauen geöffnet, da ich dem Code vertraue, den meine Organisation schreibt und nutzt.
Ich habe einen separaten Ordner namens ~/scratch (kurz für "scratchpad", Sie können ihn natürlich beliebig benennen), in den ich alles andere lege und standardmäßig als nicht vertrauenswürdig annehme. Dann treffe ich Vertrauensentscheidungen Ordner für Ordner.
Um meinen Workflow zu erleichtern, habe ich die Einstellung "security.workspace.trust.startupPrompt" auf "never" gesetzt.
Mit dieser Einstellung werde ich nicht durch das modale Dialogfeld aufgefordert, und der Arbeitsbereich wird direkt im eingeschränkten Modus geöffnet. Ich habe bereits entschieden, dass der Ordner ~src/scratch nicht vertrauenswürdig ist, daher ist es nicht notwendig, mich jedes Mal aufzufordern, wenn ich einen Unterordner öffne. Wenn ich beschließe, dass ich dem Code, den ich lese oder schreibe, vertraue, kann ich ihn mit zwei schnellen Klicks für den Ordner aktivieren (die Benachrichtigung über den eingeschränkten Modus am oberen Rand von VS Code, dann die Schaltfläche "Vertrauen").
Auf meinem Windows-Rechner ist die Sache ein wenig interessanter. Ich arbeite im Allgemeinen in Ubuntu-Images, die unter dem Windows Subsystem for Linux (WSL) laufen, und verwende die WSL-Erweiterung. Ich vertraue den ~/src-Ordnern unter Linux und ich vertraue dem d:\src-Ordner unter Windows.
Einige Teammitglieder gehen noch einen Schritt weiter und schalten auch das Banner für den eingeschränkten Modus oben aus ("security.workspace.trust.banner": "never"), sodass nur die Statusleistenbenachrichtigung übrig bleibt. Für mich geht das zu weit, das Banner am oberen Rand hält mich ehrlich und hilft mir, wachsam zu bleiben, wenn ich aus dem Internet herunterlade.
Open Source ist fantastisch
Wir wissen, dass VS Code ein Werkzeug ist, das Sie für Ihre "echte" Arbeit verwenden, und jede Stolpersteine oder Hindernisse, die wir einführen, verlangsamen Sie nur beim Erstellen und Starten des nächsten Einhorns. Viele von Ihnen haben sich die Zeit genommen, sich auf Twitter, Reddit und in Issues zu melden, und wir danken Ihnen für Ihr offenes Feedback. Wir haben eine Reihe von Korrekturen und Verbesserungen für die Version 1.58 vorgenommen, die auf Ihren Eingaben basieren, und freuen uns darauf, das Gespräch fortzusetzen.
Mit Blick auf die Zukunft möchten wir Erweiterungsautoren helfen, die Ausführung von beliebigem Code zu vermeiden und mehr Funktionalität im eingeschränkten Modus bereitzustellen. Unsere Roadmap beschreibt die Arbeit, die wir mit dem Visual Studio Marketplace-Team leisten, um dem Erweiterungsökosystem zusätzliche Sicherheit zu verleihen (wir nennen dies "Trusted Extensions"), einschließlich validierter Publisher, Signierung und plattformspezifischer Erweiterungen. Kurz gesagt, Sie können Workspace Trust als Hilfe für gute Erweiterungen betrachten, gute Entscheidungen zu treffen. Trusted Extensions schützen Sie vor schlechten Erweiterungen.
Einer der Vorteile des offenen Aufbaus von VS Code ist, dass die Community uns helfen kann, die bestmöglichen Erfahrungen zu schaffen. Lassen Sie uns also bitte wissen, wie wir den Ablauf verbessern können, um Sie sicher zu halten und gleichzeitig so unauffällig wie möglich zu sein. Kommentieren Sie (höflich!) zu bestehenden Problemen, erstellen Sie ein neues Problem oder twittern Sie uns @code, wir hören zu!
Danke,
Chris und das VS Code-Team
Frohes Coden (sicher)!