# [security] livello di sicurezza chroot?

## Tiro

ciao a tutti,

mi chiedevo che livello di sicurezza ci sia in un ambiente chroot dove girano dei server. Nel mi caso specifico ssh e mldonkey. A breve anche apache2 . Il chroot NON è su una partizione separata bensì su /mnt/qualcosa all'interno della partizione principale.

Lo stage adoperato per questo chroot è uno stage3-hardened (privo di su, ps, modprobe, ecc...). All'occorrenza vengono montate /usr/portage, /dev e /proc con:

```
# mount -o bind /$DIR /mnt/hard/$DIR
```

ecc...

Mldonkey è avviato da root e mi chiedevo quali problemi possano seguire nel caso in cui il server venga bucato. E' fattibile scalare sopra il chroot? o fare qualcosa di disastroso??

----------

## .:chrome:.

di documenti, riguardo all'evasione da chroot, ce ne sono parecchi, e di certo ti forniranno informazioni migliori di quelle che potresti trovare in questo forum.

considera che, in generale, puoi aumentare la sicureza mediante aggeggi come GRSecurity o il solo PaX.

e soprattutto CONSIDERA CHE ESEGUIRE PROGRAMMI E SERVIZI CON PRIVILEGI DI ROOT È PERICOLOSISSIMO E SBAGLIATO

----------

## CLod

direi livelli non altissimi di sicurezza ma cmq un "qualcosa in +"

tieni conto che con un semplicissimo programma in C riesci ad uscire dalla jail

----------

## shev

 *Tiro wrote:*   

> Mldonkey è avviato da root e mi chiedevo quali problemi possano seguire nel caso in cui il server venga bucato. E' fattibile scalare sopra il chroot? o fare qualcosa di disastroso??

 

Considera che già un "man chroot" risponde esplicitamente alle tue domande: si, si.

----------

## Cazzantonio

Il criterio da usare per chroot sarebbe quello di lasciare nella prigione solo i file essenziali per l'esecuzione dei demoni "imprigionati"... da quanto ho capito utilizzi uno stage vero e proprio (ovvero un'installazione pressoché completa) nella prigione di chroot.... in questo modo la prigione è "quasi" inutile...

Ti consiglio di creare prigioni che contengono solo le librerie utilizzate dai programmi imprigionati ed eventualmente i programmi che si appoggiano su di queste

inoltre MAI lanciare un demone di rete come root (a meno che non ti interessi un livello di sicurezza minimo)

per chrootare mldonkey ti consiglio questo tip

https://forums.gentoo.org/viewtopic-t-185310-highlight-chroot+mldonkey.html

----------

## Tiro

 *k.gothmog wrote:*   

> e soprattutto CONSIDERA CHE ESEGUIRE PROGRAMMI E SERVIZI CON PRIVILEGI DI ROOT È PERICOLOSISSIMO E SBAGLIATO

 

si lo so ma il problema è non sono riuscito a far girare il tutto da utente normale...ad ogni modo vedrò di recuperare...  :Cool: 

inoltre ho installato un vero e proprio stage per il fatto non sono riuscito a far funzionare jail seguendo l'howto e guide varie...e cmq...jail potrebbe essere una soluzione migliore di uno stage chrootato??

----------

## Cazzantonio

per mldonkey e ssh puoi anche fare a mano con uno script simile a quello che ti ho segnalato...

P.S. a cosa serve mettere sshd in chroot? ssh serve per accedere al sistema dall'esterno... ti interessa accedere al sistema chrootato?

----------

## fabius

 *Cazzantonio wrote:*   

> P.S. a cosa serve mettere sshd in chroot? ssh serve per accedere al sistema dall'esterno... ti interessa accedere al sistema chrootato?

 

Forse ci sono altri utenti?

----------

## Cazzantonio

 *fabius wrote:*   

>  *Cazzantonio wrote:*   P.S. a cosa serve mettere sshd in chroot? ssh serve per accedere al sistema dall'esterno... ti interessa accedere al sistema chrootato? 
> 
> Forse ci sono altri utenti?

 

continuo a non capire.... chrooti gli utenti?

----------

## fabius

 *Cazzantonio wrote:*   

> continuo a non capire.... chrooti gli utenti?

 

