Sandbox-Richtlinie

Der Bereich Sandbox-Richtlinie (in der Gruppe Sicherheit, zwischen Schutzmechanismen und Lieferkette) entscheidet, was die VM einer Maschine erreichen darf und, mit der OpenShell-Engine, was ihre Agenten in der VM tun dürfen (eine Maschine ist ein Arbeitsbereich, im Einstellungseditor). Vor 5.4 hieß er Firewall; eine Suche nach firewall, openshell, sentry oder landlock in den Einstellungen findet ihn weiterhin.

Der Bereich öffnet mit einer einzigen Wahl, Sandbox engine (die Sandbox-Engine):

Wie die Engines arbeiten und wie sie sich in die übrigen Schutzmaßnahmen von Bromure einfügen, erklärt Sandbox-Richtlinie, Gast-Sandbox und Kernel-Sentry. Diese Seite ist die Feldreferenz.

Der Wechsel zu OpenShell + Sentry füllt eine leere Policy mit der Standard-Policy Ihrer Organisation (oder der Start-Policy von Bromure) und schaltet den Kernel-Sentry in Best effort ein. Ein Wechsel zurück zu Bromure Firewall, solange eine Policy existiert, fragt zuerst nach, Switch to the Bromure Firewall?, denn Discard OpenShell policy entfernt die Policy und schaltet den Kernel-Sentry aus (es sei denn, Ihre Organisation schreibt ihn vor). Nehmen Sie zuerst Exportieren…, wenn Sie die Policy behalten wollen.

Die Schutzfunktionen, die für beide Engines gelten — den Agenten informieren, wenn die Richtlinie ihn blockiert, der Agenten-Watchdog, strenge Zugangsdaten, transparentes Abfangen und die unsichere Umgehung — stehen unter Schutzmechanismen › Schutzfunktionen.

Bromure-Firewall

Ausgehende Regeln

„Erlauben oder verweigern Sie die Verbindungen der VM nach Host, IP/CIDR, Protokoll und Port — von oben nach unten geprüft, die erste Übereinstimmung gewinnt." Regeln gelten für jedes Protokoll und jedes Ziel. Nicht zugeordneter Verkehr legt fest, was mit einer Verbindung geschieht, die keine Regel trifft: Erlauben (Voreinstellung) oder Verweigern für einen Aufbau mit Erlaubnisliste. Regel hinzufügen hängt eine Zeile an.

„Regeln gelten, während Sie sie bearbeiten; Abbrechen stellt sie wieder her." Weder Neustart noch Sichern ist nötig: Neue Verbindungen folgen sofort den neuen Regeln, und die bereits offenen ebenso. Eine Regel ausschalten, sie entfernen, eine Verweigerungsregel hinzufügen, ein ablaufendes Zeitlimit oder eine endende Bis-zum-Stopp-Regel prüfen jede offene Verbindung der Maschine neu, und die, die die neuen Regeln verweigern, werden auf beiden Seiten gekappt. Eine vorübergehende Erlaubnis auszuschalten beendet den Zugriff wirklich, statt einen offenen Download zu Ende laufen zu lassen.

• Verbindungen über die Proxy-Einstellungen (HTTPS_PROXY — curl, git, npm und die Agenten nutzen sie standardmäßig) kappt der Proxy selbst: Er schließt die Seite der VM und bricht die Anfrage an den Server ab, WebSockets eingeschlossen. Die Sicherheits-Zeitleiste zeichnet jede als Verbindung geschlossen — „allow tcp …“ erlaubt sie nicht mehr auf.
• Direkte Verbindungen kappt der virtuelle Switch bei ihrem nächsten Paket: Er verwirft es und schickt der VM einen TCP-Reset, und bei abgefangenem HTTP(S)-Verkehr wird auch die Verbindung des Proxys zum Server geschlossen.

Ändern sich die Regeln außerhalb des Editors, während er offen ist — durch eine Aktion in der Sicherheits-Zeitleiste oder ein ablaufendes Zeitlimit —, wird die Änderung mit Ihren ungesicherten Bearbeitungen zusammengeführt. Hatten Sie dieselben Regeln bearbeitet, fragt der Bereich: Neu laden oder Meine Änderungen behalten.

