chroot

[71104]

per un progetto universitario (lo stesso percui qualche giorno fa chiedevo delle inotify) dovrei realizzare un server che periodicamente notifichi i suoi clients delle modifiche effettuate al filesystem, solo a partire da una certa cartella; ovvero i clients devono poter richiedere il controllo e la ricezione di notifiche solo relativamente a cartelle radicate in una certa cartella specificata dall'amministratore all'avvio del server. inoltre il programma deve essere realizzato sia per Windows che per Linux. è logico che per Linux mi è saltato immediatamente in testa il concetto di chroot :P

in teoria potrei impedire ai clients il controllo di cartelle al di sopra della root semplicemente facendo un parsing del path richiesto e controllando che:
1) sia valido senza dover uscire dalla root
2) non contenga riferimenti alla cartella .. , cosa che un utente malizioso potrebbe sfruttare per risalire pur immettendo un path valido nella root.

però piuttosto che fare parsing per cercare di dedurre dove esattamente punta il path, preferirei una soluzione più robusta ed elegante basata su chroot su Linux e restricted tokens su Windows. coi restricted tokens me la vedo io per quanto riguarda chroot invece volevo sapere cosa dovrei fare di preciso. vedo che c'è una syscall chroot, la quale però ha successo solo se richiamata dal super-user. che è il super-user? è l'utente root, quello la cui password serve su Linux a fare casino, la classica "password di root"?

come potrei architettare il tutto? dovrei richiedere all'amministratore che il server venga avviato come root per poter fare chroot, e una volta fatto dovrei forkare creando il processo server figlio non come root ma come un altro utente impossibilitato a chroot-are?

il fatto che il server sia impossibilitato a chroot-are è una cosa che mi piacerebbe fare a scanso di exploit, ma al limite se è troppo complicata posso anche lasciar perdere perché il server (sperando di non averci lasciato dei bug) non prevede in nessun caso l'esecuzione nel suo processo di codice o comandi untrusted. semplicemente accetta dei path e si mette a controllarli in attesa di modifiche.

grazie

[71104]

up

non pretendo che qualcuno dia retta alle mie nerdate nel uichend, ma uppo giusto per non farlo andare nei meandri del forum

ilsensine, dove sei??
i tuoi aiuti sono sempre preziosi

[-fidel-]

Originariamente inviato da 71104

come potrei architettare il tutto? dovrei richiedere all'amministratore che il server venga avviato come root per poter fare chroot, e una volta fatto dovrei forkare creando il processo server figlio non come root ma come un altro utente impossibilitato a chroot-are?

Sì, per fare la cosiddetta "chroot jail" (o "sandbox" per usare un termine Java) il processo deve essere lanciato da amministratore: poi forki (o cedi i privilegi) cambiando owner su un utente/gruppo specifico con i giusti privilegi (normalmente creato ad hoc sul sistema, così che nessun utente appartenga a quel gruppo).
E' un metodo sicuro ed elegante, ma sì, devi lanciare il server da root (per ovvi motivi di sicurezza: immagina un programma con suid bit attivo, tipo 'passwd', che accede ad una chroot jail formata ad hoc (ad esempio con un falso /etc/passwd)...)

[^TiGeRShArK^]

non ho capito una mazza di quello che devi fare
per quanto riguarda l'esplorazione delle directory mi è subito saltata in mente os.walk di python.
Per quanto riguarda il tuo problema...
quale sarebbe?
che devi verificare che l'utente abbia i diritti per accedere in lettura alla cartella?

P.S. si nota che non ho la minima idea di quello ke fa chroot?
P.P.S ora ho letto il link che sull'LCD non l'avevo nemmeno notato ... xkè devi cambiare la cartella di root?

[-fidel-]

Originariamente inviato da ^TiGeRShArK^

P.P.S ora ho letto il link che sull'LCD non l'avevo nemmeno notato ... xkè devi cambiare la cartella di root?

un programma che fa chroot vede, da quel momento in poi, la directory su cui fa chroot come la radice del filesystem, rendendo impossibile per lui leggere/scrivere files al di fuori di quella directory (non a caso si parla di chroot jail).
Per un server di rete, questo è molto sicuro, perchè anche in presenza di un bug, il client remoto può solo fare danni all'iterno di quella directory, e non può invece andare altrove (visto che il processo server vede quella directory come la radice del FS...).
Come controindicazione, un programma che fa chroot via codice DEVE avere tutte le risorse e le librerie caricate dinamicamente DENTRO la directory in cui fa chroot (altrimenti non potrebbe caricarle perchè non le troverebbe), oppure precaricare tutto e poi fare chroot.
Ovviamente, se il processo che fa chroot non cede i privilegi di root subito dopo, il tutto diventa inutile.