Penso piuttosto all'opportunità di non far vedere parte del filesystem ad un utente

----------

## stefanonafets

Oppure un server ssh fuori dalla chroot che risponde solo alla 127.0.0.1 (penso che cmq non sia una cosa troppo utile, cmq certo non "pulita", imho) ...

----------

## .:chrome:.

 *fabius wrote:*   

>  *Cazzantonio wrote:*   continuo a non capire.... chrooti gli utenti? 
> 
> Penso piuttosto all'opportunità di non far vedere parte del filesystem ad un utente

 

mi sembra una inutile e macchinosa complicazione.

è più semplice fare delle ACL in cui revochi il bit di eseguibilità alle directories che vuoi per gli utenti che vuoi

----------

## Tiro

no, sshd mi serve semplicemente per riavviare il servizio da remoto in caso di problemi...

----------

## Cazzantonio

puoi riavviarlo anche se ti connetti fuori dal chroot  :Wink: 

Con lo script che ti ho postato puoi facilmente lanciare mldonkey in ambiente chroot semplicemente con un comando, per apache ci sono una quantità di howto a giro che hai solo l'imbarazzo della scelta  :Wink: 

----------

## Tiro

 *Quote:*   

> puoi riavviarlo anche se ti connetti fuori dal chroot 

 

ovviamente si...  :Wink: 

quindi mi pare di capire che non vi piace molto uno stage chrootato...quindi è meglio un chroot specifico per ogni servizio a quanto posso intendere...

appena ho il computer tra le mani vedrò di far girare lo script indicato da cazzantonio...

----------

## Cazzantonio

 *Tiro wrote:*   

> quindi mi pare di capire che non vi piace molto uno stage chrootato...quindi è meglio un chroot specifico per ogni servizio a quanto posso intendere...

 

Anche perché chrotare le applicazioni serve per fare in modo che l'ambiente in cui girano abbia accesso al minimo delle applicazioni e/o librerie necessarie (per ridurre le possibilità di explioit)... e soprattutto sarebbe importante che all'interno della prigione non ci fosse una shell in modo da ridurre le possibilità di uscire dalla jail

P.S. per chrootare mldonkey ti consiglio di scaricare i binari compilati staticamente in modo che le librerie siano già tutte dentro il pacchetto che ti serve....

----------

## .:chrome:.

ma... al di là di tutto...

come mai questa scelta di mettere in chroot il mondo intero?

per esperienza, guarda che non è mai una scelta felice. il server in chroot te lo devi fare te a mano, e ovviamente non si aggiorna con il sistema, e quando c'è da aggiornare ti garantisco che sono c@**i che spuntano dalla sedia, perché è molto facile che non funzioni più... e se hai più server in diverse chroot è anche peggio... inizi a ritrovarti in giro per il sistema versioni diverse della stessa libreria e non sai più a chi appartengono...

ci sono altre soluzioni, che garantiscono uguale sicurezza, ma che non rischiedono tutto quel lavoro. prova a farci un pensierino

----------

## Ic3M4n

 *Quote:*   

> ci sono altre soluzioni, che garantiscono uguale sicurezza, ma che non rischiedono tutto quel lavoro. prova a farci un pensierino

 

@k.gothmog dato il discorso veramente interessante e lìmportanza del tema trattato, senza tralasciare la mia non vastissima esperienza... potresti dirmi a cosa ti riferisci con la frase quotata?

l'unica cosa che mi viene in mente è utilizzare UML. in questo modo puoi eseguire un kernel con privilegi di utente ed avere una maggiore sicurezza.

----------

## Tiro

meglio usare il pacchetto jail?? o ci sono altre soluzioni per il chroot che intendete voi??

----------

## Ic3M4n

dai un'occhiata a questo. http://www.gentoo.org/doc/it/uml.xml

in ogni caso si sta parlando molto di questa caratteristica di linux. 

mi spiace ma non so dirti niente di approfondito perchè per pigrizia e per tempo non ho ancora avuto tempo/voglia di farlo.

----------

## Tiro

si ho già provato l'uml col kernel 2.6 ma non va una cippa...non finisce manco di compilare...ad ogni modo avevo provato jail ma non mi faceva chrootare...ad ogni modo appena avrò sotto mano il computer affronterò il problema in modo più legittimo  :Cool: 

