Grundlegendes zu Dateisystemrichtlinien für lokale Sandboxing in GitHub Copilot-CLI

Wenn lokale Sandboxing aktiviert ist, Copilot CLI führt jeder Sandkastenprozess oder -vorgang unter einer Dateisystemrichtlinie aus, die steuert, welche Dateien und Verzeichnisse sie lesen und schreiben können. Erfahren Sie, wie diese Richtlinie erstellt wird und wie Sie den gewährten Zugriff überprüfen.

In diesem Artikel

Hinweis

Lokale Sandkasten sind GitHub Copilot in Öffentliche Vorschau und können geändert werden.

Wichtig

Für lokale Sandboxing auf Windows ist ein Windows Insider-Build erforderlich.

Einführung

Wenn Sie die lokale Sandkastenumgebung aktivieren, führen Sie die Befehle aus, Copilot CLI die sie in Ihrem Auftrag innerhalb einer Betriebssystem-Sandbox aufruft. Der Sandkasten erzwingt eine Dateisystemrichtlinie: eine Reihe von Regeln, die entscheiden, welche Pfade ein Sandkastenprozess oder -vorgang lesen kann, den er schreiben kann und welche er überhaupt nicht berühren kann.

Die meisten dieser Richtlinien werden automatisch zusammengestellt, sodass alltägliche Befehle ohne Setup funktionieren. In diesem Artikel wird erläutert, wie Copilot die Richtlinie eintrifft und wie Sie den Zugriff überprüfen, der in einem bestimmten Verzeichnis gewährt wird.

Eine Übersicht über das lokale Sandkastening, einschließlich der Aktivierung und De-De-Funktion, finden Sie unter Informationen zu Cloud- und lokalen Sandboxes für GitHub Copilot und Verwenden der lokalen Sandkastenumgebung.

Was die Richtlinie betrifft

Die Dateisystemrichtlinie deckt die Aufgaben Copilot in Ihrem Auftrag ab, wird jedoch je nach Art der Arbeit auf unterschiedliche Weise erzwungen:

  • Shellbefehle und integrierte Suchvorgänge werden als untergeordnete Sandkastenprozesse ausgeführt, sodass das Betriebssystem die Richtlinie direkt erzwingt. Die grep Und glob Tools führen z. B. Ripgrep als sandkastenbasierten untergeordneten Prozess aus.
  • Lokale MCP- und Sprachserverprozesse (LSP) können auch innerhalb der Sandbox ausgeführt werden, sodass das Betriebssystem auch die Richtlinie erzwingt.
  • Integrierte Dateilese- und Dateibearbeitungstools werden als Teil von Copilot CLI sich selbst und nicht als sandkastenbasierter untergeordneter Prozess ausgeführt. Sie überprüfen die gleiche Dateisystemrichtlinie vor dem Lesen oder Schreiben einer Datei, aber da die Betriebssystem-Sandbox diese Vorgänge nie sieht, ist die Prüfung ein nur softwarebasierter Schutz anstelle eines vom Betriebssystem erzwungenen Betriebssystems.
  • Remote-MCP-Server werden außerhalb Ihres Computers ausgeführt, daher gibt es keinen lokalen untergeordneten Prozess zum Sandkasten, und die Dateisystemrichtlinie schränkt sie nicht ein.
  • Subagenten wirken nicht direkt; sie orchestrieren andere Tools. Ob die Richtlinie gilt und wie, hängt vom Tool ab, das ein Subagent aufruft.

Ein Sandkastenprozess wird daher durch das Betriebssystem eingeschränkt, während ein Prozessvorgang dieselbe Richtlinie in der Software erzwingt. Deshalb bezieht sich dieser Artikel auf einen Sandkastenprozess oder -vorgang und nicht nur auf Befehle.

Berechtigungsstufen

