A API de sandbox (SAPI, na sigla em inglês) foi criada com base no conhecido projeto Sandbox2. Esta página explica a arquitetura de design da SAPI e os principais conceitos.
Informações gerais
A SAPI foi projetada para fornecer aos desenvolvedores ferramentas para preparar bibliotecas C/C++ para sandbox, bem como as APIs necessárias para a comunicação com a versão em sandbox das bibliotecas C/C++.
Este diagrama mostra a arquitetura de uma biblioteca C/C++ em sandbox SAPI:
O 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 Transaction de alto nível permite o monitoramento de bibliotecas SAPI e as reinicia 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 do 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 no modo sandbox. Isso é alcançado ao esclarecer quais chamadas do sistema podem ser executadas. O SAPI usa o mesmo mecanismo que o Sandbox2. Consulte a seção Política do sandbox e a página de primeiros passos do Sandbox2 para obter mais informações sobre como criar e definir uma política de sandbox.
A SAPI usa uma política padrão. Você também pode usar uma política de sandbox dedicada, definindo-a em um arquivo de cabeçalho sandbox.h e transmitindo-a como um argumento na regra de compilação sapi_library.
Biblioteca no modo sandbox
Esta é a biblioteca C/C++ em sandbox que será executada no ambiente de sandbox restrito fornecido pelo Sandbox2. Por fim, a biblioteca no modo sandbox expõe a funcionalidade necessária que pode ser consumida pelo código do host.
A biblioteca em sandbox é criada com a regra de build sapi_library, na qual você pode especificar uma política de sandbox personalizada que define o ambiente de execução restrito. Dependendo da biblioteca, será necessário escrever um código wrapper ou de stub (consulte libcurl), mas não se espera que o código-fonte da biblioteca C/C++ seja alterado ao preparar a versão SAPI.
Objeto SAPI e stub de RPC
O objeto SAPI é um objeto C++ que expõe a API da biblioteca no modo sandbox. Ele encaminha chamadas do código de host para o stub de RPC, que é 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(). O SAPI é compatível com dois sistemas de compilação, o Bazel e o CMake do Google.
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 fora da sandbox da biblioteca C/C++. Assim, o código de host chama funções exportadas pela biblioteca SAPI, passando e recebendo dados do sandbox.
O código de host precisa ser adaptado para usar a biblioteca SAPI. Em especial, não é possível chamar as funções da biblioteca porque a biblioteca reside em um processo de sandbox separado. Dessa forma, o SAPI fornece ferramentas que criam um objeto SAPI que retransmite as chamadas para uma biblioteca SAPI.
conceitos
Regras de build do Bazel
O projeto SAPI fornece duas regras de compilação do Bazel para colocar uma biblioteca C/C++ no sandbox:
sapi_library(): cria todas as saídas necessárias para colocar a biblioteca C/C++ no sandbox como um Sandbox2 Sandbox2. A saída do build pode ser usada como dependência para a 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 ver uma explicação mais completa das regras de build, consulte Regras de build.
Variáveis
O SAPI oferece vários tipos especiais, chamados de tipos SAPI, que recomendamos usar no código host. A principal razão pela qual os tipos SAPI são necessários é devido ao processo e, portanto, ao isolamento da memória entre o código do host e a biblioteca em sandbox.
Para uma explicação mais completa sobre este tópico e uma visão geral de alguns tipos de SAPI usados com frequência, consulte Variáveis.
Transações
Como explicado acima, qualquer chamada de API para uma biblioteca no modo sandbox é transmitida por uma camada RPC. Para poder lidar com uma falha nessa camada, é necessário implementar o tratamento de erros adequado. O módulo de transação SAPI oferece o mecanismo necessário para garantir que todas as chamadas para uma biblioteca no modo sandbox sejam concluídas sem problemas no nível da RPC ou sejam retornadas com um erro relevante.
Para uma explicação mais completa sobre esse tópico, consulte Transações.
Como começar
Leia nossa página Vamos começar para configurar seu primeiro projeto de API no modo sandbox.