----------

## Ic3M4n

 *Quote:*   

> ...non finisce manco di compilare...

 

beh. visto che ci sono tante persone che lo usano non potrebbe essere che sbagli qualcosa tu?

----------

## Tiro

 *Ic3M4n wrote:*   

>  *Quote:*   ...non finisce manco di compilare... 
> 
> beh. visto che ci sono tante persone che lo usano non potrebbe essere che sbagli qualcosa tu?

 

probabilmente sbaglio qlcs io...ma queste altre persone usano uml con gentoo o con altre distro?? con che kernel??

----------

## Ic3M4n

non lo so non l'ho provato, come ho scritto poco sopra. almeno, non ancora. però se una cosa funziona in una distro non vedo il perchè non debba funzionare in un altra. alla fine dopotutto... sempre linux è.

in più non vedo perchè non debba funzionare con gentoo visto che siamo arrivati ad avere anche un how-to ufficiale in italiano.

va beh prometto che appena riesco gli do un'occhiata. a questo punto la storia inizia ad incuriosirmi.

----------

## Tiro

mi riferisco al fatto che uml con gentoo devi necessariamente compilarlo, con altre distro installi i binari. Con il kernel 2.6 ho incontrato difficoltà nell'emergerlo. Probabilmente funziona meglio col kernel 2.4...

----------

## .:chrome:.

 *Ic3M4n wrote:*   

>  *Quote:*   ci sono altre soluzioni, che garantiscono uguale sicurezza, ma che non rischiedono tutto quel lavoro. prova a farci un pensierino 
> 
> @k.gothmog dato il discorso veramente interessante e lìmportanza del tema trattato, senza tralasciare la mia non vastissima esperienza... potresti dirmi a cosa ti riferisci con la frase quotata?
> 
> l'unica cosa che mi viene in mente è utilizzare UML. in questo modo puoi eseguire un kernel con privilegi di utente ed avere una maggiore sicurezza.

 

mi riferiscco al fatto che:

1 - mantenere un server in chroot, come ti ho accennato, è un'operazione manuale, pallosa, e anche delicatina

2 - se hai più roba, in diverse chroot, il lavoro di manutenzione, da seccatura, passa a llo stato di mega rottura

ma soprattutto... metto un processo in chroot perché così, nell'eventualità che mi sfondino la macchina, restano comunque chiusi in un ambiente ristretto, dal quale non è possibile accedere all'esterno per fare danni.

prima di tutto dovresti stare a vedere da dove è possibile che cerchino di entrare, e focalizzare l'attenzione solo su quei servizi che rappresentano potenziali punti deboli. dovresti mantenere il tuo sistema aggiornato: è difficile che venga forzato un sistema costantemente aggiornato (sul quale, soprattutto, vengono sempre soddisfatti i security advisories).

con queste premesse puoi dedicarti a qualche semplice ma efficace operazioncina di hardening: inizi a portare più servizi possibili in listen solo su loopback, e poi magari ti sbizzarrisci un po' nel creare ACL in giro per il sistema (io mi concentrerei soprattutto su /etc).

per esempio, per tagliare le gambe ai celebri exploit di apache e php, questo è sufficiente.

se ottieni una shell da apache la ottieni con l'utente apache. se questo può solo leggere, ma non ha nessun privilegio per scrivere in nessun luogo dentro la ServerRoot, hai già fregato tanti dei celebri exploit di phpBB, per esempio. una cosa del genere la puoi fare agevolmente revocando i permessi di scrittura e mettendo delle ACL sulle directories.

non è un gran livello di sicurezza, ma conisdera che uno abbastanza sgamato per revocare una ACL o per scrivere in una directory nella quale non possiede alcun diritto, non trova difficoltà ad evadere da una chroot.

in sostanza: stesso risultato con meno sforzo

----------

## mouser

[forse OT]

Ho letto velocemente il thread (visto che sono un grande fan del chroot).

Come e' stato detto sopra, una prigione con chroot si puo' evadere con un semplice programma in C.... questo e' vero fino ad un certo punto, poiche' ovviamente se si ha un programma che va a leggere ../../../ fino ad uscire dalla prigione questo puo' permettere un'accesso a qualsiasi file esterno, ma un programma che possa accedere a ../../../ fino all'esterno della prigione, necessita un'esecuzione con UID = 0, cosa che tra le altre cose, permette di uscire dalla prigione senza utilizzare alcun programma in C.

