Esecuzione di programmi potenzialmente dannosi su Linux

• Macchina virtuale può darti la massima sicurezza senza riavvio, 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 (disabilita temporaneamente l'HDD nel BIOS; se non puoi, almeno non montare l'unità / smontarla, se montata automaticamente, ma questo è molto meno sicuro)

• Una finestra mobile container è un'alternativa un po' meno sicura rispetto a una macchina virtuale completa. Probabilmente la differenza cruciale (in termini di sicurezza) tra questi due è che i sistemi in esecuzione nella finestra mobile utilizzano effettivamente il kernel del tuo sistema host.

• Ci sono programmi come isolate che creeranno un ambiente speciale e protetto, generalmente chiamato sandbox - quelli sono in genere basati su chroot, con supervisione aggiuntiva - trova quello che fa per te.

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

Nota 0: All'aspetto di un "utente speciale", come il nobody account:Questo pochissimo sicurezza, molto meno di un semplice chroot . Un nobody l'utente può ancora accedere a file e programmi che sono stati letti ed esegui autorizzazioni impostate per other . Puoi testarlo con su -s /bin/sh -c 'some command' nobody . E se hai un file di configurazione/cronologia/cache accessibile a chiunque (a causa di un errore o di una piccola falla di sicurezza), un programma in esecuzione con nobody i permessi di possono accedervi, grep per dati riservati (come "pass=" ecc.) e in molti modi inviarli in rete o altro.

Nota 1: Come ha sottolineato Gilles in un commento qui sotto, un semplice ambiente chroot darà pochissima sicurezza contro gli exploit che mirano all'escalation dei privilegi. Un solo chroot ha senso dal punto di vista della sicurezza, solo se l'ambiente è minimo, costituito solo da programmi con sicurezza confermata (ma rimane ancora il rischio di sfruttare potenziali vulnerabilità a livello di kernel) e tutti i programmi non attendibili in esecuzione nel chroot vengono eseguiti come un utente che non esegue alcun processo al di fuori del chroot. Ciò che chroot impedisce (con le restrizioni menzionate qui), è la penetrazione diretta del sistema senza escalation dei privilegi. Tuttavia, come ha notato 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. Qualcosa di meno non fornisce molta sicurezza.

Qualche anno fa avrei potuto suggerire un utente dedicato al chroot o qualcosa del genere. Ma l'hardware è diventato più potente e il software della macchina virtuale è diventato più facile da usare. Inoltre, gli attacchi preconfezionati sono diventati più sofisticati. Non c'è più alcun motivo per non fare tutta la strada 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" (così puoi facilmente copiare file da e verso l'host e ssh in il VM). Disabilita l'interfaccia NAT mentre esegui i programmi degli studenti¹; abilitalo solo quando stai installando o aggiornando i pacchetti software.

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

¹ _{Puoi restringere l'interfaccia NAT a una lista bianca di utenti, ma è più avanzato di quanto ti serva in una configurazione semplice e mirata.}

ecco una spiegazione molto approfondita del motivo per cui l'utilizzo di Chroot è ancora un'opzione molto praticabile e del motivo per cui il sistema operativo completo o la virtualizzazione hardware completa è particolarmente eccessivo in scenari specifici.

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

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

le regole sono abbastanza semplici:non inserire nulla all'interno del chroot che non sia necessario. non eseguire un demone come root. non eseguire un demone come qualsiasi altro 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 utilizzando nosuid, noexec e nodev. crea l'ultima versione stabile del demone in esecuzione dal sorgente. e, soprattutto, proteggi il sistema di base!