Der Sandkasten ist standardmäßig verweigert: Es sei denn, ein Pfad wird explizit erteilt, ein Befehl kann ihn nicht verwenden. Jeder Pfad in der Richtlinie verfügt über eine von drei Berechtigungsstufen:

  • Lese-/Schreibzugriff – der Befehl kann Dateien in diesem Pfad lesen und ändern.
  • Schreibgeschützt – der Befehl kann Dateien in diesem Pfad lesen, aber nicht ändern.
  • Verweigert – der Befehl kann diesen Pfad nicht lesen oder schreiben, auch wenn eine breitere Regel dies andernfalls zulassen würde.

Da der Zugriff verweigert wird, es sei denn, der Zugriff verweigert wird, müssen Sie einem Befehl alles gewähren, Copilot was es legitim benötigt – Ihre Projektdateien, die ausgeführten Tools und unterstützende Speicherorte wie temporäre Verzeichnisse – und alles andere außer Grenzen halten.

Hinweis

Diese Berechtigungsstufen gelten für jeden Sandkastenprozess oder -vorgang, aber sie werden anders erzwungen: Für Sandkasten-untergeordnete Prozesse erzwingt das Betriebssystem sie direkt, während die eigenen integrierten Dateilese- und Dateibearbeitungstools die gleichen Ebenen in der Software überprüfen, ohne dass ein Betriebssystem-Backstop vorhanden ist.

Erstellen der Richtlinie

Bevor jeder Sandkastenprozess gestartet wird, Copilot CLI wird die effektive Richtlinie für diesen Prozess mithilfe des aktuellen Arbeitsverzeichnisses, der Umgebung, der Einstellungen und der automatischen Gewährung aufgelöst. Dadurch wird der Prozess nur auf den benötigten Zugriff beschränkt und bedeutet, dass Sie diese gemeinsamen Speicherorte nicht selbst verwalten müssen.

Ihr Arbeitsverzeichnis

Wenn "Arbeitsverzeichnis einschließen " in den Dateisystemeinstellungen für die lokale Sandkastenumgebung ( wie standardmäßig ) aktiviert ist, wird dem aktuellen Arbeitsverzeichnis Lese-/Schreibzugriff gewährt. Fügt in einem Git-Repository Copilot auch die zugehörigen Git-Zuschüsse hinzu. Wenn Sie diese Einstellung deaktivieren, werden alle diese automatischen Zuschüsse unterdrückt, sodass Sie Zulassungsregeln für die erforderlichen Projekt- und Git-Pfade manuell hinzufügen müssen. Siehe Konfigurieren lokaler Sandkasteneinstellungen.

Hinweis

Wenn Sie von einer unternehmenseigenen Organisation stammen Copilot , kann ein Administrator die Einstellung " Arbeitsverzeichnis einschließen" deaktivieren und sperren, sodass Sie sie nicht wieder aktivieren können. Siehe Unternehmensverwaltete Einstellungen.

Tools auf Ihrem PATH

Zum Ausführen eines Programms wie python oder git, muss der Sandkasten den Befehl das Verzeichnis anzeigen lassen, in dem sich das Programm befindet. Die PATH Umgebungsvariable listet diese Verzeichnisse auf und Copilot gewährt ihnen schreibgeschützten Zugriff, zusammen mit Verzeichnissen, die von verwandten Toolvariablen wie GOPATH, und CARGO_HOME``PYTHONPATH. Schreibgeschützt ist die richtige Ebene für externe Tools: Ein Befehl muss ausgeführt gitwerden, nicht ändern. Die vollständige Liste der Umgebungsvariablen und der PATH Umgebungsvariablen, die der Sandkasten überprüft, und die Interpretation der einzelnen Variablen finden Sie unter GitHub Copilot CLI-Befehlsreferenz.

System- und Profilspeicherorte

Standardsystemspeicherorte und Ihr Benutzerprofilverzeichnis (Home) werden schreibgeschützt gewährt, sodass Befehle Konfigurationsdateien und freigegebene Bibliotheken lesen können, ohne sie ändern zu können.

