Política de sandbox

O painel Política de sandbox (no grupo Segurança, entre Salvaguardas e Cadeia de abastecimento) decide o que a VM de uma máquina pode alcançar e, com o motor OpenShell, o que os seus agentes podem fazer dentro da VM (uma máquina é um espaço de trabalho, no editor de definições). Chamava-se Firewall antes da 5.4; procurar firewall, openshell, sentry ou landlock nas definições continua a encontrá-lo.

O painel abre com uma única escolha, Sandbox engine (o motor de sandbox):

Como os motores funcionam, e como se encaixam nas restantes proteções do Bromure, é explicado em Política de sandbox, sandbox do convidado e sentinela do kernel. Esta página é a referência dos campos.

Mudar para OpenShell + Sentry preenche uma política vazia com a política predefinida da sua organização (ou a política inicial do Bromure) e liga a sentinela do kernel em Best effort. Voltar para Bromure Firewall quando existe uma política pergunta primeiro, Switch to the Bromure Firewall?, porque Discard OpenShell policy remove a política e desliga a sentinela do kernel (a menos que a sua organização a exija). Use primeiro Exportar… se quiser guardar a política.

As proteções que valem para os dois motores — avisar o agente quando a política o bloqueia, o vigilante dos agentes, as credenciais estritas, a interceção transparente e o desvio inseguro — estão em Salvaguardas › Proteções.

Firewall do Bromure

Regras de saída

«Permita ou recuse as ligações da VM por anfitrião, IP/CIDR, protocolo e porta — comparadas de cima para baixo, a primeira correspondência ganha.» As regras cobrem qualquer protocolo e qualquer destino. Tráfego sem correspondência define o que acontece a uma ligação que nenhuma regra apanha: Permitir (predefinição) ou Recusar para uma configuração em lista branca. Adicionar regra acrescenta uma linha.

«As regras aplicam-se à medida que as edita; Cancelar repõe-nas.» Não é preciso reiniciar nem Salvar: as novas ligações seguem logo as novas regras, e as que já estão abertas também. Desligar uma regra, removê-la, acrescentar uma regra de recusa, um limite de tempo que se esgota ou uma regra até parar que termina voltam a verificar todas as ligações abertas da máquina, e as que as novas regras recusam são cortadas dos dois lados. Desligar uma permissão temporária acaba mesmo com o acesso, em vez de deixar uma transferência aberta correr até ao fim.

• As ligações feitas através das definições de proxy (HTTPS_PROXY — o curl, o git, o npm e os agentes usam-nas por predefinição) são cortadas pelo próprio proxy: fecha o lado da VM e cancela o pedido ao servidor, WebSockets incluídos. A Linha do tempo de segurança regista cada uma como ligação fechada — “allow tcp …” já não a permite.
• As ligações diretas são cortadas pelo switch virtual no pacote seguinte: descarta-o e envia à VM um reset TCP, e para o tráfego HTTP(S) intercetado a ligação do proxy ao servidor também é fechada.

Se as regras mudarem fora do editor enquanto ele está aberto — uma ação da Linha do tempo de segurança, ou um limite de tempo que se esgota —, a alteração é fundida com as suas edições por guardar. Se tinha editado as mesmas regras, o painel pergunta: Recarregar ou Manter minhas edições.

Regras temporárias

Algumas regras só são precisas por um momento — chegar ao GitHub ou ao registo do npm o tempo suficiente para atualizar dependências, por exemplo. Em vez de acrescentar a regra e lembrar-se de a apagar, defina um limite de tempo com o menu de relógio da regra:

• Ativa por 15 minutos / Ativa por 1 hora — a regra deixa de corresponder no momento em que o tempo acaba, mesmo que o Bromure esteja ocupado; pouco depois é desligada e guardada assim, para ficar na lista para a próxima vez.
• Ativa até o espaço de trabalho parar — a regra é desligada quando a máquina para (ou reinicia), e no próximo arranque do Bromure se ainda estava em execução quando a app saiu.

Para voltar a usar a regra mais tarde, marque-a ou escolha um novo limite de tempo.

A forma mais rápida de permitir algo que acabou de ser bloqueado é a gaveta Sandbox na janela da máquina, ou Permitir… na linha bloqueada da Linha do tempo de segurança. Ambas oferecem Sempre, Por 15 minutos, Por 1 hora e Até o espaço de trabalho parar.

Formato pf

