Perché chroot è considerato insicuro?


12

Gioco con CentOS box da un paio d'anni ormai. Quindi sono abbastanza a mio agio con il terminale. Tuttavia, ho letto molti post sul blog che affermano che chroot è insicuro e la quantità di questi post fa paura. È davvero così? Perché?

Uso chroot per bloccare gli utenti solo SFTP in un contesto specifico, senza alcuna shell o comandi. Quindi davvero, qual è il problema di sicurezza con quello?

La domanda viene esiliata da StackOverflow .


1
Primo: la domanda non è stata chiusa / migrata su Stack Overflow , ma è chiaramente OT lì. L'azione appropriata sarebbe quella di attendere fino a quando non viene migrata o contrassegnarla e chiedere a una mod di farlo, senza effettuare il cross-posting su un altro sito. Ma secondo: se "giochi con CentOS", sbagli anche qui. Questo sito è destinato ad amministratori di sistema professionali, non hobbisti - consulta le nostre FAQ .
Sven

2
@SvenW grazie, terrò a mente il tuo consiglio per il futuro. E riguardo al "secondo", beh, scusate, ma non vedo come la mia domanda violi le FAQ. Dopo averlo letto due volte ora, posso dire che non lo fa. Per quanto riguarda la frase "gioca con CentOS", beh, ho pensato che fosse abbastanza ovvio che gli utenti chrooting e solo SFTP ed essere considerati in merito alla sicurezza fossero un argomento molto serio di cui i professionisti possono trarre vantaggio anche nella loro azienda o in qualsiasi altra " ambienti "professionali".
Aleksandr Makov,

1
@sven nel caso in cui non lo sapessi, SF è stato rimosso dall'elenco delle migrazioni di SO a causa di quante brutte domande ci hanno inviato.
MDMarra,

Risposte:


9

Perché, nella maggior parte dei casi, un processo di root può facilmente uscire dal chroot. Questo è di progettazione, poiché chroot non è mai stato inteso come un dispositivo di sicurezza.

Alan Cox in qualche modo ha rimproverato uno sviluppatore che ha inviato una patch del kernel per "correggere" questo comportamento, sostenendo che chroot è stato abusato come dispositivo di sicurezza, ma non è mai stato pensato per esserlo.


Perfetto! Grazie mille. Quindi questa è la questione dei processi di root che sono presenti nella root o sono accessibili da essa. Grazie.
Aleksandr Makov,

Ho appena verificato che eseguendo il programma C mostrato su unixwiz.net/techtips/mirror/chroot-break.html come root su Linux 4.18 è possibile sfuggire al chroot.
punti

Quindi non distribuire i privilegi di root. Anche i normali sistemi "sicuri" hanno account di root.
Cees Timmerman,

6

Conosco almeno un esempio del motivo per cui è considerato insicuro. Un ambiente chroot /procnon è isolato, quindi è abbastanza facile accedere alle risorse non di proprietà dei processi avviati nel chroot.

L'uso di un ambiente chroot per SFTP va bene e migliora significativamente il livello di sicurezza. Basta non abusarne come virtualizzazione basata su container, che offre più livelli di sicurezza. In questo, sottolineo cosa c'è nella risposta di @ MDMarra.


Grazie. Quindi ora diventa più chiaro che il chroot stesso non è scarso in termini di sicurezza ma piuttosto la sicurezza dipende dall'ambiente in cui è impostata.
Aleksandr Makov,

In realtà, chroot non è scarso in termini di sicurezza, perché non è mai stato progettato per essere un dispositivo di sicurezza. Doveva essere uno strumento di sviluppo per l'esecuzione di più versioni degli stessi binari fianco a fianco con dipendenze diverse. Non è un sostituto per la corretta protezione dei servizi, anche se può essere utile in determinate circostanze, purché si capisca di cosa si tratta e cosa non lo è.
MDMarra,

MDMarra, quindi, in pratica, chroot non è pensato per l'acquisizione di connessioni SSH. Quindi, secondo te, il "chrooting delle connessioni SSH in entrata" ti sembra in qualche modo poco professionale e dovrebbe essere evitato?
Aleksandr Makov,

No, non necessariamente, ti rendi conto che qualsiasi exploit che potrebbe portare all'elevazione dei privilegi o qualsiasi processo in esecuzione come root nel chroot sarebbe banale da rompere. Può sicuramente essere un pezzo del puzzle, ma non dovrebbe essere il tutto.
MDMarra,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.