Vorübergehende Regeln

Manche Regeln braucht man nur kurz — etwa GitHub oder die npm-Registry gerade lange genug zu erreichen, um Abhängigkeiten zu aktualisieren. Statt die Regel hinzuzufügen und an das Löschen zu denken, setzen Sie mit dem Uhr-Menü der Regel ein Zeitlimit:

• 15 Minuten lang an / 1 Stunde lang an — die Regel greift nicht mehr, sobald die Zeit um ist, selbst wenn Bromure beschäftigt ist; kurz danach wird sie ausgeschaltet und so gesichert, damit sie für das nächste Mal in der Liste bleibt.
• An, bis der Workspace stoppt — die Regel wird ausgeschaltet, wenn die Maschine stoppt (oder neu startet), und beim nächsten Start von Bromure, falls sie noch lief, als die App beendet wurde.

Um die Regel später wieder zu nutzen, kreuzen Sie sie an oder wählen ein neues Zeitlimit.

Am schnellsten erlauben Sie etwas gerade Blockiertes über die Sandbox-Schublade im Fenster der Maschine, oder mit Erlauben… in der blockierten Zeile der Sicherheits-Zeitleiste. Beide bieten Immer, 15 Minuten lang, 1 Stunde lang und Bis der Workspace stoppt.

pf-Format

Das Aufklappfeld pf-Format zeigt dieselben Regeln als Text — eine je Zeile, endend mit default allow oder default deny — so werden sie gespeichert, und so benutzen sie die CLI und verwaltete Profile:

allow tcp api.github.com:443
allow web api.example.com GET,POST     # nur diese Verben erreichen die Seite
deny  web api.internal PUT,DELETE      # diese Verben blockieren, den Rest erlauben
deny  udp any:53
deny  any 10.0.0.0/8
default deny

Ausgeschaltete und vorübergehende Regeln tragen eine kurze Notiz in einem Kommentar, damit der Text schlichtes pf bleibt:

#@off allow tcp registry.npmjs.org:443          # ausgeschaltet
allow tcp github.com:443 #@until=1767225600      # an bis zu diesem Zeitpunkt (Unix-Sekunden)
allow tcp pypi.org:443 #@until=stop              # an, bis die Maschine stoppt

Die Durchsetzung geschieht auf dem Mac, in zwei Schichten: der virtuelle Netzwerk-Switch prüft jede Verbindung nach Ziel-IP und nach dem im DNS gesehenen Hostnamen (alle Protokolle), und der Proxy prüft erneut nach dem TLS-Servernamen und, für web-Regeln, nach der HTTP-Methode. Genau das erlaubt einer Maschine, eine API zu lesen, in die sie nicht schreiben darf: allow web api.example.com GET,POST gibt dem Agenten Abfragen ohne Änderungen, welches Werkzeug er auch benutzt.

Jede Entscheidung wird in der Sicherheits-Zeitleiste aufgezeichnet, mit der Regel, die sie getroffen hat, und auf registrierten Macs an Ihre Organisation gesendet.

Zugelassene Verbindungen protokollieren

Blockierte Verbindungen werden immer aufgezeichnet. Zugelassene Verbindungen protokollieren, unter der Auswahl Nicht zugeordneter Verkehr, entscheidet, ob auch die Verbindungen aufgezeichnet werden, die die Firewall durchlässt — das gibt ihren Zeilen die Schnellaktionen Blockieren… und Regel…. Solange Sie nichts wählen, ist es an, wenn die Maschine Regeln hat (oder nicht zugeordneten Verkehr verweigert), und aus bei einer Maschine ohne Firewall, damit eine Maschine ohne Regeln die Zeitleiste nicht mit „erlaubt“-Zeilen füllt.

Zugelassene Verbindungen bleiben in jedem Fall ruhig: eine Zeile pro Ziel (Host, Port und Protokoll — ein Host hinter mehreren Adressen ist eine Zeile) höchstens einmal pro Minute, und Wiederholungen werden mit einem Zähler in die vorige Zeile gefaltet. Der Endpunkt der lokalen Modelle auf dem Mac wird nie aufgeführt.