A divulgação formato pf mostra as mesmas regras como texto — uma por linha, acabando em default allow ou default deny — que é como são guardadas e o que a CLI e os perfis geridos usam:

allow tcp api.github.com:443
allow web api.example.com GET,POST     # só estes verbos chegam ao site
deny  web api.internal PUT,DELETE      # bloquear estes verbos, permitir o resto
deny  udp any:53
deny  any 10.0.0.0/8
default deny

As regras desligadas e temporárias levam uma nota curta num comentário, para que o texto continue a ser pf simples:

#@off allow tcp registry.npmjs.org:443          # desligada
allow tcp github.com:443 #@until=1767225600      # ligada até esta hora (segundos Unix)
allow tcp pypi.org:443 #@until=stop              # ligada até a máquina parar

A aplicação acontece no Mac, em duas camadas: o comutador de rede virtual verifica cada ligação pelo IP de destino e pelo nome de anfitrião visto no DNS (todos os protocolos), e o proxy verifica outra vez pelo nome de servidor TLS e, para as regras web, pelo método HTTP. É isso que permite a uma máquina ler uma API em que não pode escrever: allow web api.example.com GET,POST dá ao agente consultas sem alterações, qualquer que seja a ferramenta que use.

Cada decisão é registada na Linha do tempo de segurança, com a regra que a tomou, e nos Macs inscritos enviada à sua organização.

Registar as ligações permitidas

As ligações bloqueadas são sempre registadas. Registrar conexões permitidas, sob a escolha Tráfego sem correspondência, decide se as ligações que a firewall deixa passar também são registadas — é isso que dá às suas linhas as ações rápidas Bloquear… e Regra…. Enquanto não escolher, está ligado quando a máquina tem regras (ou recusa o tráfego sem correspondência) e desligado numa máquina sem firewall, para que uma máquina sem regras não encha a Linha do tempo de linhas “permitido”.

As ligações permitidas fazem pouco ruído de qualquer forma: uma linha por destino (anfitrião, porta e protocolo — um anfitrião atrás de vários endereços é uma linha) no máximo uma vez por minuto, e as repetições juntam-se à linha anterior com uma contagem. O endpoint dos modelos locais no Mac nunca é listado.

Nota: os modelos locais estão sempre alcançáveis: uma regra de permissão para o ponto final de inferência no Mac é posta à frente das suas regras, de modo que nem um default deny consegue cortar os agentes de um modelo no dispositivo.

A sentinela do kernel sob o firewall

A sentinela do kernel pertence ao motor OpenShell. Uma máquina que ainda a corre sob o firewall do Bromure mostra um cartão Kernel sentry is still on com Turn off, ou — quando a sua organização exige a sentinela — «Your organization requires at least …» e nenhum controlo.

OpenShell + Sentry

As definições do motor estão dispostas em cinco cartões.

Política

«Tudo é recusado a menos que uma regra o permita. Aplica-se ao vivo.» O cartão Policy contém a própria política: uma política de sandbox NVIDIA OpenShell, versão de esquema 1, em YAML. As ligações só são permitidas por uma regra network_policies; um endpoint com um protocol é inspecionado pedido a pedido, onde enforce bloqueia e audit apenas regista. As alterações aplicam-se a uma máquina em execução sem reinício.

Os botões do cartão:

• Importar… — substitui a política por um ficheiro .yaml / .yml.
• Exportar… — guarda-a como <machine>-policy.yaml.
• Reset to starter policy — a política inicial permite o GitHub (github.com, api.github.com, **.githubusercontent.com na 443), o npm e o PyPI só de leitura (inspecionados, em enforce), e os espelhos de pacotes do Ubuntu na 80/443.

Por baixo do editor, uma linha de verificação mostra Valid policy · N network rules (a verde) ou o erro de análise (a vermelho), seguida de eventuais avisos. Com Enforce binaries ligado, as regras que não listam nenhum binaries são assinaladas a laranja: não permitem nada.

Sentinela do kernel

«Transmite os eventos de segurança (lançamentos de processos, mudanças de privilégios, carregamentos de módulos e de BPF, recusas da sandbox) do kernel da VM para o Bromure, fora do alcance de tudo o que o agente consegue parar; depois de arrancar, o kernel é trancado para que nem o root na VM consiga carregar código para interferir.» Um silêncio ou uma falha no fluxo conta como adulteração para o vigilante dos agentes.

Mode aplica-se no próximo arranque da VM. Quando a sua organização define um mínimo, aplica-se o mais estrito dos dois, e Best effort fica a cinzento sob um mínimo Required («Your organization requires it.»). Uma máquina configurada antes de a sentinela vir com o motor mostra Off for this workspace com Turn on.

