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

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. Ausführliche Informationen zum Konfigurieren der lokalen Sandbox-Isolierung finden Sie unter Konfigurieren lokaler Sandkasteneinstellungen.

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 Sprachserverprozesse (LSP) werden standardmäßig im Sandkasten ausgeführt, sodass das Betriebssystem auch die Richtlinie für sie erzwingt. Sie können dies in den Sandkasteneinstellungen ändern, es sei denn, eine verwaltete Richtlinie erfordert dies.
  • 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. Ihre Verbindungen von der CLI können weiterhin durch die Netzwerkrichtlinie eingeschränkt werden, wenn Sandbox MCP servers aktiviert ist.
  • Subagenten verwenden andere Tools, um ihre Arbeit zu erledigen. 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. Dies umfasst allgemeine Speicherorte, die von Tools benötigt werden, sodass Sie nicht jeden einzelnen selbst freigeben müssen. Tools können auch Zugriff auf ausgewählte Sitzungsdateien und installierte Skills erhalten, die sie benötigen.

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 PFAD

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, es aber nicht ä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 wird standardmäßigen Systemspeicherorten nur Leseberechtigung gewährt, sodass Befehle freigegebene Bibliotheken laden und die Systemkonfiguration lesen können, ohne sie ändern zu können. Die Anwendungsverzeichnisse in Ihrem Benutzerprofil (z. B. die Unterverzeichnisse von %LOCALAPPDATA%\Programs unter Windows oder die Verzeichnisse ~/.local/bin und ~/.local/lib unter macOS und Linux) erhalten ebenfalls Nur-Lesezugriff, wenn Zugriff auf Entwicklertools zulassen aktiviert ist, damit Befehle die dort installierten Tools lesen können, ohne sie ändern zu können.

Paketmanager-Caches

Wenn Zugriff auf Entwicklertools zulassen aktiviert ist, gewährt Copilot Zugriff auf die Caches und Registrys, die von allgemeinen Paketmanagern und Toolchains verwendet werden. Die meisten Speicherorte sind schreibgeschützt. Ausgewählte Speicherorte, z. B. npm-Cache, Buildcaches und einige Abhängigkeitsspeicher, sind schreibbar, sodass Installationen und Builds funktionieren können.

Diese Berechtigungen hängen vom Befehl und den in Ihrem Projekt erkannten Tools ab. Sie können Cache-Speicherorte berücksichtigen, die Sie außerhalb der üblichen Verzeichnisse konfiguriert haben. Einige freigegebene Konfigurationsdateien enthalten Anmeldedaten für die Registry, und schreibbare Caches können mit Befehlen geteilt werden, die Sie außerhalb der Sandbox ausführen. Deaktivieren Sie Zugriff auf Entwicklertools zulassen, wenn Sie diese Speicherorte selbst gewähren möchten.

/sandbox policy Im Bericht werden im Abschnitt "Dev Tools" die erkannten Tools und deren Pfade aufgelistet. Ausgewählte schreibbare Caches werden erstellt, wenn ein Befehl sie benötigt, sodass sie möglicherweise nicht im Bericht vor der ersten Verwendung angezeigt werden.

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 schreibgeschützte und Lese-/Schreibberechtigungen überlappen, 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. Verweigerte Pfade haben Vorrang vor beiden Arten von Berechtigungen.

Ermittelte Berechtigungen für Tool-Verzeichnisse weichen einem Lese-/Schreibzugriff, der sie bereits abdeckt. 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 belässt es als Teil Ihres Arbeitsbereichs schreibbar. Andere schreibgeschützte Regeln, einschließlich der Regeln, die Sie selbst konfigurieren, werden auf diese Weise nicht verworfen.

Von Ihnen konfigurierte Regeln werden nicht entfernt, nur weil derselbe Pfad automatisch erkannt wurde. Sie können sie verwenden, um den Zugriff auf einen vertraulichen Speicherort zu beschränken, z. B. eine vorhandene .env Datei. Fehlende Pfade und symbolische Verknüpfungen benötigen zusätzliche Sorgfalt, wie in der Problembehandlung für den Dateisystemzugriff beschrieben.

Ü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 druckt die effektive Richtlinie für Ihr aktuelles Verzeichnis. Pfade werden nach Quelle gruppiert, z. B. vom Benutzer konfigurierte Pfade und Dev-Tools, und nach Zugriffsebene. Der Bericht enthält außerdem Netzwerkeinstellungen und einen Abschnitt "Funktionen" , in dem Einstellungen wie Umgehung, MCP/LSP-Sandboxing und Authentifizierung behandelt werden. Dies ist das Ergebnis, nachdem automatische Berechtigungen, Einstellungen und verwaltete Einschränkungen kombiniert wurden – nicht nur eine Kopie Ihrer gespeicherten Einstellungen.