Hinweis: Lokale Modelle sind immer erreichbar: eine Erlaubnisregel für den Inferenz-Endpunkt auf dem Mac wird vor Ihre Regeln gesetzt, sodass selbst default deny Agenten nicht von einem Modell auf dem Gerät abschneiden kann.

Der Kernel-Sentry unter der Firewall

Der Kernel-Sentry gehört zur OpenShell-Engine. Eine Maschine, die ihn unter der Bromure-Firewall noch laufen lässt, zeigt eine Karte Kernel sentry is still on mit Turn off, oder — wenn Ihre Organisation den Sentry vorschreibt — „Your organization requires at least …" ohne Bedienelement.

OpenShell + Sentry

Die Einstellungen der Engine sind auf fünf Karten verteilt.

Policy

„Alles ist verweigert, solange keine Regel es erlaubt. Gilt sofort." Die Karte Policy enthält die Policy selbst: eine Sandbox-Policy von NVIDIA OpenShell, Schema-Version 1, in YAML. Verbindungen erlaubt nur eine Regel in network_policies; ein Endpunkt mit protocol wird Anfrage für Anfrage geprüft, wobei enforce blockiert und audit nur aufzeichnet. Änderungen gelten für eine laufende Maschine ohne Neustart.

Die Schaltflächen der Karte:

• Importieren… — ersetzt die Policy durch eine .yaml- / .yml-Datei.
• Exportieren… — sichert sie als <machine>-policy.yaml.
• Reset to starter policy — die Start-Policy erlaubt GitHub (github.com, api.github.com, **.githubusercontent.com auf 443), npm und PyPI nur lesend (geprüft, enforce) und die Paketspiegel von Ubuntu auf 80/443.

Unter dem Editor zeigt eine Prüfzeile Valid policy · N network rules (grün) oder den Parse-Fehler (rot), gefolgt von etwaigen Warnungen. Mit eingeschaltetem Enforce binaries werden Regeln ohne binaries orange hervorgehoben: Sie erlauben nichts.

Kernel-Sentry

„Streamt Sicherheitsereignisse (Prozessstarts, Rechteänderungen, Modul- und BPF-Ladevorgänge, Sandbox-Verweigerungen) aus dem Kernel der VM an Bromure, außerhalb von allem, was der Agent stoppen kann; nach dem Start wird der Kernel gesperrt, sodass nicht einmal root in der VM Code laden kann, um einzugreifen." Stille oder eine Lücke im Strom gilt für den Agenten-Watchdog als Manipulation.