[^TiGeRShArK^]

Originariamente inviato da -fidel-

un programma che fa chroot vede, da quel momento in poi, la directory su cui fa chroot come la radice del filesystem, rendendo impossibile per lui leggere/scrivere files al di fuori di quella directory (non a caso si parla di chroot jail).
Per un server di rete, questo è molto sicuro, perchè anche in presenza di un bug, il client remoto può solo fare danni all'iterno di quella directory, e non può invece andare altrove (visto che il processo server vede quella directory come la radice del FS...).
Come controindicazione, un programma che fa chroot via codice DEVE avere tutte le risorse e le librerie caricate dinamicamente DENTRO la directory in cui fa chroot (altrimenti non potrebbe caricarle perchè non le troverebbe), oppure precaricare tutto e poi fare chroot.
Ovviamente, se il processo che fa chroot non cede i privilegi di root subito dopo, il tutto diventa inutile.

mmm..
ok ..
ora mi è chiaro cosa faccia chroot..
ma mi sfugge perchè fare tutto ciò..
non sarebbe meglio usare sempre path relativi e nel caso ci sia un path assoluto impedire l'esecuzione?
con i path relativi si può risalire solo alle cartelle sotto quella corrente, quindi basterebbe controllare che il path non contenga ".." e/o "/" all'inizio della stringa...
o no?

[71104]

dunque dunque... innanzitutto grazie fidel, utillima () spiegazione, specialmente il post #5. inizialmente stavo riflettendo sul fatto che tutto sommato implementare nel server il supporto per chrootare è inutile perché un amministratore di sistema potrebbe semplicemente avviare il server col comando chroot (giusto...?), poi però ho letto la cosa delle risorse e degli shared object, che il server deve per forza avere completamente a portata di mano. ecco, questo è un bel problema per il quale vale la pena di implementare un supporto al chroot. il server infatti deve usufruire di un file di configurazione che logicamente potrebbe trovarsi al di fuori del ramo di filesystem da controllare, anzi tipicamente si troverà proprio fuori. di conseguenza il server, una volta avviato da root con l'apposita ipotetica opzione che abilita il supporto per chrootare, deve prima leggere il file di configurazione, poi chrootare, e poi cedere in qualche modo i permessi di root, o comunque sia deve divenire impossibile chrootare dal suo codice a scanso di exploit. il punto chiave è appunto questo: come faccio a cedere i permessi di root? devo loggarmi come un altro utente o posso restare root però con meno permessi? è necessario creare un altro processo o posso restare nel processo avviato come root? che syscall uso per loggarmi come altro utente/avviare processo come altro utente/rinunciare a dei permessi/altra soluzione ?

[-fidel-]

Originariamente inviato da ^TiGeRShArK^

mmm..
ok ..
ora mi è chiaro cosa faccia chroot..
ma mi sfugge perchè fare tutto ciò..
non sarebbe meglio usare sempre path relativi e nel caso ci sia un path assoluto impedire l'esecuzione?
con i path relativi si può risalire solo alle cartelle sotto quella corrente, quindi basterebbe controllare che il path non contenga ".." e/o "/" all'inizio della stringa...
o no?

se ad esempio il server viene lanciato nella directory /home/user/server, e il client richiede un list di:

dir_in_server/../../../../etc/

cosa succede?

Il parsing è pericoloso, deve essere davvero robusto.

[71104]

Originariamente inviato da ^TiGeRShArK^

mmm..
ok ..
ora mi è chiaro cosa faccia chroot..
ma mi sfugge perchè fare tutto ciò..
non sarebbe meglio usare sempre path relativi e nel caso ci sia un path assoluto impedire l'esecuzione?
con i path relativi si può risalire solo alle cartelle sotto quella corrente, quindi basterebbe controllare che il path non contenga ".." e/o "/" all'inizio della stringa...
o no?

