Politique du bac à sable

Le volet Politique du bac à sable (dans le groupe Sécurité, entre Garde-fous et Chaîne d'approvisionnement) décide ce que la VM d'une machine peut atteindre et, avec le moteur OpenShell, ce que ses agents peuvent faire dans la VM (une machine est un espace de travail, dans l'éditeur de réglages). Il s'appelait Pare-feu avant la 5.4 ; chercher firewall, openshell, sentry ou landlock dans les réglages le trouve toujours.

Le volet s'ouvre sur un seul choix, Sandbox engine (le moteur de bac à sable) :

Le fonctionnement des moteurs, et leur place parmi les autres protections de Bromure, est expliqué dans Politique du bac à sable, bac à sable invité et sentinelle du noyau. Cette page est la référence des champs.

Passer à OpenShell + Sentry remplit une politique vide avec la politique par défaut de votre organisation (ou la politique de départ de Bromure) et active la sentinelle du noyau en Best effort. Revenir à Bromure Firewall alors qu'une politique existe demande d'abord confirmation, Switch to the Bromure Firewall?, parce que Discard OpenShell policy supprime la politique et désactive la sentinelle du noyau (sauf si votre organisation l'impose). Utilisez d'abord Exporter… si vous voulez garder la politique.

Les protections qui valent pour les deux moteurs — prévenir l'agent quand la politique le bloque, le chien de garde des agents, les identifiants stricts, l'interception transparente et le contournement non sécurisé — se trouvent dans Garde-fous › Protections.

Pare-feu Bromure

Règles sortantes

« Autorisez ou refusez les connexions de la VM par hôte, IP/CIDR, protocole et port — appariées de haut en bas, la première correspondance gagne. » Les règles couvrent n'importe quel protocole et n'importe quelle destination. Trafic non apparié fixe ce qu'il advient d'une connexion qu'aucune règle n'apparie : Autoriser (défaut) ou Refuser pour une configuration en liste blanche. Ajouter une règle ajoute une ligne.

« Les règles s'appliquent pendant que vous les modifiez ; Annuler les remet en place. » Ni redémarrage ni Enregistrer : les nouvelles connexions suivent aussitôt les nouvelles règles, et celles déjà ouvertes aussi. Désactiver une règle, la supprimer, ajouter une règle de refus, l'expiration d'une durée ou la fin d'une règle jusqu'à l'arrêt revérifient toutes les connexions ouvertes de la machine, et celles que les nouvelles règles refusent sont coupées des deux côtés. Désactiver une autorisation temporaire met réellement fin à l'accès, au lieu de laisser un téléchargement ouvert aller jusqu'au bout.

• Les connexions passées par les réglages de proxy (HTTPS_PROXY — curl, git, npm et les agents les utilisent par défaut) sont coupées par le proxy lui-même : il ferme le côté VM et annule la requête vers le serveur, WebSockets compris. La Chronologie de sécurité enregistre chacune comme connexion fermée — « allow tcp … » ne l'autorise plus.
• Les connexions directes sont coupées par le commutateur virtuel à leur paquet suivant : il le rejette et envoie à la VM un reset TCP, et pour le trafic HTTP(S) intercepté la connexion du proxy vers le serveur est fermée aussi.

Si les règles changent hors de l'éditeur pendant qu'il est ouvert — une action de la Chronologie de sécurité, ou une durée qui expire —, le changement est fusionné avec vos modifications non enregistrées. Si vous aviez modifié les mêmes règles, le volet demande : Recharger ou Garder mes modifications.

Règles temporaires

Certaines règles ne servent qu'un instant — joindre GitHub ou le registre npm le temps de mettre à jour des dépendances, par exemple. Plutôt que d'ajouter la règle et de penser à la supprimer, fixez une durée avec le menu horloge de la règle :

• Activer pendant 15 minutes / Activer pendant 1 heure — la règle cesse de correspondre dès que le temps est écoulé, même si Bromure est occupé ; peu après, elle est désactivée et enregistrée ainsi, si bien qu'elle reste dans la liste pour la prochaine fois.
• Activer jusqu'à l'arrêt de l'espace de travail — la règle est désactivée quand la machine s'arrête (ou redémarre), et au prochain lancement de Bromure si elle tournait encore quand l'app a quitté.

Pour réutiliser la règle plus tard, cochez-la ou choisissez une nouvelle durée.

Le moyen le plus rapide d'autoriser ce qui vient d'être bloqué est le tiroir Sandbox dans la fenêtre de la machine, ou Autoriser… sur la ligne bloquée de la Chronologie de sécurité. Les deux proposent Toujours, Pendant 15 minutes, Pendant 1 heure et Jusqu'à l'arrêt de l'espace de travail.

Format pf

Le dépliant format pf montre les mêmes règles sous forme de texte — une par ligne, finissant par default allow ou default deny — c'est ainsi qu'elles sont stockées et c'est ce qu'utilisent la CLI et les profils gérés :

allow tcp api.github.com:443
allow web api.example.com GET,POST     # seuls ces verbes atteignent le site
deny  web api.internal PUT,DELETE      # bloquer ces verbes, autoriser le reste
deny  udp any:53
deny  any 10.0.0.0/8
default deny

Les règles désactivées et temporaires portent une courte note en commentaire, de sorte que le texte reste du pf simple :

#@off allow tcp registry.npmjs.org:443          # désactivée
allow tcp github.com:443 #@until=1767225600      # active jusqu'à cette heure (secondes Unix)
allow tcp pypi.org:443 #@until=stop              # active jusqu'à l'arrêt de la machine

L'application se fait sur le Mac, en deux couches : le commutateur réseau virtuel vérifie chaque connexion par IP de destination et par le nom d'hôte vu dans le DNS (tous protocoles), et le proxy vérifie de nouveau par nom de serveur TLS et, pour les règles web, par méthode HTTP. C'est ce qui permet à une machine de lire une API dans laquelle elle ne peut pas écrire : allow web api.example.com GET,POST donne à l'agent des requêtes sans changements, quel que soit l'outil qu'il utilise.

Chaque décision est enregistrée dans la Chronologie de sécurité, avec la règle qui l'a prise, et sur les Mac inscrits envoyée à votre organisation.

Journaliser les connexions autorisées

Les connexions bloquées sont toujours enregistrées. Journaliser les connexions autorisées, sous le choix Trafic non apparié, décide si les connexions que le pare-feu laisse passer sont enregistrées aussi — c'est ce qui donne à leurs lignes les actions rapides Bloquer… et Règle…. Tant que vous n'avez pas choisi, il est activé quand la machine a des règles (ou refuse le trafic non apparié) et désactivé pour une machine sans pare-feu, si bien qu'une machine sans règles ne remplit pas la Chronologie de lignes « autorisé ».

Les connexions autorisées restent peu bavardes dans tous les cas : une ligne par destination (hôte, port et protocole — un hôte derrière plusieurs adresses fait une seule ligne) au plus une fois par minute, et les répétitions se replient dans la ligne précédente avec un compteur. Le point d'accès des modèles locaux sur le Mac n'est jamais listé.

Note : les modèles locaux sont toujours joignables : une règle d'autorisation pour le point d'accès d'inférence sur le Mac est placée devant vos règles, de sorte que même default deny ne peut pas couper les agents d'un modèle sur l'appareil.

La sentinelle du noyau sous le pare-feu

La sentinelle du noyau appartient au moteur OpenShell. Une machine qui la fait encore tourner sous le pare-feu Bromure affiche une carte Kernel sentry is still on avec Turn off, ou — quand votre organisation impose la sentinelle — « Your organization requires at least … » et aucune commande.

OpenShell + Sentry

Les réglages du moteur sont répartis en cinq cartes.

Politique

« Tout est refusé sauf si une règle l'autorise. S'applique à chaud. » La carte Policy contient la politique elle-même : une politique de bac à sable NVIDIA OpenShell, version de schéma 1, en YAML. Les connexions ne sont autorisées que par une règle network_policies ; un point de terminaison doté d'un protocol est inspecté requête par requête, où enforce bloque et audit ne fait qu'enregistrer. Les modifications s'appliquent à une machine en marche sans redémarrage.

Les boutons de la carte :

• Importer… — remplace la politique par un fichier .yaml / .yml.
• Exporter… — l'enregistre sous <machine>-policy.yaml.
• Reset to starter policy — la politique de départ autorise GitHub (github.com, api.github.com, **.githubusercontent.com sur 443), npm et PyPI en lecture seule (inspectés, en enforce), et les miroirs de paquets d'Ubuntu sur 80/443.

Sous l'éditeur, une ligne de vérification affiche Valid policy · N network rules (en vert) ou l'erreur d'analyse (en rouge), suivie des éventuels avertissements. Avec Enforce binaries activé, les règles qui ne listent aucun binaries sont signalées en orange : elles n'autorisent rien.

Sentinelle du noyau

« Transmet les événements de sécurité (lancements de processus, changements de privilèges, chargements de modules et de BPF, refus du bac à sable) du noyau de la VM à Bromure, hors de portée de tout ce que l'agent peut arrêter ; une fois démarrée, le noyau est verrouillé pour que même root dans la VM ne puisse pas charger de code pour interférer. » Un silence ou un trou dans le flux compte comme une altération pour le chien de garde des agents.

Mode s'applique au prochain démarrage de la VM. Quand votre organisation fixe un minimum, c'est le plus strict des deux qui s'applique, et Best effort est grisé sous un minimum Required (« Your organization requires it. »). Une machine configurée avant que la sentinelle n'accompagne le moteur affiche Off for this workspace avec Turn on.

La ligne d'état de la carte indique Connected · kernel version ou Not connected, combien d'événements ont été perdus sous la charge, le cas échéant, et Couldn't start: raison en rouge quand la VM n'a pas pu charger la sentinelle. Voir la sentinelle du noyau pour la façon dont ses modules sont livrés.

Bac à sable

Le titre de la carte passe à l'orange, Sandbox ⚠︎, quand la VM signale un problème : le bac à sable du système de fichiers ou le bac à sable strict ne s'est pas appliqué, la sentinelle est indisponible alors qu'elle est attendue, ou l'invité a envoyé des avertissements.

Les lignes d'état sous Enforce binaries et Filesystem & process disent ce que la VM a réellement appliqué :

• Attestor connected: binaries are enforced, ou Attestor not connected: until it is, only Bromure's own rules apply.
• Filesystem suivi de son état, de l'utilisateur sous lequel tourne l'agent et de la version de Landlock, ou Filesystem not applied yet avant que la VM ne fasse son rapport.
• Les chemins que Bromure ajoute pour sa propre plomberie (Added for Bromure: …).
• Quand le système de fichiers est confiné mais que les binaires ne sont pas imposés : « The agent keeps sudo, so it could stop Bromure's processes in the VM. Turn on Enforce binaries to prevent that. »
• En rouge, quand le bac à sable strict ne s'est pas appliqué : « no session will start and binary rules fail closed. Restarting the VM retries it. »

Conseiller de politique

Quand une requête est bloquée, l'agent peut proposer la règle étroite dont il a besoin à http://policy.local (l'API du conseiller d'OpenShell) et attendre votre décision. Les connexions bloquées sont aussi rédigées ici sous forme de propositions.

Chaque proposition en attente montre sa règle et sa destination, si elle a été drafted from a block (rédigée à partir d'un blocage) ou proposed by the agent (proposée par l'agent), l'intention annoncée par l'agent, le YAML, et les éventuels constats de risque en orange. Saisissez une Reason (sent to the agent on reject) si vous le souhaitez, puis Reject ou Approve. Une règle approuvée est ajoutée à la politique et s'applique à chaud. Recent decisions liste les cinq dernières. Les mêmes propositions apparaissent dans le tiroir Sandbox.

Gouvernance

• Organization boundary — le maximum que la politique d'une machine peut autoriser. Elle est Set by your organization (bromure.io), Set on this Mac (avec Set from file… et Effacer), ou None set. Chaque enregistrement qui modifie une politique est vérifié par rapport à elle, avec le openshell-prover de NVIDIA quand il est installé, sinon avec la vérification intégrée de Bromure. Une politique hors de la limite est refusée avec le résumé de la limite, où qu'elle ait été modifiée — le volet, le tiroir Sandbox, le conseiller ou l'API.
• Revision history — chaque enregistrement qui modifie la politique est conservé comme une version (vN, avec sa date, l'origine du changement et une empreinte courte). Restaurer recharge une version dans l'éditeur.
• Rules Bromure adds automatically — comme les règles de fournisseur d'OpenShell, elles gardent joignables les agents de la machine et chaque identifiant qu'elle configure. Elles ne font pas partie de la politique exportée.

Ce que voit l'agent quand il est bloqué

Une connexion que la politique refuse échoue aussitôt, sans socket suspendu. Sous une politique OpenShell, une connexion via le proxy ou une requête inspectée refusée reçoit un HTTP 403 avec le corps policy_denied propre à OpenShell : la couche, l'hôte et le port (ou la méthode et le chemin), et la règle ou la raison. Quand le conseiller de politique est activé, le corps dit aussi à l'agent comment proposer une règle à http://policy.local. Avec Tell the agent when policy blocks it activé (voir Garde-fous), l'agent apprend aussi, dans sa conversation, ce qu'il a tenté, que la politique l'interdit, et qu'il doit vous demander au lieu de contourner.

Référence des réglages

La table des règles et l'éditeur de politique ne sont pas montrés dans les clients iPhone, iPad ou Vision Pro (« Outbound connection rules are edited on the Mac that runs this workspace. ») ; les règles et politiques posées sur le Mac s'appliquent quand même.

Chapitres liés

• Politique du bac à sable, bac à sable invité et sentinelle du noyau — le fonctionnement des moteurs.
• Garde-fous — les politiques d'identifiants et les protections communes aux deux moteurs.
• Identifiants — les profils de fournisseur OpenShell et les jetons de substitution d'identifiants.
• Vue d'ensemble et chronologie de sécurité — chaque blocage et chaque autorisation, par machine, et la lignée réseau.