Mode gilt ab dem nächsten VM-Start. Legt Ihre Organisation ein Minimum fest, gilt das strengere von beiden, und Best effort ist unter einem Minimum Required ausgegraut („Your organization requires it."). Eine Maschine, die eingerichtet wurde, bevor der Sentry zur Engine gehörte, zeigt Off for this workspace mit Turn on.

Die Statuszeile der Karte zeigt Connected · kernel Version oder Not connected, wie viele Ereignisse unter Last verloren gingen, falls welche, und Couldn't start: Grund in Rot, wenn die VM den Sentry nicht laden konnte. Wie seine Module geliefert werden, steht unter Der Kernel-Sentry.

Sandbox

Der Titel der Karte wird orange, Sandbox ⚠︎, wenn die VM ein Problem meldet: Die Dateisystem-Sandbox oder die strenge Sandbox wurde nicht angewendet, der Sentry ist nicht verfügbar, obwohl er erwartet wird, oder der Gast hat Warnungen geschickt.

Die Statuszeilen unter Enforce binaries und Filesystem & process zeigen, was die VM tatsächlich angewendet hat:

• Attestor connected: binaries are enforced, oder Attestor not connected: until it is, only Bromure's own rules apply.
• Filesystem, gefolgt von seinem Zustand, dem Benutzer, unter dem der Agent läuft, und der Landlock-Version, oder Filesystem not applied yet, bevor die VM sich meldet.
• Die Pfade, die Bromure für seine eigene Infrastruktur hinzufügt (Added for Bromure: …).
• Wenn das Dateisystem eingeschränkt ist, Binaries aber nicht erzwungen werden: „The agent keeps sudo, so it could stop Bromure's processes in the VM. Turn on Enforce binaries to prevent that."
• In Rot, wenn die strenge Sandbox nicht angewendet wurde: „no session will start and binary rules fail closed. Restarting the VM retries it."

Policy-Berater

Wird eine Anfrage blockiert, kann der Agent die enge Regel, die er braucht, bei http://policy.local (der Berater-API von OpenShell) vorschlagen und auf Ihre Entscheidung warten. Blockierte Verbindungen werden hier ebenfalls als Vorschläge entworfen.

Jeder offene Vorschlag zeigt seine Regel und sein Ziel, ob er drafted from a block (aus einer Blockade entworfen) oder proposed by the agent (vom Agenten vorgeschlagen) ist, die erklärte Absicht des Agenten, das YAML und etwaige Risikobefunde in Orange. Tippen Sie bei Bedarf einen Reason (sent to the agent on reject) ein, dann Reject oder Approve. Eine genehmigte Regel wird der Policy hinzugefügt und gilt sofort. Recent decisions listet die letzten fünf. Dieselben Vorschläge erscheinen in der Sandbox-Schublade.

Governance

• Organization boundary — das Höchste, was die Policy irgendeiner Maschine erlauben darf. Sie ist Set by your organization (bromure.io), Set on this Mac (mit Set from file… und Leeren) oder None set. Jedes Sichern, das eine Policy ändert, wird gegen sie geprüft, mit NVIDIAs openshell-prover, wenn er installiert ist, sonst mit der eingebauten Prüfung von Bromure. Eine Policy außerhalb der Grenze wird mit der Zusammenfassung der Grenze abgewiesen, egal wo sie bearbeitet wurde — im Bereich, in der Sandbox-Schublade, über den Berater oder die API.
• Revision history — jedes Sichern, das die Policy ändert, wird als Version aufbewahrt (vN, mit Datum, Herkunft der Änderung und kurzem Hash). Wiederherstellen lädt eine Version zurück in den Editor.
• Rules Bromure adds automatically — wie die Anbieterregeln von OpenShell halten sie die Agenten der Maschine und alle Zugangsdaten, die sie einrichtet, erreichbar. Sie gehören nicht zur exportierten Policy.

Was der Agent sieht, wenn er blockiert wird

Eine Verbindung, die die Policy verweigert, scheitert sofort, ohne hängenden Socket. Unter einer OpenShell-Policy bekommt eine verweigerte Proxy-Verbindung oder geprüfte Anfrage HTTP 403 mit dem OpenShell-eigenen Body policy_denied: die Schicht, Host und Port (oder Methode und Pfad) und die Regel oder der Grund. Ist der Policy-Berater an, sagt der Body dem Agenten auch, wie er bei http://policy.local eine Regel vorschlägt. Mit eingeschaltetem Tell the agent when policy blocks it (siehe Schutzmechanismen) erfährt der Agent zudem in seiner Unterhaltung, was er versucht hat, dass die Richtlinie es verbietet, und dass er Sie fragen soll, statt es zu umgehen.

Einstellungsreferenz

Regeltabelle und Policy-Editor werden im Client für iPhone, iPad oder Vision Pro nicht gezeigt („Outbound connection rules are edited on the Mac that runs this workspace."); auf dem Mac gesetzte Regeln und Policies gelten weiter.

Verwandte Kapitel

• Sandbox-Richtlinie, Gast-Sandbox und Kernel-Sentry — wie die Engines arbeiten.
• Schutzmechanismen — Zugangsdaten-Richtlinien und die Schutzfunktionen, die beide Engines teilen.
• Zugangsdaten — OpenShell-Anbieterprofile und Zugangsdaten-Platzhalter.
• Sicherheitsübersicht und Zeitleiste — jede Blockade und jede Erlaubnis, je Maschine, und die Netzwerk-Abstammung.