Domande frequenti

Posso utilizzare i thread?

Sì, i thread sono supportati in Sandbox2.

Tutti i thread devono essere sottoposti a sandbox

Per via del funzionamento di Linux, il criterio seccomp-bpf viene applicato solo al thread attuale: questo significa che il criterio non viene applicato ad altri thread esistenti, ma i thread futuri erediteranno il criterio:

• Se usi Sandbox2 nella prima modalità in cui la sandbox è attivata prima del giorno execve(), tutti i thread erediteranno il criterio e non ci sarà alcun problema. Questa è la modalità di sandbox preferita.
• Se stai utilizzando la seconda modalità in cui l'esecutore ha set_enable_sandbox_before_exec(false) e la sandbox viene mostrata all'esecutore quando vuole essere sandbox con SandboxMeHere(), assicurati che il filtro sia applicato a tutti i thread. In caso contrario, c'è il rischio di un attacco sandbox: il codice dannoso potrebbe passare da un thread con sandbox a un thread con sandbox.

Nota: il kernel Linux ha introdotto il flag TSYNC nella versione 3.17, che consente di applicare un criterio a tutti i thread. Prima di questo flag era possibile applicare il criterio solo thread per thread. Se Sandbox2 rileva che è in esecuzione su un kernel senza supporto TSYNC e chiami SandboxMeHere() da un programma multi-thread, Sandbox2 verrà interrotto, in quanto ciò comprometterebbe la sicurezza della sandbox.

Come faccio a compilare la mia sandbox?

Se non fai attenzione, puoi ereditare molte dipendenze ed effetti collaterali (chiamate di sistema aggiuntive, accessi ai file o anche connessioni di rete) che rendono più difficile la limitazione tramite sandbox (rilevando tutti gli effetti collaterali) e meno sicuri (perché i criteri syscall e file sono più ampi). Alcune opzioni di compilazione possono aiutare a ridurre questi problemi:

• Compila il file binario di Sandboxee in modo statico per evitare il collegamento dinamico, che utilizza molte chiamate di sistema (open/openat, mmap e così via).

• Poiché Bazel aggiunge pie per impostazione predefinita, ma il feed statico non è compatibile, considera di utilizzare il flag funzionalità per forzarlo attraverso le seguenti opzioni nelle regole cc_binary:

  linkstatic = 1,
  features = [
      "fully_static_link",  # link libc statically
      "-pie",
  ],
  

Tuttavia: l'utilizzo del feed statico offre lo svantaggio di ridurre l'entropia dell'heap ASLR (da 30 bit a 8 bit), semplificando gli exploit. Decidi con attenzione cosa è meglio in base all'implementazione e al criterio della sandbox:

• non statico: un buon ASLR heap, potrebbe essere più difficile ottenere l'esecuzione del codice iniziale, ma a un criterio sandbox meno efficace, potrebbe risultare più facile da uscire.
• statico: il linguaggio ASLR heap è potenzialmente più semplice ottenere l'esecuzione iniziale del codice, ma un criterio sandbox più efficace, potenzialmente più difficile da uscire.

Questa è una scelta spiacevole perché il compilatore non supporta la PIE statica (Position Independent Executable). Il PIE viene implementato perché il programma binario è un oggetto dinamico e il caricatore lo mappa in una posizione casuale prima di eseguirlo. Quindi, poiché l'heap viene tradizionalmente posizionato a un offset casuale dopo l'indirizzo di base del programma binario (e espanso con brk syscall), questo significa che per i programmi binari statici l'entropia dell'ASLR dello heap è solo questo offset perché non è previsto un PIE.

Per esempi di queste opzioni di compilazione, guarda l'esempio statico di esempio BUILD.bazel: static_bin.cc è compilato in modo statico, il che ci consente di avere criteri di syscall molto precisi. Questo approccio si presta bene anche per il sandbox di programmi binari di terze parti.

Posso sandbox con programmi binari x86 a 32 bit?

Sandbox2 può limitare tramite sandbox solo la stessa architettura utilizzata per la compilazione.

Inoltre, il supporto per x86 a 32 bit è stato rimosso da Sandbox2. Se provi a utilizzare un esecutore x86 a 64 bit per sandbox di un programma binario x86 a 32 bit o un programma binario x86 a 64 bit che effettua chiamate di sistema a 32 bit (tramite int 0x80), entrambi genereranno una violazione della sandbox che può essere identificata dall'etichetta dell'architettura [X86-32].

Il motivo alla base di questo comportamento è che i numeri di syscall sono diversi tra le architetture e, poiché il criterio syscall è scritto nell'architettura dell'esecutore, può essere pericoloso consentire un'architettura diversa per Sandboxee. In effetti, questo potrebbe portare a una syscall apparentemente innocua, che in realtà significa che un'altra syscall più dannosa potrebbe aprire la sandbox per fuga.

Esistono limiti al numero di sandbox che un processo di esecutore può richiedere?

Per ogni istanza di Sandboxee (nuovo processo generato dal forkserver), viene creato un nuovo thread, che è il limite.

Un esecutore può richiedere la creazione di più sandbox?

No. Esiste una relazione 1:1: un'istanza di Executor archivia il PID di Sandboxee, gestisce l'istanza Comms nell'istanza Sandbox e così via.

Perché appare il messaggio "Funzione non implementata" all'interno di forkserver.cc?

Sandbox2 supporta l'esecuzione solo su kernel ragionevolmente nuovi. Il nostro attuale limite è il kernel 3.19, anche se potrebbe cambiare in futuro. Il motivo è che stiamo utilizzando funzionalità del kernel relativamente nuove, tra cui gli spazi dei nomi degli utenti e seccomp con il flag TSYNC.

Se stai eseguendo una produzione, questo non dovrebbe essere un problema, perché l'intero parco risorse esegue un kernel sufficiente. In caso di problemi, contattaci.

Se utilizzi Debian o Ubuntu, aggiornare il kernel è facile come eseguire:

sudo apt-get install linux-image-<RECENT_VERSION>