non è così semplice: a voler fare un algoritmo veramente esaustivo di parsing del path non basterebbe controllare l'assenza del / iniziale e l'assenza TOTALE di "..", perché in realtà il path, pur contenendo il / iniziale e/o i ".." potrebbe comunque essere valido. insomma, non è molto elegante come soluzione, e tutto sommato neanche tanto semplice. preferirei se fosse qualcosa di molto più robusto basato sulla sicurezza del sistema operativo (chroot di Linux è perfetto, i restricted token e l'impersonazione di Windows NT un po' meno ma vanno bene lo stesso), anche perché scrivere un mio algoritmo di parsing del path non mi va per paura di produrre qualcosa che non coincide esattamente con l'algoritmo del sistema operativo (a maggior ragione quando il sorgente deve essere portabile su due piattaforme molto diverse tra loro...)

[71104]

Originariamente inviato da -fidel-

se ad esempio il server viene lanciato nella directory /home/user/server, e il client richiede un list di:

dir_in_server/../../../../etc/

cosa succede?

Il parsing è pericoloso, deve essere davvero robusto.

esatto, ma non tanto robusto quanto identico all'algoritmo del sistema operativo. molto meglio lasciare che il parsing lo faccia solo il sistema operativo, perché la versione "originale" dell'algoritmo è la sua, non la mia

[-fidel-]

Originariamente inviato da 71104

dunque dunque... innanzitutto grazie fidel, utillima () spiegazione, specialmente il post #5.

Di nulla

Originariamente inviato da 71104

inizialmente stavo riflettendo sul fatto che tutto sommato implementare nel server il supporto per chrootare è inutile perché un amministratore di sistema potrebbe semplicemente avviare il server col comando chroot (giusto...?)

In teoria sì, però lasci tutto il lavoro (e la responsabilità) all'admin (che normalmente si fa uno script ad hoc, normalmente non basta fare chroot sull'eseguibile). Se l'admin non è proprio il massimo, può fare danni. Se il programma crea una chroot via codice, tanto meglio (lì sta al programmatore, che di solito si fida più di sè stesso che di un admin terzo ).

Originariamente inviato da 71104

il punto chiave è appunto questo: come faccio a cedere i permessi di root? devo loggarmi come un altro utente o posso restare root però con meno permessi? è necessario creare un altro processo o posso restare nel processo avviato come root? che syscall uso per loggarmi come altro utente/avviare processo come altro utente/rinunciare a dei permessi/altra soluzione ?

I comandi Linux hanno il nome delle relative system calls, quindi nello specifico potrai usare chown (via codice hai anche a disposizione fchown e lchown) per i permessi sui files (se vuoi cambiarli), sui permessi del processo setuid/seteuid, setgid/setegid, setsid.
Con setsid puoi anche disassociarti dal terminale di controllo per rendere il server immune a certi segnali (insomma lo puoi rendere un "demone" (o meglio daemon)).

[-fidel-]

Originariamente inviato da 71104

esatto, ma non tanto robusto quanto identico all'algoritmo del sistema operativo. molto meglio lasciare che il parsing lo faccia solo il sistema operativo, perché la versione "originale" dell'algoritmo è la sua, non la mia

Concordo. Del resto diventa più facile fare una chroot che fare un path parser che si avvicini a quello del SO

[^TiGeRShArK^]

Originariamente inviato da -fidel-

se ad esempio il server viene lanciato nella directory /home/user/server, e il client richiede un list di:

dir_in_server/../../../../etc/

cosa succede?

Il parsing è pericoloso, deve essere davvero robusto.

apposta avevo scritto esplicitamente di impedire stringhe contenenti ".." nel mio post precedente

[^TiGeRShArK^]

Originariamente inviato da -fidel-

Concordo. Del resto diventa più facile fare una chroot che fare un path parser che si avvicini a quello del SO

Per farlo uguale a quello del SO in effetti è un casino

[^TiGeRShArK^]

cmq tornando IT..
direi che ad occhio in mezzo a tutte le properties ke è possibile specificare nel SecurityManager di Java qualcuna che faccia al caso tuo si trova per forza

[-fidel-]

Originariamente inviato da ^TiGeRShArK^

apposta avevo scritto esplicitamente di impedire stringhe contenenti ".." nel mio post precedente

