L'API in modalità sandbox (SAPI) si basa sul progetto Sandbox2, ben consolidato. Questa pagina spiega l'architettura di progettazione di SAPI e i concetti chiave.
Panoramica
SAPI è progettata per fornire agli sviluppatori strumenti per preparare le librerie C/C++ per il sandboxing, nonché le API necessarie per la comunicazione con la versione in sandbox delle librerie C/C++.
Questo diagramma mostra l'architettura di una libreria C/C++ in modalità sandbox SAPI:
SAPI fornisce anche primitive per la sincronizzazione manuale e automatica (in base agli attributi del puntatore personalizzati) della memoria (array, strutture) tra le librerie SAPI e il codice host.
Infine, un'API Transactions di alto livello consente di monitorare le librerie SAPI e riavviarle in caso di errore (ad es. a causa di violazioni della sicurezza, arresti anomali o esaurimento delle risorse).
Sandbox2
Il progetto open source Sandbox2 è sviluppato e gestito dagli ingegneri della sicurezza di Google ed è la tecnologia di sandboxing principale utilizzata da SAPI. Sandbox2 contiene tre componenti principali: la normativa Sandbox, l'executor e l'Sandboxee.
Norme relative alla sandbox
I criteri sandbox definiscono l'ambiente di esecuzione con limitazioni per la libreria sandbox. Ciò si ottiene specificando quali chiamate di sistema possono essere eseguite. SAPI utilizza lo stesso meccanismo di Sandbox2. Per ulteriori informazioni su come progettare e definire una policy sandbox, consulta la sezione Policy sandbox e la pagina Guida introduttiva di Sandbox2.
SAPI utilizza una norma predefinita. In alternativa, puoi utilizzare una norma sandbox dedicata definendola in un file di intestazione sandbox.h e passandola come argomento nella regola di compilazione sapi_library.
Libreria con sandbox
Questa è la libreria C/C++ in sandbox che verrà eseguita nell'ambiente sandbox con limitazioni fornito da Sandbox2. In definitiva, la libreria in sandbox espone la funzionalità richiesta che può essere utilizzata dal codice host.
La libreria in sandbox è creata con la regola di compilazione sapi_library, in cui puoi specificare un criterio sandbox personalizzato che definisce l'ambiente di esecuzione con limitazioni. A seconda della libreria, potrebbe essere necessario scrivere codice wrapper o stub (vedi libcurl), ma non è previsto che tu modifichi il codice sorgente della libreria C/C++ durante la preparazione della versione SAPI.
Oggetto SAPI e stub RPC
L'oggetto SAPI è un oggetto C++ che espone l'API della libreria in sandbox. Inoltra le chiamate dal codice host allo stub RPC, che è incorporato nella libreria SAPI insieme alla libreria in sandbox.
Questi due elementi vengono generati automaticamente dal sistema di build utilizzando la regola di build sapi_library(). SAPI supporta due sistemi di compilazione: Bazel e CMake di Google.
Codice host
Il codice host implementa la logica fornita dalla libreria SAPI. È ciò che altrimenti consumerebbe la versione non sottoposta a sandbox della libreria C/C++. Pertanto, il codice host chiama le funzioni esportate dalla libreria SAPI, passando i dati alla sandbox e ricevendo i dati dalla sandbox.
Il codice host deve essere adattato per utilizzare la libreria SAPI. In particolare, non è possibile chiamare le funzioni della libreria perché si trova in un processo sandbox separato. Pertanto, SAPI fornisce strumenti che creano un oggetto SAPI che funge da proxy per le chiamate a una libreria SAPI.
Concetti
Regole di build Bazel
Il progetto SAPI fornisce due regole di build Bazel per il sandboxing di una libreria C/C++:
sapi_library(): crea tutti gli output necessari per eseguire il sandboxing della libreria C/C++ come Sandboxee di Sandbox2. L'output della build può essere utilizzato come dipendenza per la regolacc_binary()utilizzata per creare il binario del codice host.sapi_interface(): genera automaticamente l'intestazione che può essere inclusa nel file binario del codice host.
Per una spiegazione più esaustiva delle regole di build, vedi Regole di build.
Variabili
SAPI fornisce una serie di tipi speciali, chiamati tipi SAPI, che consigliamo di utilizzare nel codice host. Il motivo principale per cui sono necessari i tipi SAPI è l'isolamento del processo e quindi della memoria tra il codice host e la libreria in sandbox.
Per una spiegazione più esaustiva di questo argomento e una panoramica di alcuni tipi di SAPI comunemente utilizzati, consulta Variabili.
Transazioni
Come spiegato in precedenza, qualsiasi chiamata API a una libreria in modalità isolata viene passata a un livello RPC. Per poter gestire un errore in questo livello, devi implementare una gestione degli errori appropriata. Il modulo SAPI Transaction fornisce il meccanismo necessario per assicurarsi che tutte le chiamate a una libreria in sandbox vengano completate senza problemi a livello di RPC o vengano restituite con un errore pertinente.
Per una spiegazione più esaustiva di questo argomento, consulta la sezione Transazioni.
Per iniziare
Leggi la nostra pagina Guida introduttiva per configurare il tuo primo progetto API in sandbox.