Volevo solo mettere due cosine che mi sono state dette durante il corso di sicurezza, e che, a quanto pare, sono le 2 cose fondamentali nella creazione di un'ambiente chrootato:

1) MAI mettere una shell nell'ambiente chrootato! (sapendo bene come funzione, e' possibile andare a settare a runtime uno UID=0 nei registri contenenti le variabili della shell, con il relativo salto esterno alla prigione)

2) Finche' si puo', copiare nella prigione le librerie e i programmi compilate staticamente! (una compilazione dinamica, magari con riferimenti ad altre lib/programmi esterni alla prigione, permette di saltarne fuori).

Solo un chiarimento per chi avesse qualche dubbio

[/forse OT]

Ciriciao

mouser  :Wink: 

----------

## Cazzantonio

@k.gothmog

Proprio perché magari mi interessa lanciare poca roba in chroot che mi torna comodo quello piuttosto chele acl....  :Wink: 

Per aggionrare mldonkey con i binari compilati staticamente mi ci vuole meno di 10 minuti (e lo fo solo se me lo ricordo... ovvero praticamente mai)

----------

## Tiro

 *k.gothmog wrote:*   

>  *Ic3M4n wrote:*    *Quote:*   ci sono altre soluzioni, che garantiscono uguale sicurezza, ma che non rischiedono tutto quel lavoro. prova a farci un pensierino 
> 
> @k.gothmog dato il discorso veramente interessante e lìmportanza del tema trattato, senza tralasciare la mia non vastissima esperienza... potresti dirmi a cosa ti riferisci con la frase quotata?
> 
> l'unica cosa che mi viene in mente è utilizzare UML. in questo modo puoi eseguire un kernel con privilegi di utente ed avere una maggiore sicurezza. 
> ...

 

a questo punto mi hai convinto...appena il tempo me lo permette incomincio a smanettare con ACL e gingilli vari...anche perchè sulla questione manutenzione del chroot devo darti ragione...è pallosa e poco pratica! pensavo che la soluzione del chroot portasse vantaggi e invece a quanto pare non sono poi così tanti...

----------

## .:chrome:.

 *Cazzantonio wrote:*   

> @k.gothmog
> 
> Proprio perché magari mi interessa lanciare poca roba in chroot che mi torna comodo quello piuttosto chele acl.... 
> 
> Per aggionrare mldonkey con i binari compilati staticamente mi ci vuole meno di 10 minuti (e lo fo solo se me lo ricordo... ovvero praticamente mai)

 

evidentemente non mi sono spiegato. scusa.

quando metti un programma in chroot, ovviamente non può esserci solo lui, ma pure tutta la roba di cui ha bisogno (librerie, in primis, fino a passwd e le librerie per leggere lui e shadow, se il tuo programma gira con un utente dedicato). E QUESTA la menata da aggiornare. se aggiorno glibc (ok, è un esempio estremo: non succede quasi mai) devo ribaltare tutti i files contenuti nella /lib della chroot. l'esempio è un po' estremo, ma è facilmente rapportabile a casi più generali.

finché è il mio sistema di casa, posso anche fare finta di niente, ma se si tratta di una macchina in produzione, insomma... è un po' una seccatura

io ho provato, per un po', a farmi uno script che generasse e mantenesse una chroot per apache. finché si trattava di generare, ok... per aggiornarla ho sempre dovuto fare a mano

----------

## Cazzantonio

@k.gothmog

Questo perché apache è più complesso da gestire... molti programmini (tipo mldonkey visto che si parlava di quello) possono essere fatti girare in chroot senza sbattimenti...

1) i binari di mldonkey sono compilati staticamente mentre i sorgenti, durante il ./configure, ti chiedono se vuoi scaricarti le librerie da cui dipende (sono solo 2) direttamente nella dir del programma se non le trova nel sistema  :Wink:  (io comunque uso i binari statici)

2) non hai bisogno di passwd, shadow e compagnia bella perché con dei semplici script (tipo quello postato sopra) puoi cambiare l'uid e il gid del programma al volo dopo che è stato lanciato come root, quindi ancora meno sbattimento visto che non devi ricreare parte della tua /etc in chroot  :Wink: 