avevo capito .. all'inizio della stringa (evidentemente tu intendevi solo / all'inizio della stringa).
Vabbé, fai conto che su linux puoi anche chiamare un file "/../" ad esempio
Per avere massima flessibilità bisognerebbe appunto implementare il path parser già implmentato nel SO, meglio non reinventare la ruota (tra l'altro ben fatta e collaudata in tanti anni )

[-fidel-]

Originariamente inviato da ^TiGeRShArK^

cmq tornando IT..
direi che ad occhio in mezzo a tutte le properties ke è possibile specificare nel SecurityManager di Java qualcuna che faccia al caso tuo si trova per forza

Fan di Java eh? Anche a me piace molto Tra l'altro ultimamente uso solo Java per applicazioni CORBA ed è davvero ottimo (soprattutto visto che ha una gestione del multithreading ottima e preimplementata ed è multipiattaforma, soprattutto).

[71104]

fidel, mi sono guardato il man delle varie syscall che hai detto e ho scoperto l'esistenza di effective uid, real uid, e saved uid. da quello che ho capito il real uid è l'user id sotto il quale gira il processo, l'effective è quello effettivo (cioè quello che realmente determina se il processo può o non può accedere a questa o quella risorsa), e il saved è un uid salvato che serve a riottenere permessi elevati quando vi si rinuncia. è più che altro un'idea che mi sono fatto leggendo le syscall, ma non ho trovato una definizione precisa di questi tre uid, quindi correggimi se ho sbagliato. io nel mio caso quale dei tre dovrei settare? nel man leggo a proposito di setuid (che setta quello effettivo, a proposito: che differenza c'è tra setuid e seteuid?) che se l'uid effettivo corrente è il super-user allora tutti e tre gli uid vengono settati al nuovo uid, di conseguenza un processo che usa questa syscall per rinunciare ai privilegi di root non può ridiventare root. ciò basta ai miei scopi? è sufficiente che io richieda all'amministratore l'avvio da root, poi chiami chroot ed infine setuid? e l'uid_t che serve a me da dove lo piglio?

[-fidel-]

Originariamente inviato da 71104

fidel, mi sono guardato il man delle varie syscall che hai detto e ho scoperto l'esistenza di effective uid, real uid, e saved uid. da quello che ho capito il real uid è l'user id sotto il quale gira il processo, l'effective è quello effettivo (cioè quello che realmente determina se il processo può o non può accedere a questa o quella risorsa), e il saved è un uid salvato che serve a riottenere permessi elevati quando vi si rinuncia. è più che altro un'idea che mi sono fatto leggendo le syscall, ma non ho trovato una definizione precisa di questi tre uid, quindi correggimi se ho sbagliato. io nel mio caso quale dei tre dovrei settare? nel man leggo a proposito di setuid (che setta quello effettivo, a proposito: che differenza c'è tra setuid e seteuid?) che se l'uid effettivo corrente è il super-user allora tutti e tre gli uid vengono settati al nuovo uid, di conseguenza un processo che usa questa syscall per rinunciare ai privilegi di root non può ridiventare root. ciò basta ai miei scopi? è sufficiente che io richieda all'amministratore l'avvio da root, poi chiami chroot ed infine setuid? e l'uid_t che serve a me da dove lo piglio?

Per i tre uid ci hai preso: per chiarezza (visto che quelle syscall non sono documentate alla perfezione, danno un po' per scontato che il lettore conosca i meccanismi di Unix):

Un utente sul sistema ha un unico UID (user ID) che specifica le risorse al quale l'utente può accedere. Stessa cosa per il group ID (GID).
Un processo sul sistema, invece, ha 3 UID:
1) UID reale: specifica il proprietario del processo
2) UID effettivo (EUID): usato nella decisione di quali risorse il processo può usare
3) UID salvato: per un ripristino futuro dell'UID in caso di cambio UID.
Stessa cosa per il GID (3 GID).

Un processo (creato o forkato), ha inizialmente come EUID l'UID reale (quindi quello del proprietario del processo). Visto che solo l'utente root può modificare l'UID reale del processo, cosa accade quando un utente non privilegiato chiama setuid()? Questo era lasciato all'implementazione di setuid(), diversa di solito tra i vari sistemi *nix, visto che lo standard POSIX 1 prevede solo la syscall setuid(). Quindi è stata introdotta la syscall seteuid(), per cambiare l'UID effettivo da parte di utenti non privilegiati (ovviamente non puoi mai avere privilegi superiori a quelli dati dall'UID reale )
Perchè tutto questo? Per avere flessibilità: se io utente non privilegiato potessi cambiare l'UID reale, ad esempio rilasando i permessi, non potrei più tornare all'UID precedente, con privilegi più elevati. Con seteuid invece, un processo non privilegiato (UID reale non privilegiato) può tranquillamente cambiare/rialssare i permessi con seteuid (visto che è con l'EUID che il kernel decide l'accesso alle risorse) per poi poter riprendere i privilegi dell'uid reale.