A linha de estado do cartão diz Connected · kernel versão ou Not connected, quantos eventos se perderam sob carga, se for o caso, e Couldn't start: motivo a vermelho quando a VM não conseguiu carregar a sentinela. Veja a sentinela do kernel para saber como os seus módulos são entregues.

Sandbox

O título do cartão fica laranja, Sandbox ⚠︎, quando a VM comunica um problema: a sandbox do sistema de ficheiros ou a sandbox estrita não se aplicou, a sentinela não está disponível quando é esperada, ou o convidado enviou avisos.

As linhas de estado por baixo de Enforce binaries e Filesystem & process dizem o que a VM aplicou de facto:

• Attestor connected: binaries are enforced, ou Attestor not connected: until it is, only Bromure's own rules apply.
• Filesystem seguido do seu estado, do utilizador com que o agente corre e da versão do Landlock, ou Filesystem not applied yet antes de a VM comunicar.
• Os caminhos que o Bromure acrescenta para a sua própria canalização (Added for Bromure: …).
• Quando o sistema de ficheiros está confinado mas os binários não são impostos: «The agent keeps sudo, so it could stop Bromure's processes in the VM. Turn on Enforce binaries to prevent that.»
• A vermelho, quando a sandbox estrita não se aplicou: «no session will start and binary rules fail closed. Restarting the VM retries it.»

Conselheiro de políticas

Quando um pedido é bloqueado, o agente pode propor a regra estreita de que precisa em http://policy.local (a API do conselheiro do OpenShell) e esperar pela sua decisão. As ligações bloqueadas também são redigidas aqui como propostas.

Cada proposta pendente mostra a sua regra e o destino, se foi drafted from a block (redigida a partir de um bloqueio) ou proposed by the agent (proposta pelo agente), a intenção declarada pelo agente, o YAML, e eventuais constatações de risco a laranja. Escreva uma Reason (sent to the agent on reject) se quiser, depois Reject ou Approve. Uma regra aprovada é acrescentada à política e aplica-se ao vivo. Recent decisions lista as últimas cinco. As mesmas propostas aparecem na gaveta Sandbox.

Governação

• Organization boundary — o máximo que a política de qualquer máquina pode permitir. É Set by your organization (bromure.io), Set on this Mac (com Set from file… e Limpar), ou None set. Cada gravação que altera uma política é verificada contra ele, com o openshell-prover da NVIDIA quando está instalado, caso contrário com a verificação integrada do Bromure. Uma política fora do limite é recusada com o resumo do limite, onde quer que tenha sido editada — o painel, a gaveta Sandbox, o conselheiro ou a API.
• Revision history — cada gravação que altera a política é guardada como uma versão (vN, com a data, a origem da alteração e um hash curto). Restaurar carrega uma versão de volta no editor.
• Rules Bromure adds automatically — tal como as regras de fornecedor do OpenShell, mantêm alcançáveis os agentes da máquina e cada credencial que ela configura. Não fazem parte da política exportada.

O que o agente vê quando é bloqueado

Uma ligação que a política recusa falha de imediato, sem socket pendurado. Sob uma política OpenShell, uma ligação pelo proxy ou um pedido inspecionado recusado recebe um HTTP 403 com o corpo policy_denied próprio do OpenShell: a camada, o anfitrião e a porta (ou o método e o caminho), e a regra ou o motivo. Quando o conselheiro de políticas está ligado, o corpo também diz ao agente como propor uma regra em http://policy.local. Com Tell the agent when policy blocks it ligado (veja Salvaguardas), o agente também fica a saber, na sua conversa, o que tentou, que a política o proíbe, e que lhe deve perguntar em vez de contornar.

Referência de definições

A tabela de regras e o editor de políticas não são mostrados no cliente iPhone, iPad ou Vision Pro («Outbound connection rules are edited on the Mac that runs this workspace.»); as regras e políticas postas no Mac continuam a aplicar-se.

Capítulos relacionados

• Política de sandbox, sandbox do convidado e sentinela do kernel — como os motores funcionam.
• Salvaguardas — as políticas de credenciais e as proteções comuns aos dois motores.
• Credenciais — os perfis de fornecedor OpenShell e os marcadores de credenciais.
• Visão geral e linha do tempo de segurança — cada bloqueio e cada permissão, por máquina, e a linhagem de rede.