Paket-Manager-Caches

Damit Installationen und Builds innerhalb des Sandkastens funktionieren können, Copilot gewähren Sie auch Zugriff auf die Caches und Registrierungen, die von allgemeinen Paketmanagern und Toolketten verwendet werden. Schreibgeschützt für Registrierungen und Toolketten und Lese-/Schreibzugriff für Buildcaches. /sandbox policy Im Bericht wird dies als Dev-Tool-Zugriff angezeigt.

Git-Repositorys

Wenn Sie in einem Unterverzeichnis eines Git-Repositorys arbeiten, Copilot gewährt Ihnen Lesezugriff auf das gesamte Repository, sodass Befehle das vollständige Projekt sehen können, während Schreibvorgänge in Ihr aktuelles Arbeitsverzeichnis und die Git-Metadaten des Repositorys (sein .git Verzeichnis) beschränkt werden. Auf diese Weise kann ein Befehl über das Repository gelesen werden, aber änderungen bleiben auf dem Ort, an dem Sie arbeiten, konzentriert.

Da der Lesezugriff das gesamte Repository umfasst, kann ein Sandkastenbefehl Dateien außerhalb Des aktuellen Unterverzeichnisses lesen, einschließlich der vertraulichen Elemente, die an anderer Stelle im Projekt gespeichert sind. Um bestimmte Pfade außerhalb der Reichweite zu halten, können Sie Verweigerungsregeln hinzufügen. Siehe Konfigurieren lokaler Sandkasteneinstellungen.

Wenn Zugriffsregeln sich überlappen

Da Copilot mehrere Standorte gewährt werden und Sie eigene hinzufügen können, können sich die Regeln überlappen. Wenn sie dies tun, gewinnt der spezifischere Pfad. Wenn z. B /project . schreibgeschützt, aber schreibgeschützt markiert /project/secrets wird, bleibt alles in /project schreibbar außer /project/secrets. Dies ist eine nützliche Möglichkeit, um einen vertraulichen Unterordner zu schützen.

Überlappungen werden auch zu Gunsten gelöst, wenn eine Convenience Grant andernfalls in die Richtung kommen würde. Ziehen Sie ein Python Projekt mit einer lokalen virtuellen Umgebung (.venv) in Betracht, die auf Ihrem PATHComputer angezeigt wird. Durch die Behandlung dieses Verzeichnisses als gewöhnlicher schreibgeschützter Toolspeicherort würde es schreibgeschützt – auch wenn es sich in Ihrem schreibbaren Projekt befindet – und ein Befehl, der pip install dann fehlschlägt, wenn versucht wird, die Umgebung zu aktualisieren. Copilot löst dies für Sie aus: Eine Bewilligung, die automatisch hinzugefügt wurde (z. B. ein Toolverzeichnis auf PATH) ermöglicht eine umfassendere Lese-/Schreibberechtigung, die sie bereits abdeckt. Daher bleibt ein projektlokales .venv, node_modules/.binoder ähnliches Verzeichnis im Rahmen Ihres Arbeitsbereichs schreibbar.

Von Ihnen konfigurierte Regeln werden immer beibehalten. Wenn Sie einen Pfad schreibgeschützt markieren oder ablehnen, steht diese Entscheidung auch dann, wenn derselbe Pfad sonst automatisch erkannt und gewährt wird. Dadurch erhalten Sie eine zuverlässige Möglichkeit, einen vertraulichen Speicherort zu schützen, z. B. das Verweigern einer .env Datei, sodass kein Sandkastenbefehl Ihre geheimen Schlüssel lesen kann.

Überprüfen, was die aktuelle Richtlinie zulässt

Da die Richtlinie für jedes Verzeichnis und jeden Befehl zusammengestellt ist, ist die einfachste Möglichkeit, den Zugriff anzuzeigen, den Sie fragen Copilot CLImüssen. Geben Sie in einer Sitzung Folgendes ein:

Shell
/sandbox policy

Copilot druckt die effektive Richtlinie für Ihr aktuelles Verzeichnis: die Pfade mit Lese-/Schreibzugriff, schreibgeschützt und verweigerten Pfaden, die ein von hier gestarteter Befehl tatsächlich erhalten würde, zusammen mit dem Netzwerkzugriff und dem erzwungenen Dev-Tool-Zugriff. Dies ist das aufgelöste Ergebnis, nachdem die automatischen Zuschüsse und Ihre eigenen Einstellungen kombiniert wurden und alle Überlappungen aufgelöst wurden , nicht nur eine Kopie Ihrer gespeicherten Einstellungen.

Ein paar Dinge, die Sie beim Lesen des Berichts beachten sollten:

  • Es spiegelt Ihr aktuelles Verzeichnis wider. Da Zuschüsse pro Verzeichnis ermittelt werden, können die gleichen Einstellungen je nach Ausführung in verschiedene Pfade aufgelöst werden.
  • Wenn ein von Ihnen konfigurierter Pfad auf dem Datenträger nicht vorhanden ist, wird er aus der Richtlinie herausgelassen und in einem Abschnitt "Notizen" angegeben. Dies erklärt, warum eine von Ihnen hinzugefügte Regel möglicherweise keine Auswirkung hat.
  • Wenn die Sandkastenfunktion deaktiviert ist, /sandbox policy wird dies angezeigt, anstatt eine Richtlinie zu drucken, da keine Einschränkungen in Kraft sind.

Um nur zu überprüfen, ob die Sandkastenumgebung derzeit aktiviert ist, verwenden Sie /sandbox status. Weitere Informationen zu diesen Befehlen finden Sie unter Verwenden der lokalen Sandkastenumgebung.

Anpassen der Richtlinie

Sie können zusätzliche Lese-/Schreib- oder schreibgeschützte Pfade gewähren, Pfade verweigern und ein anderes Dateisystemverhalten ändern, entweder über das /sandbox config Dialogfeld oder in der Einstellungsdatei. Nachdem Sie eine Änderung vorgenommen haben, führen Sie die Ausführung aus /sandbox policy , um das Ergebnis zu bestätigen. Schrittweise Anleitungen finden Sie unter Konfigurieren lokaler Sandkasteneinstellungen.

Unternehmensverwaltete Richtlinien

Wenn Sie eine unternehmenseigene Organisation durchlaufen Copilot , kann ein Administrator eine Dateisystemrichtlinie über verwaltete Einstellungen erzwingen. Verwaltete Einstellungen dienen als Basisplan, den Sie nicht lockern können: Sie können Sandkasten erfordern, verweigerte Pfade hinzufügen und einschränken, welche Pfade Sie gewähren dürfen. Wenn eine verwaltete Einstellung angewendet wird, wird sie /sandbox config im Dialogfeld als gesperrter (verwalteter) Wert angezeigt und /sandbox policy in der aufgelösten Richtlinie widergespiegelt.

Im Gegensatz zu den meisten Einstellungen, bei denen eine einzelne Quelle gewinnt, wird die Sandkastenrichtlinie aus jeder quelle erstellt, die gleichzeitig in Kraft ist. Verwaltete Einstellungen können über mehrere Kanäle gleichzeitig eingehen – serververwaltet, MDM und dateibasiert – und diese kombinieren sich miteinander und mit Ihren eigenen Einstellungen in der restriktivsten Richtung, anstatt eine Quelle außer Kraft zu setzen: Ein erforderlicher Umschalter bleibt aktiviert, pfade aus allen Quellen addiert, und die Pfade, die Sie erteilen dürfen, können nur eingeschränkt werden. Weitere Informationen findest du unter Unternehmensverwaltete Einstellungen.

Weiterführende Lektüre