A API em sandbox (SAPI, na sigla em inglês) é criada com base no projeto Sandbox2. Esta página explica a arquitetura de design da SAPI e os principais conceitos.
Visão geral
A SAPI foi projetada para fornecer aos desenvolvedores ferramentas para preparar bibliotecas C/C++ para sandbox, bem como as APIs necessárias para comunicação com a versão em sandbox das bibliotecas C/C++.
Este diagrama mostra a arquitetura de uma biblioteca C/C++ em sandbox da SAPI:
A SAPI também fornece primitivos para sincronização de memória manual e automática (com base em atributos de ponteiro personalizados) (matrizes, estruturas) entre as bibliotecas SAPI e o código do host.
Por fim, uma API de transações de alto nível permite monitorar as bibliotecas SAPI e reiniciá-las em caso de falha (por exemplo, devido a violações de segurança, falhas ou esgotamento de recursos).
Sandbox2
O projeto de código aberto Sandbox2 é desenvolvido e mantido por engenheiros de segurança do Google e é a principal tecnologia de sandbox usada pela SAPI. O Sandbox2 contém três componentes principais: a política de sandbox, o executor e o sandboxee.
Política de sandbox
A política de sandbox define o ambiente de execução restrito para a biblioteca em sandbox. Isso é feito esclarecendo quais syscalls podem ser executadas. A SAPI usa o mesmo mecanismo do Sandbox2. Consulte a seção Política de sandbox e a página Introdução para Sandbox2 para mais informações sobre como criar e definir uma política de sandbox.
Por padrão, as classes de sandbox SAPI geradas são inicializadas usando
DefaultConfig
(sapi::SandboxConfig::DefaultConfig()). DefaultConfig() configura o
sandbox com:
- Uma política padrão do Sandbox2 criada com
sapi::Sandbox2Config::DefaultPolicyBuilder() - Limites de tempo e recursos padrão de
sapi::Sandbox2Config::DefaultLimits() - Comunicação de memória compartilhada ativada (combinada com as permissões de memória compartilhada em
DefaultPolicyBuilder()) - Flags de linha de comando padrão (
sapi::SandboxConfig::DefaultFlags()) e variáveis de ambiente (sapi::SandboxConfig::DefaultEnvironmentVariables()), que configuram o registro de base e o comportamento de execução no sandboxee
Para personalizar a política ou configuração do sandbox, comece com
sapi::SandboxConfig::DefaultConfig(), modifique o
sapi::SandboxConfig retornado e transmita-o para o construtor de sandbox gerado ou
defina uma subclasse de sandbox personalizada em um arquivo principal sandbox.h transmitido à regra de build
sapi_library. Por exemplo, é possível criar uma política começando com
sapi::Sandbox2Config::DefaultPolicyBuilder() e encadeando outras regras ou
construir um
PolicyBuilder
diretamente quando uma configuração mais restritiva for necessária. Ao adicionar
flags ou variáveis de ambiente, comece com sapi::SandboxConfig::DefaultFlags()
ou sapi::SandboxConfig::DefaultEnvironmentVariables() para que as configurações de base sejam
preservadas.
Biblioteca em sandbox
Essa é a biblioteca C/C++ em sandbox que será executada no ambiente de sandbox restrito fornecido pelo Sandbox2. Em última análise, a biblioteca em sandbox expõe a funcionalidade necessária que pode ser consumida pelo código do host.
A biblioteca em sandbox é criada com a sapi_library regra de build, em que é possível especificar uma política de sandbox personalizada que define o ambiente de execução restrito. Dependendo da biblioteca, talvez seja necessário escrever um wrapper ou um código stub (consulte libcurl), mas não é esperado que você mude o código-fonte da biblioteca C/C++ ao preparar a versão da SAPI.
Objeto SAPI e stub RPC
O objeto SAPI é um objeto C++ que expõe a API da biblioteca em sandbox. Ele encaminha chamadas do código do host para o stub RPC, que está incorporado na biblioteca SAPI junto com a biblioteca em sandbox.
Esses dois elementos são gerados automaticamente pelo sistema de build usando a regra de build sapi_library(). A SAPI oferece suporte a dois sistemas de build: o
Bazel do Google e o CMake.
Código do host
O código do host é o que implementa a lógica fornecida pela biblioteca SAPI. É o que, de outra forma, consumiria a versão não em sandbox da biblioteca C/C++. Assim, o código do host chama funções exportadas pela biblioteca SAPI, transmitindo e recebendo dados do sandbox.
O código do host precisa ser adaptado para usar a biblioteca SAPI. Principalmente, não é possível chamar as funções da biblioteca porque ela reside em um processo em sandbox separado. Portanto, a SAPI fornece ferramentas que criam um objeto SAPI que faz proxy de chamadas para uma biblioteca SAPI.
Conceitos
Regras de build do Bazel
O projeto SAPI fornece duas regras de build do Bazel para colocar uma biblioteca C/C++ em sandbox:
sapi_library(): cria todas as saídas necessárias para que a biblioteca C/C++ seja colocada em sandbox como um Sandboxee do Sandbox2. A saída de build pode ser usada como uma dependência da regracc_binary()usada para criar o binário do código do host.sapi_interface(): gera automaticamente o cabeçalho que pode ser incluído no binário do código do host.
Para uma explicação mais detalhada das regras de build, consulte Regras de build.
Variáveis
A SAPI fornece vários tipos especiais, chamados de tipos SAPI, que recomendamos usar no código do host. O principal motivo para a necessidade de tipos SAPI é o processo e, portanto, a isolamento de memória entre o código do host e a biblioteca em sandbox.
Para uma explicação mais detalhada desse tópico e uma visão geral de alguns tipos SAPI usados com frequência, consulte Variáveis.
Transações
Conforme explicado acima, qualquer chamada de API para uma biblioteca em sandbox é transmitida por uma camada RPC. Para processar uma falha nessa camada, é necessário implementar o tratamento de erros adequado. O módulo de transação SAPI fornece o mecanismo necessário para garantir que todas as chamadas para uma biblioteca em sandbox sejam concluídas sem problemas no nível de RPC ou sejam retornadas com um erro relevante.
Para uma explicação mais detalhada desse tópico, consulte Transações.
Primeiros passos
Leia nossa página Introdução para configurar seu primeiro projeto de API em sandbox.