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 Sandbox aktivieren, führt Copilot CLI die Befehle, die es für Sie aufruft, innerhalb einer Betriebssystem-Sandbox aus. 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 zu der Richtlinie gelangt und wie Sie überprüfen, welchen Zugriff sie in einem bestimmten Verzeichnis gewährt.

Eine Übersicht über das lokale Sandboxing, einschließlich seiner Aktivierung und Deaktivierung, finden Sie unter Informationen zu Cloud- und lokalen Sandboxes für GitHub Copilot und Verwenden einer lokalen Sandbox.

Wofür die Richtlinie gilt

Die Dateisystemrichtlinie gilt für die Arbeit, die Copilot in Ihrem Auftrag ausführt, wird jedoch je nach Art der Aufgabe auf unterschiedliche Weise durchgesetzt:

  • 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 Language-Server-Prozesse (LSP) können auch in der Sandbox laufen, sodass das Betriebssystem die Richtlinie auch für sie durchsetzt.
  • Integrierte Tools zum Lesen und Bearbeiten von Dateien werden als Teil von Copilot CLI selbst und nicht als in einer Sandbox ausgeführter untergeordneter Prozess ausgeführt. Sie prüfen vor dem Lesen oder Schreiben einer Datei dieselbe Dateisystemrichtlinie, aber weil die Sandbox des Betriebssystems diese Vorgänge nie erfasst, ist die Prüfung eine rein softwarebasierte Schutzmaßnahme und keine, die vom Betriebssystem durchgesetzt wird.
  • 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

Die Sandbox ist standardmäßig gesperrt: Sofern ein Pfad nicht explizit freigegeben ist, kann ein Befehl 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 standardmäßig verweigert wird, sofern er nicht gewährt wurde, muss Copilot einem Befehl alles gewähren, was er berechtigterweise benötigt – Ihre Projektdateien, die Tools, die er ausführt, und erforderliche Speicherorte wie temporäre Verzeichnisse – und alles andere unzugänglich halten.

Hinweis

Diese Berechtigungsstufen gelten für jeden Prozess und jeden Vorgang in der Sandbox, werden jedoch unterschiedlich durchgesetzt: Bei untergeordneten Prozessen in der Sandbox setzt das Betriebssystem sie direkt durch, während die integrierten Werkzeuge der CLI zum Lesen und Bearbeiten von Dateien dieselben Berechtigungsstufen softwareseitig prüfen, ohne Absicherung durch das Betriebssystem.

Erstellen der Richtlinie

Bevor jeder Sandbox-Prozess startet, löst Copilot CLI die effektive Richtlinie für diesen Prozess anhand des aktuellen Arbeitsverzeichnisses, der Umgebung, der Einstellungen und der automatischen Berechtigungen auf. 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. In einem Git-Repository fügt Copilot auch die zugehörigen Git-Berechtigungen 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 Copilot von einer unternehmenseigenen Organisation erhalten, kann ein Administrator die Einstellung Arbeitsverzeichnis einschließen deaktivieren und sperren, sodass Sie sie nicht erneut aktivieren können. Siehe Unternehmensverwaltete Einstellungen.

Tools auf Ihrem PATH

Um ein Programm wie python oder git auszuführen, muss die Sandbox dem Befehl Zugriff auf das Verzeichnis gewähren, in dem sich das Programm befindet. Wenn Zugriff auf Entwicklertools zulassen aktiviert ist – was standardmäßig der Fall ist –, gewährt Copilot Nur-Lesezugriff auf die in Ihrer Umgebungsvariablen PATH aufgeführten Verzeichnisse sowie auf Verzeichnisse, die durch verwandte Tool-Variablen wie GOPATH, JAVA_HOME und PYTHONPATH angegeben werden. Nur-Lesezugriff ist die richtige Berechtigungsstufe für externe Tools: Ein Befehl muss mit git ausgeführt werden, nicht es ändern. Wenn Sie Zugriff auf Entwicklertools zulassen deaktivieren, wird diesen Verzeichnissen nicht mehr automatisch Zugriff gewährt, sondern er muss durch Ihre eigenen Zulassungsregeln erlaubt werden. Die vollständige Liste der PATH und Toolchain-Umgebungsvariablen, die die Sandbox untersucht, sowie wie jede einzelne interpretiert wird, finden Sie unter GitHub Copilot CLI-Befehlsreferenz.

System- und Profilspeicherorte

Unter macOS werden standardmäßige Systemspeicherorte mit Schreibschutz bereitgestellt, sodass Befehle gemeinsam genutzte Bibliotheken laden und die Systemkonfiguration lesen können, ohne diese Speicherorte ändern zu können. Die Anwendungsverzeichnisse in Ihrem Benutzerprofil werden ebenfalls nur mit Lesezugriff freigegeben, wenn Zugriff auf Entwicklertools zulassen aktiviert ist, sodass Befehle die dort installierten Tools lesen können, ohne sie ändern zu können.

Paketmanager-Caches

