Esecuzione di programmi potenzialmente dannosi su Linux

Sto scrivendo un programma che testerà i programmi scritti dagli studenti. Temo di non potermi fidare di loro e devo assicurarmi che non finisca male per il computer che lo esegue.

Stavo pensando di fare un utente con crash test con accesso limitato alle risorse di sistema ed eseguire programmi come quell'utente, ma da quello che ho trovato in rete finora, rendere un sistema virtuale sarebbe l'opzione più sicura ...

Qualcuno può aiutarmi a scegliere l'approccio giusto? La sicurezza è una grande preoccupazione per me. D'altra parte, non voglio una soluzione che sia eccessiva e perda molto tempo nel tentativo di imparare qualcosa di cui non ho davvero bisogno.

• La macchina virtuale può offrirti la massima sicurezza senza riavviare, ma le prestazioni più basse.

• Un'altra opzione, per una sicurezza ancora maggiore rispetto a una macchina virtuale: avviare un CD / DVD / pendrive "live" senza accesso al disco rigido (disabilitare temporaneamente l'HDD nel BIOS; se non è possibile, almeno non montare l'unità / smontalo, se montato automaticamente - ma questo è molto meno sicuro)

• Un contenitore docker è un'alternativa un po 'meno sicura a una macchina virtuale completa. Probabilmente la differenza cruciale (in termini di sicurezza) tra questi due è che i sistemi in esecuzione in docker utilizzano effettivamente il kernel del sistema host.

• Esistono programmi come isolato che creeranno un ambiente speciale e sicuro - questo è generalmente chiamato sandbox - quelli sono generalmente basati su chroot, con supervisione aggiuntiva - trova quello che fa per te.

• Un chroot semplice sarà il meno sicuro (specialmente per quanto riguarda l'esecuzione dei programmi), anche se forse un po 'più veloce, ma ... Dovrai costruire / copiare un intero albero radice separato e usare i mount di bind per /devecc. (Vedi Nota 1 sotto!). Quindi, in generale, questo approccio non può essere raccomandato, soprattutto se è possibile utilizzare un ambiente più sicuro e spesso più facile da configurare sandbox.

Nota 0: All'aspetto di un "utente speciale", come l'nobodyaccount: questo non fornisce quasi alcuna sicurezza, molto meno di un semplicechroot. Unnobodyutente può comunque accedere a file e programmi che hanno letto ed eseguono autorizzazioni impostate per altri . Puoi provarlo consu -s /bin/sh -c 'some command' nobody. E se hai file di configurazione / cronologia / cache accessibili a chiunque (per errore o falla di sicurezza minore), un programma in esecuzione connobodyle autorizzazioni può accedervi, grep per dati riservati (come "pass =" ecc.) E in molti modi lo inviano tramite la rete o altro.

Nota 1: Come ha sottolineato Gilles in un commento qui sotto , un semplice ambiente chroot fornirà pochissima sicurezza contro gli exploit che mirano all'escalation dei privilegi. Un unico chroot ha senso dal punto di vista della sicurezza, solo se l'ambiente è minimo, costituito solo da programmi confermati dalla sicurezza(ma permane il rischio di sfruttare potenziali vulnerabilità a livello di kernel) e tutti i programmi non attendibili in esecuzione nel chroot sono in esecuzione come utente che non esegue alcun processo al di fuori del chroot. Ciò che impedisce chroot (con le restrizioni menzionate qui) è la penetrazione diretta del sistema senza escalation di privilegi. Tuttavia, come notato da Gilles in un altro commento, anche quel livello di sicurezza potrebbe essere aggirato, consentendo a un programma di uscire dal chroot.

Usa una macchina virtuale. Niente di meno non fornisce molta sicurezza.

Qualche anno fa avrei potuto suggerire un utente chroot dedicato o qualcosa del genere. Ma l'hardware è diventato più potente e il software della macchina virtuale è diventato più facile da usare. Inoltre, gli attacchi standard sono diventati più sofisticati. Non c'è più motivo di non andare fino in fondo qui.

Consiglierei di eseguire VirtualBox. Puoi configurare la macchina virtuale in un paio di minuti, quindi installare una distribuzione Linux al suo interno. L'unica configurazione non predefinita che raccomando è la configurazione di rete: crea sia un'interfaccia "NAT" (per comunicare con il mondo) sia un'interfaccia "solo host" (in modo da poter copiare facilmente i file da e verso l'host, e ssh in la VM). Disabilita l'interfaccia NAT mentre esegui i programmi dei tuoi studenti¹; abilitarlo solo durante l'installazione o l'aggiornamento dei pacchetti software.

All'interno della macchina virtuale, creare un utente per studente.

¹ _{È possibile limitare l'interfaccia NAT a una whitelist di utenti, ma è più avanzata di quanto sia necessario in una configurazione semplice e precisa.}

ecco una spiegazione molto approfondita del perché l'utilizzo di Chroot è ancora un'opzione molto praticabile e perché il sistema operativo completo o la virtualizzazione completa dell'hardware sono particolarmente eccessivi in ​​scenari specifici.

non è altro che un mito che Chroot non sia una funzionalità di sicurezza. ci sono strumenti che costruiranno automaticamente il file system chroot per te, e Chroot è integrato in molte applicazioni tradizionali come una funzione di sicurezza intenzionale.

contrariamente alla credenza popolare, non tutte le situazioni richiedono una virtualizzazione completa del sistema operativo o una simulazione completa dell'hardware. questo può effettivamente significare avere più superficie d'attacco per cercare di coprire. a sua volta, il che significa un sistema meno sicuro . (presumibilmente per amministratori di sistema meno esperti)

le regole sono abbastanza semplici: non inserire nulla nel chroot che non sia necessario. non eseguire un demone come root. non eseguire un demone come qualsiasi utente che esegue un demone al di fuori del chroot.

rimuovere eventuali applicazioni non sicure, binari setuid, collegamenti simbolici / hardlink senza proprietario. rimontare le cartelle non necessarie usando nosuid, noexec e nodev. crea l'ultima versione stabile del demone in esecuzione dal sorgente. e, soprattutto, proteggere il sistema di base!

Ho intenzione di aggiungere questo, ben dopo che la domanda abbia ricevuto una risposta ufficiale: MAGIA: invecchiamento dannoso nei circuiti / core , che purtroppo è bloccato dietro il paywall di ACM. Il risultato finale della carta è che la larghezza molto piccola traccia nei circuiti in uso oggi invecchia durante l'uso e alla fine si guasta. Trovando le istruzioni corrette e ripetendole ripetutamente, un utente malintenzionato può far invecchiare rapidamente i circuiti integrati.

Nessuna VM o sandbox o contenitore o chroot jail impedirebbe questo tipo di distruzione dannosa dell'hardware. Gli autori dell'articolo hanno trovato tali sequenze di istruzioni, e hanno sperimentalmente invecchiato l'hardware fino al fallimento, ma non hanno dato via le istruzioni, quindi potrebbe non essere una vera minaccia per un po '.

Sugli unix derivati ​​da BSD (incluso Mac OS X) c'è una funzione chiamata sandbox. La manpage dice

DESCRIZIONE
La funzione sandbox consente alle applicazioni di limitare volontariamente l'accesso alle risorse del sistema operativo. Questo meccanismo di sicurezza ha lo scopo di limitare i potenziali danni nel caso in cui venga sfruttata una vulnerabilità. Non sostituisce altri controlli di accesso al sistema operativo.

Questo è separato dalla chrootstruttura che è anche disponibile.