Come puoi immaginare, a te tutto questo non interessa per niente, visto che lancerai il server come root. Quindi, userai solo setuid() e setgid().
E' anche molto più sicuro, visto che, cambiando l'UID ed il GID reali, NON potrai più, in un secondo momento, riprendere i permessi (anche in presenza di un bug), perche l'EUID non può scavalcare l'uid, ed il processo NON PUO' PIU' cambiare l'uid reale (perchè è diventato non privilegiato) ma solo quello effettivo.
I permessi di un processo privilegiato vanno rilassati cambiando quindi l'UID e il GID reali, che sono il "tetto" dell'EUID.
Quindi farai:

1) setuid() ad un user non privilegiato
2) setgid() ad un gruppo non privilegiato.

Ovviamente potresti anche usare una execve: in modo figo, fai un programmino "wrapper" che crea una chroot jail, abbassa i privilegi e lancia il tuo server (che sarà un eseguibile esterno): in questo modo il server sarà multipiattaforma (con linux lo lanci con il wrapper, su altri sistemi lo lanci direttamente) ed il wrapper sarà "universale" (applicabile a tutti i programmi che vuoi). Giusto per completezza

La domanda adesso sorge spontanea: come scelgo il nuovo UID e GID, da dove li prendo?.
Partendo dal presupposto che UID e GID possono assumere i valori di uno tra gli UID e GID presenti sul sistema ospite del processo, dobbiami scegliere l'utente ed il gruppo appropriato, che deve esistere sul sistema.
Normalmente, i programmi chrooted, come ad esempio Apache o Postfix, creano in fase di installazione un utente/gruppo ad hoc (Apache ad esempio crea l'utente 'wwwrun', Postifix crea l'utente 'postfix'), che hanno i giusti privilegi solo nelle loro cartelle, e sul resto del sistema sono sempre visti come "other" (quindi al massimo hano privilegi di lettura).
Quindi potresti creare un utente ad hoc, ottenere via codice uid e gid associati e settare quelli.
Hai però un'altra soluzione, se, come penso, non vuoi mettere mani al sistema, ma semplicemente lanciare il tuo server chrooted in modo sicuro su qualiasi sistema *nix, senza intervenire sul sistema stesso.
Bene, quello che può al caso tuo è l'utente 'nobody', che ha UID=65534 e GID=65533.
'nobody' qualche privilegio ce l'ha (di solito sul database di "locate" ad esempio) ma mi sembra un buon utente per una chroot (visto che non puoi agire al di fuori della chroot dopo averla creata, e un utente non privilegiato non puo "scappare dalla prigione").
In codiice, quindi, puoi fare:

...
/* apro le risorse esterne alla chroot */
...
if (chroot(path))
{
   /* gestione errore */
   exit(1);
}
if (setgid(65533))
{
   /* gestione errore */
   exit(1);
}
if (setuid(65534))
{
   /* gestione errore */
   exit(1);
}

Certo, creare un utente ad hoc è il meglio, ma penso che con nobody vada comunque bene.

Un'ultima nota: se non vuoi problemi con il caricamento di librerie condivise dopo aver fatto chroot, puoi tranquillamente linkare staticamente quando compili il server.

EDIT: dimenticavo, per completessa: Il kernel GNU/Linux prevede anche un quarto uid/gid: è il Filesystem UID (FSUID) che regola i permessi di accesso al filesystem. Ovviamente, in caso di chiamata a setuid(), FSUID prende il valore di UID.

EDIT 2: Ah, se non puoi avere la certezza che all'utente nobody (come a qualunque altro utente) sia associato proprio quell'UID/GID, per conoscerli a partire da un username puoi usare la funzione getpwuid(uid_t uid) presente in "pwd.h".
Fai "man getpwuid()" per saperne di più - anche per gli headers da includere - oppure, in modo più bello, apri Konqueror e digita come indirizzo "man:/getpwuid"

EDIT 3: eliminata la fork(), inutile.

[^TiGeRShArK^]

che casino
con java in teoria basterebbe far partire il server specificando un securityManager che abbia questo permesso:

java.io.FilePermission "./*", "read"

in questo modo dovresti avere accesso in lettura a tutti i file al di sopra della dir corrente (o eventualmente puoi specificare un'altra dir).
Per quanto riguarda la portabilità.. bhè.. immagino che sia garantita quantomeno tra windows e linux