Damit Installationen und Builds innerhalb der Sandbox funktionieren, gewährt Copilot außerdem Zugriff auf die Caches und Registrys, die von gängigen Paketmanagern und Toolchains verwendet werden – für die meisten Orte schreibgeschützt und für ausgewählte beschreibbare Orte mit Lese-/Schreibzugriff, z. B. Build-Caches und Abhängigkeitsverzeichnisse von Paketmanagern. /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 bereitstellt und Sie eigene hinzufügen können, können sich Regeln überschneiden. Wenn sie dies tun, gewinnt der spezifischere Pfad. Wenn z. B. /project beschreibbar ist, Sie /project/secrets aber als schreibgeschützt markieren, bleibt alles in /project außer /project/secrets beschreibbar. Dies ist eine nützliche Möglichkeit, um einen vertraulichen Unterordner zu schützen.

Überschneidungen werden auch dann zu Ihren Gunsten aufgelöst, wenn eine aus Kulanz gewährte Genehmigung andernfalls im Weg stehen würde. Ziehen Sie ein Python Projekt mit einer lokalen virtuellen Umgebung (.venv) in Betracht, die auf Ihrem PATHComputer angezeigt wird. Wenn dieses Verzeichnis als ein gewöhnlicher schreibgeschützter Tool-Speicherort behandelt würde, wäre es schreibgeschützt – obwohl es sich innerhalb Ihres beschreibbaren Projekts befindet – und ein Befehl wie pip install könnte dann fehlschlagen, wenn er versucht, die Umgebung zu aktualisieren. Copilot löst dies für Sie: Eine automatisch hinzugefügte Berechtigung (z. B. ein Toolverzeichnis auf PATH) wird durch eine umfassendere Lese-/Schreibberechtigung ersetzt, die dieses 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 als schreibgeschützt markieren oder verweigern, bleibt diese Entscheidung auch dann bestehen, wenn derselbe Pfad andernfalls automatisch erkannt und zugelassen würde. 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 erstellt wird, ist die einfachste Möglichkeit, zu sehen, welche Zugriffsrechte Sie haben, Copilot CLI zu fragen. Geben Sie in einer Sitzung Folgendes ein:

Shell
/sandbox policy

Copilot gibt die effektive Richtlinie für Ihr aktuelles Verzeichnis aus: die Pfade mit Lese-/Schreibzugriff, schreibgeschützte Pfade und verweigerte Pfade, die ein von hier aus gestarteter Befehl tatsächlich erhält, zusammen mit dem geltenden Netzwerkzugriff und dem Zugriff auf Entwicklertools. Dies ist das resultierende Ergebnis, nachdem die automatisch gewährten Berechtigungen mit Ihren eigenen Einstellungen kombiniert und alle Überschneidungen bereinigt 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 das Sandboxing deaktiviert ist, weist /sandbox policy Sie darauf hin, anstatt eine Richtlinie auszugeben, da keine Einschränkungen in Kraft sind.

Um nur zu prüfen, ob Sandboxing aktuell aktiviert ist, verwenden Sie /sandbox status. Weitere Informationen zu diesen Befehlen finden Sie unter Verwenden einer lokalen Sandbox.

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 Copilot über eine unternehmenseigene Organisation erhalten, kann ein Administrator über verwaltete Einstellungen eine Dateisystemrichtlinie erzwingen. Verwaltete Einstellungen dienen als restriktive Grundlage: sie können Sandboxing erfordern, gesperrte Pfade hinzufügen und einschränken, welche Pfade Sie freigeben dürfen. Wenn eine verwaltete Einstellung gilt, zeigt das /sandbox config Dialogfeld sie als gesperrten (verwalteten) Wert an, und /sandbox policy zeigt sie entsprechend in der aufgelösten Richtlinie an. Wenn die effektive Richtlinie die Umgehung der Sandbox zulässt, kann ein Nutzer die Ausführung in der Sandbox für den Rest der aktuellen Sitzung über eine aktive Aufforderung zur Erteilung einer Umgehungsberechtigung explizit deaktivieren. Diese Deaktivierung für die aktuelle Sitzung lockert die gespeicherte Richtlinie nicht.

Im Gegensatz zu den meisten Einstellungen, bei denen sich eine einzelne Quelle durchsetzt, wird die Sandbox-Richtlinie aus allen gleichzeitig geltenden Quellen zusammengesetzt. Verwaltete Einstellungen können gleichzeitig über mehrere Kanäle bereitgestellt werden – serverseitig verwaltet, per MDM und dateibasiert – und werden miteinander sowie mit Ihren eigenen Einstellungen nach dem Prinzip der strengsten Einschränkung zusammengeführt, statt dass eine Quelle eine andere überschreibt: Ein verpflichtend aktivierter Schalter bleibt aktiviert, von allen Quellen verweigerte Pfade summieren sich, und die Pfade, die Sie freigeben dürfen, können nur weiter eingeschränkt werden. Weitere Informationen findest du unter Unternehmensverwaltete Einstellungen.

Weiterführende Lektüre