Io chrooto mldonkey in una directory dove c'è solo lui, niente shel, librerie esterne, file di conf residenti fuori dalla dir del programma.... e tutto questo semplicemente scompattando i binari del programma nella directory di chroot.... l'unica cosa che devo ricordarmi di aggiornare è lo script (per farlo puntare alla nuova directory semmai)

Come vedi in questo caso lo sbattimento è minimo e la sicurezza è soddisfacente (rispetto alla fatica durata  :Wink:  niente è sicurissimo....)

In generale penso sia comodo far girare sotto chroot i programmi di file sharing perché, vista l'attività che fanno, ovvero "condividere i files", fosse mai che ad un tratto venisse fuori un exploit che da accesso al disco dall'esterno....  :Rolling Eyes: 

----------

## .:chrome:.

che storia... questo cambia molto le carte in tavola  :Smile: 

----------

## Tiro

 *Cazzantonio wrote:*   

> 
> 
> 1) i binari di mldonkey sono compilati staticamente mentre i sorgenti, durante il ./configure, ti chiedono se vuoi scaricarti le librerie da cui dipende (sono solo 2) direttamente nella dir del programma se non le trova nel sistema  (io comunque uso i binari statici)
> 
> 

 

dove si trovano? ho cercato sul sito ufficiale ma non ho trovato nulla...

----------

## Cazzantonio

http://ftp.berlios.de/pub/mldonkey/spiralvoice/

http://www.mldonkeyworld.com/

15 secondi di ricerca su google compreso il tempo necessario per postare  :Wink: 

----------

## Tiro

già fatto...in effetti ho postato troppo frettolosamente...sorry!  :Wink: 

----------

## Tiro

ad ogni modo lo scriptino ha qlc problema...

```
 # ls -l mldonkey-chroot 

-rwx------  1 root root 574  6 mag 19:40 mldonkey-chroot

```

ma per partire ha bisogno di:

```
 # bash mldonkey-chroot 

import: unable to grab mouse `Success'.

import: unable to read X window image `'.

import: unable to read X window image `'.

mldonkey-chroot: line 8: syntax error near unexpected token `:'

mldonkey-chroot: line 8: `if os.fork():'

```

ma come si può ben vedere ha dei problemi...! cmq a volte parte e funziona ma poi si impappina...

```
 # cat mldonkey-chroot 

#!/usr/bin/python

import os, sys

MLDONKEY_HOME='/mnt/mldonkey-distrib-2.5-30.15/'

MLDONKEY_EXE='./mlnet'

MLDONKEY_UID=1000

MLDONKEY_GID=123

MLDONKEY_NICE=18

if os.fork():

        sys.exit()

os.close(sys.stdout.fileno())

os.close(sys.stderr.fileno())

sys.stdout.close()

sys.stderr.close()

sys.stdout = file('/dev/null','w')

sys.stderr = file('/dev/null','w')

os.nice(MLDONKEY_NICE)

os.chdir(MLDONKEY_HOME)

os.chroot(MLDONKEY_HOME)

os.setgroups([])

os.setregid(MLDONKEY_UID,MLDONKEY_UID)

os.setreuid(MLDONKEY_GID,MLDONKEY_GID)

os.setsid()

os.execl(MLDONKEY_EXE,MLDONKEY_EXE) 

```

----------

## Tiro

```
# grep user  downloads.ini 

        (* port for user interaction *)

          ("server.met", 96, "http://www.primusnet.ch/users/komintern/ed2k/min/server.met");

        (* The login of the user you want mldonkey to run as, after the ports

        (* The UID of the user (0=disabled) you want mldonkey to run as, after the ports

(*        user. Do not modify them if you are not   sure.        *)

```

----------

## gutter

@Tiro: Per favore non postiamo un post dopo l'altro ma editiamo sempre l'ultimo se abbiamo da aggiungere delle considerazioni.

----------

## Cazzantonio

 *Tiro wrote:*   

> ma come si può ben vedere ha dei problemi...! cmq a volte parte e funziona ma poi si impappina...

 

strano.... a me non ha mai dato problemi....

----------