Um den Zugriff auf das Entwicklertool für einen bestimmten Befehl zu prüfen, fügen Sie den Befehl nach policy hinzu. Beispiele:

Shell
/sandbox policy npm install

Dies läuft nicht npm install. Es zeigt, welchen Zugriff das Tool auf den Befehl erhalten würde. Die Vorschau erstellt keine Verzeichnisse, einschließlich fehlender oder verweigerter Pfade und Toolcaches.

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.
  • Überprüfen Sie die Hinweise auf konfigurierte Pfade, die nicht eingeschlossen werden konnten. Fehlende Lese-/Schreibberechtigungen oder schreibgeschützte Berechtigungen werden weggelassen. Unter Linux werden fehlende verweigerte Pfade aus dieser Vorschau weggelassen, aber die Startvorbereitung erstellt sie, bevor die Richtlinie angewendet wird. Die Vorschau behält sie unter macOS und auf Windows-Hosts bei, die nicht zulässige Pfade unterstützen.
  • 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.

Problembehandlung beim Dateisystemzugriff

Wenn ein konfigurierter Lese-/Schreib- oder schreibgeschützter Pfad nicht existiert, erstellen Sie ihn außerhalb des Sandkastens, bevor Sie den Befehl erneut starten. Ein laufender untergeordneter Prozess behält die beim Start empfangene Richtlinie bei. Das Erstellen eines Pfads zu einem späteren Zeitpunkt fügt diesem Prozess keine fehlende Berechtigung hinzu. Starten Sie einen lange laufenden Server neu, wenn er den aktualisierten Zugriff benötigt.

Bevor ein Prozess in der Sandbox gestartet wird, erstellt Copilot CLI fehlende gesperrte Pfade und deren übergeordnete Verzeichnisse auf Ihrem Computer. Dies schließt Pfade ein, die für Dateien vorgesehen sind, sodass ein fehlendes .env zu einem Verzeichnis wird. Die Verzeichnisse verbleiben nach dem Beenden des Prozesses.

Wenn ein gesperrter Pfad nicht vorbereitet werden kann, wird der Vorgang nicht gestartet. Die schreibgeschützte /sandbox policy Vorschau führt diese Vorbereitung nicht durch, weshalb fehlende Pfade mit Zugriffsverweigerung unter Linux weggelassen werden. Informationen zur Problembehandlung finden Sie unter Verwenden einer lokalen Sandbox.

Ein symbolischer Link innerhalb eines zulässigen Verzeichnisses garantiert keinen Zugriff auf ein Ziel außerhalb dieses Verzeichnisses. Wenn eine Ablehnungsnachricht ein solches Ziel benennt, überprüfen Sie sie, und gewähren Sie nur dann Zugriff, wenn dies beabsichtigt ist. Durch das Hinzufügen einer auflösbaren symbolischen Verknüpfung über /sandbox config wird auch das aktuelle Ziel für Lese-/Schreibzugriff oder Nur-Lese-Zugriff hinzugefügt. Manuell definierte Pfadregeln und automatisch ermittelte Berechtigungen für Entwicklertools fügen dieses Ziel nicht automatisch hinzu.

Verweigerte Pfade werden anders behandelt als Berechtigungen: Die CLI löst ihren geschriebenen Pfad und das aktuelle Ziel auf. Unter Linux schützt ein abgelehnter symbolischer Link sein Ziel, verhindert aber nicht zuverlässig, dass der symbolische Link selbst ersetzt wird. Bevorzugen Sie es, den Zugriff auf das tatsächliche sensible Verzeichnis zu verweigern, anstatt sich allein auf eine Regel für symbolische Links zu verlassen.

Informationen zu Netzwerkfehlern, verwalteten Einschränkungen und Umgehungsoptionen finden Sie unter "Problembehandlung blockierter Befehle".

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 Sandbox-Umgehung zulässt, kann ein Benutzer die Sandbox für den Rest der aktuellen Sitzung explizit deaktivieren, entweder über einen aktiven Prompt für die Umgehungsberechtigung oder durch Ausführen von /sandbox disable. Durch diese Abmeldung von der Sitzung wird die gespeicherte Richtlinie nicht gelockert.

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