Nelle discussioni sulla sicurezza, spesso emerge l'argomento della sandboxing. Che cos'è l'applicazione sandboxing? Come funziona e quali sono le vulnerabilità della sicurezza che impedisce?
Una "sandbox" è un'area giochi per bambini piccoli: dovrebbe essere sicura per loro (non possono ferire se stessi) e da sicuri (è sabbia, non possono romperli) . Nel contesto della sicurezza IT, "sandboxing" significa isolare una parte di software in modo tale che qualunque cosa faccia, non diffonderà il caos altrove.
Un comune modo Unix di sandboxing è il comando chroot (che utilizza la chiamata di sistema chroot() ). Un processo avviato con questo comando vede solo una sottodirectory (quella che vede come root del filesystem, '/' , è quella sottodirectory). Il sistema FreeBSD ha una versione avanzata . Soluzioni più moderne e complete utilizzano macchine virtuali (come in VMWare ). Questo tipo di sandboxing è pensato per il contenimento dei danni: si inserisce un determinato processo in una prigione perché nel caso in cui venga violato, ad esempio, un buffer overflow, l'hacker è ancora in prigione e non sarà in grado di influenzare altre applicazioni in esecuzione lo stesso sistema.
Un altro tipo di sandboxing è quello che si trova al centro di linguaggi di programmazione come Java o C # (chiamato anche "macchina virtuale"): il codice dell'applicazione viene eseguito su una CPU virtuale in cui ogni singolo codice operativo viene controllato per le violazioni (buffer overflow e underflow, tipo mismatches ...). La struttura delle lingue e della VM sono state progettate in modo che questi controlli non siano troppo costosi. Anche in questo caso, questo è il contenimento dei danni, ma con una granularità più fine.
Sandboxing non rimuove le vulnerabilità; riduce solo le conseguenze di tali vulnerabilità (ad esempio trasformando una shell remota in un crash remoto). Un buffer overflow è un bug, indipendentemente dal fatto che una VM lo intrappoli o meno.
Ok, quindi in primo luogo, come funzionano le applicazioni?
Su un sistema operativo standard del tipo che probabilmente stai usando in questo momento, le applicazioni vengono lanciate dagli utenti. Quando un'applicazione viene avviata, viene caricata in memoria e viene dato il tempo necessario per l'esecuzione sulla CPU.
Per ottenere risultati, piuttosto che controllare direttamente l'hardware del computer, l'applicazione effettua richieste del sistema operativo. Gli sviluppatori chiamano queste chiamate di sistema o chiamate API. In sostanza, tutto ciò che fa un programma è un'operazione sulla sua memoria o una chiamata di sistema per fare qualcos'altro.
Ora, ovviamente, non possiamo semplicemente caricare le applicazioni e lasciare che facciano qualsiasi cosa, perché altrimenti gli utenti potrebbero fare qualsiasi cosa. Quindi, il sistema operativo che stai usando in questo momento ha un concetto di permessi. Quando viene effettuata una chiamata di sistema, il sistema operativo esamina il contesto dell'applicazione: chi lo sta eseguendo? - e le autorizzazioni sulla risorsa in questione. Dico risorsa piuttosto che file perché regedt32 ti consente di impostare le autorizzazioni sulle chiavi di registro e solo root può aprire i socket sotto la porta 1024 su Linux.
Quindi cosa può fare un'applicazione? Qualunque cosa tu possa fare Chiaramente, questo è ok per dire Windows Explorer, ma diciamo che si scarica un altro programma, come un convertitore da PDF a audio (solo un suggerimento casuale). Non sei sicuro di fidarti di "Ninefingerz-so-l33t-man", lo sviluppatore che l'ha implementato, ma se lo esegui, ha accesso a tutto ciò che fai.
L'applicazione sandboxing consiste nell'impedire che a un certo livello. Strumenti come sandboxie o SELinux sandbox agganciare quelle chiamate del sistema operativo e controllare a un livello più fine che cosa può fare quel programma. Ad esempio, potresti consentire al programma di modificare qualsiasi cosa sotto C:\Users\Ninefingers\temporaryisolateddata , ma ovunque altro è di sola lettura. È possibile che impedisca di creare connessioni in uscita sui socket o di leggere il registro.
Ovviamente, non è l'unico modo (aggancio del kernel) per implementare una sandbox. La sandbox di Google Chrome su Windows è interamente implementata dal programma - il processo master di google chrome controlla ciò che i processi figlio può accedere, in poche parole. Questa sandbox funziona sfruttando i controlli di sicurezza esistenti in Windows, consentendo solo al processo secondario di comunicare al processo di destinazione quando vuole intraprendere un'azione che normalmente otterrebbe tramite una chiamata di sistema. In questo modo, il processo di destinazione esegue il filtraggio delle richieste.
Al suo interno, l'applicazione sandboxing prevede restrizioni aggiuntive per impedire che processi potenzialmente dannosi possano danneggiare il sistema. È un'estensione del modello di autorizzazioni esistente.
Si noti che il Controllo di accesso obbligatorio, una funzionalità disponibile in alcuni sistemi operativi, dovrebbe, se implementato correttamente, sandboxare tutto in base a chi è l'utente e qual è il processo.
Il sandboxing è un meccanismo per il controllo del flusso di informazioni. Eseguendo del codice in una sandbox, ottieni un controllo aggiuntivo sugli input e gli output del programma. Ciò significa che puoi negare / mediare l'accesso a dati esterni o ad altre risorse nel caso in cui il programma in modalità sandbox sia compromesso o dannoso.
Spesso, nella sandbox è incluso un ambiente di esecuzione complesso, ad esempio librerie Java e Java in caso di sandbox basate su JVM. Oppure puoi eseguire un'applicazione all'interno di una VM dedicata, trasformandola in una sandbox per te con un sistema operativo legacy completo come ambiente di esecuzione.
A mia conoscenza, la tecnologia sandbox all'avanguardia per l'esecuzione di x86 è descritta nel Java Native Client di Google: link
Il concetto di controllo del flusso di informazioni è essenziale per la progettazione della sicurezza. Tutto ciò che riguarda i privilegi e il MAC in Linux è tutto sul controllo del flusso di informazioni. Di conseguenza, DJB nota nel suo articolo "Alcune considerazioni sulla sicurezza dopo dieci anni di qmail 1.0" che il flusso di informazioni e le interfacce sono sostanziali e il "minimo privilegio" non è altro che una distrazione. Tuttavia, non ha usato sandbox esplicite come una JVM completa, ha usato la funzionalità del sistema operativo standard per suddividere qmail in diversi piccoli programmi con interfacce esplicite e ben definite. In effetti, le sandbox sono progettate non molto più di una replica / messa a punto / miglioramento di ciò che il sistema operativo (dovrebbe) fornire.
Leggi altre domande sui tag sandbox attack-prevention