Soluzione 1:
Come ha detto @Some Guy, devi pensare a questo in una prospettiva storica.
La prospettiva storica era che un singolo componente hardware fosse una dozzina di servizi diversi sotto un unico sistema operativo. Se un servizio è stato compromesso, allora tutto su quell'hardware è stato compromesso.
Con la virtualizzazione questo è molto meno un problema. Sebbene non sia impossibile uscire da una VM, è tutt'altro che banale. È certamente più difficile uscire da una VM di quanto non lo sia per un processo in esecuzione con privilegi di root uscire da un chroot. Quindi i miei server di bind sono in esecuzione sulla propria VM. In questo caso non ha davvero molto senso usare un chroot poiché il danno è già limitato semplicemente dal fatto che si tratta di una VM.
Un chroot è un tentativo molto debole di creare qualcosa come una VM. I chroot possono essere sfuggiti da qualsiasi processo con privilegi di root. Un chroot non è previsto e non funziona come meccanismo di sicurezza. Un chroot con una jail BSD o LXC ti offre la virtualizzazione a livello di sistema operativo e fornisce funzionalità di sicurezza. Ma oggigiorno, dato che è così facile avviare una nuova VM di un'intera macchina, potrebbe non valere la pena configurarla o imparare a utilizzare gli strumenti di virtualizzazione a livello di sistema operativo per questo scopo.
Le versioni precedenti di bind non eliminavano i privilegi. Su Unix, solo l'account root può aprire porte inferiori a 1024 e Bind, come tutti sappiamo, deve ascoltare udp/53 e tcp/53. Poiché Bind inizia come root e non perde privilegi, qualsiasi compromesso significherebbe che l'intero sistema potrebbe essere compromesso. Quasi tutti i software in questi giorni inizieranno ad aprire i propri socket e fare qualsiasi altra cosa che richiede i privilegi di root, quindi cambieranno l'utente che stanno eseguendo come un account non privilegiato. Una volta eliminati i privilegi, l'impatto della compromissione è molto inferiore sul sistema host.
Soluzione 2:
Le altre risposte sono piuttosto buone ma non menzionano il concetto di sicurezza a strati. Ogni livello di sicurezza che aggiungi al tuo sistema è un altro livello che un avversario deve superare. Mettere BIND in un chroot aggiunge un altro ostacolo.
Diciamo che c'è una vulnerabilità sfruttabile in BIND e qualcuno è in grado di eseguire codice arbitrario. Se si trovano in un chroot, devono uscirne prima di accedere a qualsiasi altra cosa nel sistema. Come accennato, i privilegi di root sono richiesti per l'interruzione del chroot. BIND non viene eseguito come root e dovrebbero esserci strumenti minimi disponibili nel chroot, limitando ulteriormente le opzioni e essenzialmente lasciando solo le chiamate di sistema. Se non c'è una chiamata di sistema per aumentare i privilegi, l'avversario è bloccato a guardare i tuoi record DNS.
La situazione di cui sopra è alquanto improbabile come menziona SomeGuy, BIND ha parecchie poche vulnerabilità in questi giorni e sono per lo più limitate a scenari di tipo DoS piuttosto che all'esecuzione remota. Detto questo, l'esecuzione in un chroot è la configurazione predefinita su parecchi sistemi operativi, quindi è improbabile che tu faccia uno sforzo da parte tua per mantenere la sicurezza sempre leggermente aumentata.
Soluzione 3:
preambolo
Continuo a sentire persone che ripetono idee sbagliate da tutta Internet... quindi, cercherò di dare qualche chiarimento
prima di tutto; quante scoperte accidentali ci sono state, che semplicemente... dovute a causa ed effetto , finì per essere usato per qualcosa di altro rispetto allo scopo previsto?
cos'era e cos'è una prigione Chroot
Chroot è stato inizialmente progettato per modificare la directory principale per il processo o l'utente (ottimo per compilare software da fonti sconosciute). questo forniva sicurezza al sistema di base, nonché un rapido apparecchio da banco di prova, inclusa una facile pulizia. sono passati anni da allora, e il suo concetto e gli usi impliciti sono certamente cambiati, allo stesso modo.
chroot è stato utilizzato efficacemente , ed è direttamente nella base di codice per diversi programmi e librerie (ad es. openSSHd, apache2 + mod_security2/mod_chroot, dovecot, sendmail, openVPN, pam_chroot, e molto altro ). presumere che tutte queste applicazioni tradizionali abbiano implementato soluzioni di sicurezza difettose è semplicemente non vero
chroot è una soluzione per la virtualizzazione del file system:niente di meno, niente di più. anche il presupposto che tu possa uscire facilmente da un chroot non è vero... a patto che tu rispetti le linee guida per l'esecuzione dei processi all'interno del chroot jail.
alcuni passaggi per proteggere il tuo chroot jail
cioè NON eseguire i processi come ROOT. questo potrebbe aprire un vettore di escalation della radice (che è vero anche all'interno o all'esterno del chroot). non eseguire un processo interno il chroot, utilizzando lo stesso utente di un altro processo esterno il chroot. separa ogni processo e utente nel proprio Chroot al fine di limitare le superfici di attacco e fornire privacy. monta solo i file, le librerie e i dispositivi necessari. infine, chroot NON sostituisce la sicurezza del sistema di base. mettere in sicurezza il sistema nella sua interezza.
un'altra nota importante: molte persone pensano che OpenVZ sia rotto o che non sia uguale rispetto alla virtualizzazione completa del sistema. fanno questo presupposto perché è essenzialmente un Chroot, con una tabella di processo che deve essere sterilizzata. con misure di sicurezza in atto su hardware e dispositivi. la maggior parte di cui puoi implementare in un chroot.
non tutti gli amministratori hanno il livello di conoscenza necessario per proteggere tutti i parametri del kernel necessari su un server dedicato o con la virtualizzazione completa del sistema. ciò significa che l'implementazione di OpenVZ significa che i tuoi clienti avranno una superficie di attacco molto inferiore per provare a coprire e proteggere prima di distribuire le loro applicazioni. un buon host farà un buon lavoro proteggendo questi parametri e, a sua volta, questo è meglio non solo per tutti sul nodo o nel data center, ma per Internet nel suo insieme...
come affermato, il chroot fornisce la virtualizzazione del file system. devi assicurarti che non ci siano eseguibili setuid, applicazioni non sicure, librerie, collegamenti simbolici senza proprietario penzolanti, ecc. in qualche altro modo compromettere qualcosa che risiede all'interno del chroot, scappando dalla prigione di solito attraverso l'escalation dei privilegi o iniettando il suo carico utile nel sistema di base.
se ciò accade, di solito è il risultato di un cattivo aggiornamento, zero day exploit o errore umano idiomatico .
perché chroot è ancora utilizzato, al contrario della virtualizzazione completa del sistema
considera questo scenario:stai eseguendo un Virtual Private Server, con il nodo host che esegue OpenVZ. semplicemente non puoi esegui tutto ciò che funziona a livello di kernel. questo significa anche che non è possibile utilizzare la virtualizzazione del sistema operativo per separare i processi e fornire ulteriore sicurezza. quindi, DEVI usa chroot per questo scopo.
inoltre, chroot è sostenibile su qualsiasi sistema, indipendentemente dalle risorse disponibili. in poche parole, ha il minimo sovraccarico di qualsiasi tipo di virtualizzazione. questo significa che è ancora importante su molte scatole di fascia bassa.
considera un altro scenario:hai apache in esecuzione all'interno di un ambiente virtualizzato. si desidera separare ogni utente. fornire un file system virtualizzato tramite un componente aggiuntivo chroot ad apache (mod_chroot, mod_security, ecc.) sarebbe l'opzione migliore per garantire la massima privacy tra gli utenti finali. questo aiuta anche a prevenire la raccolta di informazioni e offre un ulteriore livello di sicurezza.
in poche parole, è importante implementare la sicurezza nei livelli . Chroot è potenzialmente uno di loro. non tutti e tutti i sistemi hanno il lusso di avere accesso al Kernel, quindi, chroot STILL serve uno scopo. ci sono una varietà di applicazioni in cui la virtualizzazione completa del sistema è essenzialmente eccessiva.
In risposta alla tua domanda
non uso particolarmente CentOS, ma so che Bind ora perde i suoi privilegi prima delle operazioni. presumo, tuttavia, che bind sia sottoposto a chroot a causa della sua storia di vettori di attacco e potenziali vulnerabilità.
inoltre ... ha più senso eseguire automaticamente il chroot di questa applicazione, piuttosto che no, perché non TUTTI hanno accesso alla virtualizzazione a livello di sistema / sistema operativo completo. questo a sua volta, e in teoria, aiuta a fornire sicurezza alla base di utenti CentOS:
i fornitori di sistemi operativi semplicemente non vanno in giro supponendo che tutti eseguano lo stesso sistema. in questo modo, possono aiutare a fornire un ulteriore livello di sicurezza in generale...
c'è un motivo per cui così tante applicazioni lo usano , e perché ovviamente il tuo sistema operativo lo fa per impostazione predefinita:perché È usato come funzionalità di sicurezza e FUNZIONA. con un'attenta preparazione, come affermato in precedenza, è ancora un altro ostacolo che il potenziale aggressore deve superare, il più delle volte, limitando il danno alla sola prigione chroot.
Soluzione 4:
Ciò è in parte dovuto a ragioni storiche, quando le versioni precedenti di Bind presentavano gravi e frequenti vulnerabilità di sicurezza. Non mi sono tenuto aggiornato sull'argomento, ma scommetto che è molto migliorato rispetto ai vecchi tempi.
L'altro motivo, quello più pratico, è solo che è tipicamente implementato in un ruolo rivolto a Internet e, come tale, è aperto a più attacchi, sondaggi e malizia generale.
Pertanto, come è spesso la regola empirica in materia di sicurezza:meglio prevenire che curare, in particolare perché lo sforzo di chroot è relativamente ridotto.