View Full Version : chroot
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 :D per quanto riguarda chroot invece volevo sapere cosa dovrei fare di preciso. vedo che c'è una syscall chroot (http://www.linuxmanpages.com/man2/chroot.2.php), la quale però ha successo solo se richiamata dal super-user. che è il super-user? :D :D :D è l'utente root, quello la cui password serve su Linux a fare casino, la classica "password di root"? :huh:
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
up :D
non pretendo che qualcuno dia retta alle mie nerdate nel uichend, ma uppo giusto per non farlo andare nei meandri del forum :D
ilsensine, dove sei?? :D
i tuoi aiuti sono sempre preziosi :read:
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^
12-05-2007, 15:48
non ho capito una mazza di quello che devi fare :D
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? :fagiano:
P.S. si nota che non ho la minima idea di quello ke fa chroot? :D
P.P.S ora ho letto il link che sull'LCD non l'avevo nemmeno notato :muro: ... xkè devi cambiare la cartella di root? :fagiano:
P.P.S ora ho letto il link che sull'LCD non l'avevo nemmeno notato :muro: ... xkè devi cambiare la cartella di root? :fagiano:
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^
12-05-2007, 17:17
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? :fagiano:
dunque dunque... innanzitutto grazie fidel, utillima (:p) 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 ?
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? :fagiano:
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.
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? :fagiano: 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...)
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 :)
dunque dunque... innanzitutto grazie fidel, utillima (:p) spiegazione, specialmente il post #5.
Di nulla :)
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 :D).
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)).
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 :D
^TiGeRShArK^
12-05-2007, 19:38
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 :fagiano:
^TiGeRShArK^
12-05-2007, 19:40
Concordo. Del resto diventa più facile fare una chroot che fare un path parser che si avvicini a quello del SO :D
Per farlo uguale a quello del SO in effetti è un casino :D
^TiGeRShArK^
12-05-2007, 19:47
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 :D
apposta avevo scritto esplicitamente di impedire stringhe contenenti ".." nel mio post precedente :fagiano:
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 ;))
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 :D
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).
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, 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^
13-05-2007, 11:23
:mbe:
che casino :mbe:
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 :p
:mbe:
che casino :mbe:
Addirittura per 4 linee di codice....
con java in teoria basterebbe far partire il server specificando un securityManager che abbia questo permesso:
java.io.FilePermission "./*", "read"
in teoria sì, ma usare un securitymanager implica altre cose (tipo gestire eccezioni DOPO aver creato un security manager).
Con la chroot invece, con 4 linee di codice (chroot(), setuid(), setgid() e fork()) poi programmi normalmente e in sicurezza, senza dover gestire alcunchè o prevedere casi particolari (il processo è senza privilegi, e gira in una directory che viene vista come la radice del filesystem...): in più non parliamo delle prestazioni (praticamente immutate nel caso di chroot jail, mentre con un securitymanager...
Concordo invece se mi dici che un SecurityManager è più flessibile, o meglio che è più facile da usare se vuoi flessibilità nei permessi (con chroot di "chiudi in carcere" appunto, ed uscirne una volta rilassati i permessi diventa praticamente impossibile, a meno che non si preveda di poter rimettere l'UID a root (uid 0), ma sarebbe rischiosissimo.
EDIT: poi mi sono dilungato in spiegazioni e nei meccanismi (non credo che 71104 voglia imparare "bovinamente"), ma il codice è una cavolata pazzesca.
sigh :cry: fidel non so come ringraziarti
però non ho ancora finito con le domande :D
c'è ancora questa cosa che non capisco: in base a cosa il kernel permette o non permette ad un processo di cambiare l'effective user id? ovvero, in base a cosa il kernel determina che un uid ha più o meno permessi di un altro (cioè di quello reale del processo)?? :mbe:
cosa significa di preciso "meno permessi" o "più permessi"? si parla sempre di permessi su files? un utente può certamente avere un ovvio sottoinsieme o sovrainsieme dei permessi che ha un altro utente, ma se semplicemente avesse dei permessi diversi? Tizio ha rwx su un file (e nient'altro) e Caio ha rwx su un altro file (e nient'altro): chi dei due ne ha "di più"?
e poi altra cosa: come mai per cambiare l'UID di un processo non devo fare nessun tipo di logon?? :confused:
non devo specificare password a nessuna syscall? in tal modo un utente potrebbe agire come un altro utente semplicemente avviando un programma che cambia il suo euid. suppongo che la risposta a questa domanda si basi sulla logica del fatto che il real uid è il "tetto" dell'euid, e che quindi se anche un processo impersonasse un altro utente potrebbe sicuramente fare meno danni, ma non di più. ma la cosa mi stupisce alquanto ugualmente perché i danni risulterebbero fatti da un utente innocente :D
grazie 1000 per la tua pazienza :)
sigh :cry: fidel non so come ringraziarti
però non ho ancora finito con le domande :D
:D
c'è ancora questa cosa che non capisco: in base a cosa il kernel permette o non permette ad un processo di cambiare l'effective user id? ovvero, in base a cosa il kernel determina che un uid ha più o meno permessi di un altro (cioè di quello reale del processo)?? :mbe:
No la cosa è molto più semplice: ogni processo ed ogni nodo del filesystem (compresi quindi i node device, le periferiche insomma) ha il suo UID ed il suo GID: la maschera dei permessi su OGNI elemento del filesystem (file e periferiche, visto che l'accesso ad un periferico si ha grazie ad un semplice file, con i suoi permessi, situato in /dev) è suddivisa in tre parti:
lettura/scrittura/esecuzione per l'owner user (UID)
lettura/scrittura/esecuzione per l'owner group (GID)
lettura/scrittura/esecuzione per tutti gli altri (Others).
questo regola l'accesso alle risorse da parte dei processi.
Quindi... (segue)
cosa significa di preciso "meno permessi" o "più permessi"? si parla sempre di permessi su files? un utente può certamente avere un ovvio sottoinsieme o sovrainsieme dei permessi che ha un altro utente, ma se semplicemente avesse dei permessi diversi? Tizio ha rwx su un file (e nient'altro) e Caio ha rwx su un altro file (e nient'altro): chi dei due ne ha "di più"?
...avrò "più permessi" se, ad esempio, ho i permessi di scrittura sul file /etc/passwd, posso uccidere processi lanciati da "init", ho possibilità di cambiare i files di configurazione in /etc, e così via.
Visto quindi che "avere più permessi" dipende da COME è settato il sistema (ok tutte le distro GNU/Linux hanno un setup standard sui files e sui processi "di default", ma nessuno ti vieta di cambiarle, e comunque ci sono un sacco di programmi che hanno particolari permessi sulle loro cartelle, vedi ad esempio Apache) il kernel linux si comporta in modo molto semplice:
solo l'utente/gli utenti root possono cambiare UID/EUID :)
Prova ad esempio a fare setuid() o seteuid() lanciando il programma con qualunque utente che non sia root e vedi se te lo permette.
Forse nel precedente post questo non si era capito a sufficienza. Però, come detto prima, chiarisco: seteuid si usa quando un processo (sempre root) vuole rilassare i suoi permessi (impersonare un utente non root) per poi ritornare ad essere processo root (può farlo visto che con seteuid l'UID non cambia ma solo l'EUID). Se invece chiamasse setuid() (come farai tu per la chroot) il processo perde definitivamente i privilegi di root, perchè cambi il real UID (il nostro "tetto").
e poi altra cosa: come mai per cambiare l'UID di un processo non devo fare nessun tipo di logon?? :confused:
non devo specificare password a nessuna syscall? in tal modo un utente potrebbe agire come un altro utente semplicemente avviando un programma che cambia il suo euid. suppongo che la risposta a questa domanda si basi sulla logica del fatto che il real uid è il "tetto" dell'euid, e che quindi se anche un processo impersonasse un altro utente potrebbe sicuramente fare meno danni, ma non di più. ma la cosa mi stupisce alquanto ugualmente perché i danni risulterebbero fatti da un utente innocente :D
Visto che solo un processo root può cambiare UID/EUID/GID/EGID, mi pare ovvio che nessuna password sia richiesta: l'utente root è il dio di Linux :D
^TiGeRShArK^
13-05-2007, 17:28
Addirittura per 4 linee di codice....
in teoria sì, ma usare un securitymanager implica altre cose (tipo gestire eccezioni DOPO aver creato un security manager).
bhè..
imho 1 riga di configurazione è meglio di 4 righe di codice :D
l'unica riga di codice senza bug è quella che non è stata scritta :asd:
e cmq per fare funzionare il tutto basta catchare la SecurityException corrispondente all'accesso ai File (sarà qualcosa del tipo FilePermissionException immagino).
E in questo modo si ha una soluzione che funge sia su win che su linux :p
:
e cmq per fare funzionare il tutto basta catchare la SecurityException corrispondente all'accesso ai File (sarà qualcosa del tipo FilePermissionException immagino).
Sì, su ogni accesso ai file però, devi ricordartene (non dicevo che è difficile, ma che devi sempre prestare attenzione), soprattutto se hai più funzioni che fanno accesso a file in più punti del programma (se dimentichi di catchare il programma non fa danni ma termina l'esecuzione, invece con la chroot jail te ne freghi e programmi normalmente).
Poi il tutto risulta più lento (visto che c'è qualcosa in mezzo tra il file ed il tuo accesso, che viene sempre interpellato) e con maggior consumo di memoria (vabbé quest'ultimo punto magari è un po' esagerato :)), anche se, come dici:
in questo modo si ha una soluzione che funge sia su win che su linux :p
che non è una cosa da poco :)
Te lo dice un fan di Java che apprezza tantissimo questo linguaggio (soprattutto la versione RealTime, davvero ottima, potenza espressiva in programmazione ma grandi prestazioni, e tra poco approda anche su Linux (ora solo su Solaris) :D).
^TiGeRShArK^
13-05-2007, 19:37
Te lo dice un fan di Java che apprezza tantissimo questo linguaggio (soprattutto la versione RealTime, davvero ottima, potenza espressiva in programmazione ma grandi prestazioni, e tra poco approda anche su Linux (ora solo su Solaris) :D).
La versione Real-Time però è un discreto casino dal poco ke ho visto :cry:
seteuid si usa quando un processo (sempre root) vuole rilassare i suoi permessi (impersonare un utente non root) per poi ritornare ad essere processo root (può farlo visto che con seteuid l'UID non cambia ma solo l'EUID). Se invece chiamasse setuid() (come farai tu per la chroot) il processo perde definitivamente i privilegi di root, perchè cambi il real UID (il nostro "tetto").
Visto che solo un processo root può cambiare UID/EUID/GID/EGID, mi pare ovvio che nessuna password sia richiesta: l'utente root è il dio di Linux :D OOOOOOOOOOOOra ho capito :read:
perciò:
1) chiedere all'amministratore di avviare come root se vuole fare il chroot
2) chroot
3) setuid() e setgid() a "nobody" (o meglio, all'uid_t e gid_t che ottengo passando "nobody" a getpwnam, giusto?) e passa la paura :cool:
4) fork, perché se mi scordo i fd aperti poi un exploit li può ancora utilizzare; ma qui ho ancora un piccolo dubbio: i fd non vengono ereditati se uso la fork? :confused:
ah poi altra cosa, a proposito di questa getpwnam: ma quand'è che fallisce questa funzione? perché vedo che restituisce informazioni direi abbastanza sensibili... :D
a rigor di logica è una funzione che dovrebbe avere successo solo se richiamata sotto root o comunque da un account che ha già di per se' la possibilità di leggere quella stessa roba dal file delle password.
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.
premetto che ho letto con molto interesse questo thread (fidel ne sa sempre un casino). una domanda scema.. si può pensare di creare dei link simbolici alle librerie che servono nella directory chrootata oppure questo è pericoloso per qualche motivo o semplicemente i link simbolici non funzionano se vanno fuori dalla directory?
ah poi altra cosa, a proposito di questa getpwnam: ma quand'è che fallisce questa funzione? perché vedo che restituisce informazioni direi abbastanza sensibili... :D
Fallisce al solito per errori di I/O, o per interruzione causata da una signal, memoria insufficiente a contenere la struct ( :rolleyes: )
Quali informazioni sensibili? l'elenco degli utenti registrati sul sistema? Non mi pare sia una informazione sensibile. Se pensi che in /etc/passwd ci siano le passwords degli utenti, beh, sappi che sono eoni che si usano per lo meno le shadow passwords criptate con la chiave di sistema ;) Al posto della password in quel file ci trovi una bella "x".
a rigor di logica è una funzione che dovrebbe avere successo solo se richiamata sotto root o comunque da un account che ha già di per se' la possibilità di leggere quella stessa roba dal file delle password.
Per i motivi descritti prima, /etc/passwd è leggibile da tutti (e scrivibile solo da root ovviamente), a meno che l'admin del sistema sia un po' paranoico: se ci pensi, se non fosse leggibile dagli utenti non root (quindi dagli "others") getpwnam() fallirebbe miseramente per I/O error.
premetto che ho letto con molto interesse questo thread (fidel ne sa sempre un casino). una domanda scema.. si può pensare di creare dei link simbolici alle librerie che servono nella directory chrootata oppure questo è pericoloso per qualche motivo o semplicemente i link simbolici non funzionano se vanno fuori dalla directory? premesso che non lo so e che sto solo gettando i miei 2 cents :p
la risposta dipende dal livello a cui i link simbolici vengono dereferenziati su Linux: su Windows ad esempio i "collegamenti" sono semplici "shell links" (termine tecnico per indicarli), e vengono dereferenziati banalmente dalla shell grafica (explorer.exe, shell32.dll, e compagnia bella); non si tratta di un meccanismo trasparente alle applicazioni (le quali se cercano di aprire un collegamento, con CreateFile o con fopen, aprono quello, e non il file a cui esso punta), e se uno shell link puntasse ad un file a cui l'utente non ha accesso, l'utente pur avendo accesso al link e facendovi doppio click sarebbe impossibilitato ad aprire il file.
è mia modesta opinione che un link (parlo di "link" in questo contesto solo a livello concettuale) ad un file che sia dereferenziato ad un livello più basso, diciamo a livello di kernel, dovrebbe necessariamente basarsi su una feature di redirezione supportata dal filesystem. infatti un link ad un file è una pezzo di informazioni (tipicamente un file esso stesso) contenente sostanzialmente il path di un altro file e poco altro, e per contenere tali informazioni deve essere definito un formato; tale formato può essere o una specifica della shell (come nel caso di Windows) o del filesystem, non credo ci siano altri casi.
si notava molto che andavo a supposizioni e che non so nulla dei link simbolici di Linux? :Prrr:
Fallisce al solito per errori di I/O, o per interruzione causata da una signal, memoria insufficiente a contenere la struct ( :rolleyes: )
Quali informazioni sensibili? l'elenco degli utenti registrati sul sistema? Non mi pare sia una informazione sensibile. Se pensi che in /etc/passwd ci siano le passwords degli utenti, beh, sappi che sono eoni che si usano per lo meno le shadow passwords criptate con la chiave di sistema ;) Al posto della password in quel file ci trovi una bella "x". quindi nel campo pw_passwd della struct passwd ci trovo sempre quella stringa fittizia? sapevo che delle password su Linux viene memorizzato a lungo termine solamente l'hash MD5, quindi pensavo che nella struct (o nel file /etc/passwd) ci avrei trovato l'hash scritto a stringa... ma comunque mi chiedo: in passato (anche solo nei primi Unix, o nello Unix originale) quel campo aveva valore? un utente qualunque poteva realmente leggere nomi e password di chiunque?? O_o
e meno male che hanno messo la "x"... :D
ma poi ad essere sincero anche il solo elenco degli utenti a me sembra una informazione potenzialmente sensibile :confused:
non è mica detto (ad esempio) che ad un'organizzazione piaccia che chiunque abbia un account (magari solo temporaneo, perché fornisce all'azienda un contributo occasionale) abbia la possibilità di conoscere l'elenco di tutti i dipendenti, compresi quelli dei livelli più alti della gerarchia... il solo fatto che una certa persona lavori per un'azienda, e di quale gruppo faccia parte, in certe situazioni potrebbe essere segreto. in casi simili suppongo che all'utente venga negato l'accesso in lettura al file delle password, no?
si può pensare di creare dei link simbolici alle librerie che servono nella directory chrootata oppure questo è pericoloso per qualche motivo o semplicemente i link simbolici non funzionano se vanno fuori dalla directory?
Sì, ma con hard link, non soft link. E' comunque potenzialmente rischioso, visto che costituiscono una possibile "via di fuga" dalla jail. Meglio linkare staticamente o avere una copia della libreria dentro la jail da caricare con *dlopen() (o in modo ancora più "figo" ma soprattutto semplice per il programmatore, avere un sottoinsieme di /usr/lib (e/o qualunque altra directory contenente librerie condivise utilizzate dal programma) nella jail, in path del tipo /jail_path/usr/lib).
Oppure si carica tutto e subito (ma non sempre è possibile, a meno di non usare *dlopen()).
quindi nel campo pw_passwd della struct passwd ci trovo sempre quella stringa fittizia? sapevo che delle password su Linux viene memorizzato a lungo termine solamente l'hash MD5, quindi pensavo che nella struct (o nel file /etc/passwd) ci avrei trovato l'hash scritto a stringa... ma comunque mi chiedo: in passato (anche solo nei primi Unix, o nello Unix originale) quel campo aveva valore? un utente qualunque poteva realmente leggere nomi e password di chiunque?? O_o
e meno male che hanno messo la "x"... :D
All'epoca sì, ma quel file era leggibile (e scrivibile) solo da root. Ormai quel file ha poco valore (a meno che non sia scrivibile eh!!), quindi è stato "demilitarizzato".
ma poi ad essere sincero anche il solo elenco degli utenti a me sembra una informazione potenzialmente sensibile :confused:
non è mica detto (ad esempio) che ad un'organizzazione piaccia che chiunque abbia un account (magari solo temporaneo, perché fornisce all'azienda un contributo occasionale) abbia la possibilità di conoscere l'elenco di tutti i dipendenti, compresi quelli dei livelli più alti della gerarchia... il solo fatto che una certa persona lavori per un'azienda, e di quale gruppo faccia parte, in certe situazioni potrebbe essere segreto. in casi simili suppongo che all'utente venga negato l'accesso in lettura al file delle password, no?
Bene, gli cambi i permessi in un attimo :)
Sulle distro "home/a prova di newbie" di solito è leggibile da tutti (figurati se il newbie si flippa con getpwnam(), e comunque se ne frega se un potenziale hacker - che già devi vedere se riesce ad accedere al sistema per fare una getpwnam() - vede che c'è l'utente PincoPallino registrato come user), ma i permessi (di tutto il sistema, su un unico file tipo /etc/passwd lo fai al volo) li cambi al volo grazie ai files "permissions": ad esempio su Suse ce ne sono di già fatti: permissions.easy, permission.security, permissions.paranoid (:D) e permissions.local (per definire qualcosa di personalizzato), che vengono letti in fase di init del sistema: di default Suse legge solo permissions.easy e .local, ma li cambi in 20 secondi con Yast. Pensa che una volta ho settato permissions.paranoid e non mi faceva neanche spegnere il PC: "Solo root può arrestare il sistema"... :)
Dipende da cosa devi farci col sistema.
Per la storia dei link, cerco di risponderti domani (ora vado a letto :)) cmq i link (hard e soft) in linux sono un qualcosa di molto potente e versatile, più che in Win.
4) fork, perché se mi scordo i fd aperti poi un exploit li può ancora utilizzare; ma qui ho ancora un piccolo dubbio: i fd non vengono ereditati se uso la fork? :confused:
Ultima cosa e vado: certo, i fd vengono ereditati dal processo figlio, ma ricordavo erroneamente che i permessi venivano cambiati: ho provato e non è così invece, il processo figlio può scrivere su un file di root se questo è stato aperto (magari in scrittura) prima di rilassare i permessi (il fd viene ereditato così com'è): quindi o lo si chiude o si usa una fcntl() per cambiare modalità di accesso.
Mmmh, mi sta venendo un dubbio sull'utilità della fork(), devo investigare (domani sera però :))
Ultima cosa e vado: certo, i fd vengono ereditati dal processo figlio, ma ricordavo erroneamente che i permessi venivano cambiati: ho provato e non è così invece, il processo figlio può scrivere su un file di root se questo è stato aperto (magari in scrittura) prima di rilassare i permessi (il fd viene ereditato così com'è): quindi o lo si chiude o si usa una fcntl() per cambiare modalità di accesso.
Mmmh, mi sta venendo un dubbio sull'utilità della fork(), devo investigare (domani sera però :)) ti ringrazio. per quanto riguarda la fork, che dire... è l'unico paradigma disponibile su Linux per la creazione di nuovi processi, quindi direi che la sua utilità non è messa in dubbio ^^
però in effetti è stata concepita in un'epoca in cui la sicurezza non era forse importante come oggi, e il leak dei FD non era stato preso in considerazione. vorrà dire che vedrò di chiudere il file di configurazione prima di forkare (tanto penso di dover leggere solo quello).
grazie di tutto fidel e buona notte :p
premesso che non lo so e che sto solo gettando i miei 2 cents :p
la risposta dipende dal livello a cui i link simbolici vengono dereferenziati su Linux
in linux si possono trovare tutti i tipi di link esistenti.. gli shell link (come li chiami te) che sono tipicamente dei file .desktop, i link simbolici che sostanzialmente funzionano come gli shell links ma il meccanismo è gestito dal file system e infine gli hard link, cioè quando il link si comporta esattamente come se fosse il file a cui punta, ovviamente anche questo è gestito dal FS.
per quanto riguarda la fork, che dire... è l'unico paradigma disponibile su Linux per la creazione di nuovi processi, quindi direi che la sua utilità non è messa in dubbio ^^
ci sono anche i thread anche se sono meno usati perchè di solito basta un fork ;)
OT, @k0nt3: vedo che combattiamo per gli stessi ideali: no al TC e ai brevetti software :read:
IT: volendo essere esaustivi oltre agli shell link il kernel di Windows NT prevede un ulteriore meccanismo di link: cfr. IoCreateSymbolicLink (http://msdn2.microsoft.com/en-us/library/aa490622.aspx). però MSDN dice che funziona solo con i Device Object, cioè i kernel objects che compongono i Device Stacks. i Device Objects non sono necessariamente uno a periferica: il Device Stack di una periferica è composto tipicamente da almeno due oggetti, talvolta anche di più perché "drivers filtro" ci piazzano gli oggetti loro.
cdimauro
14-05-2007, 08:07
Microsoft Windows [Versione 6.0.6000]
Copyright (c) 2006 Microsoft Corporation. Tutti i diritti riservati.
D:\Test>mklink
Crea un collegamento simbolico.
MKLINK [[/D] | [/H] | [/J]] Collegamento Destinazione
/D Crea un collegamento simbolico a una directory. L'impostazione
predefinita è il collegamento simbolico a un file.
/H Crea un collegamento reale anziché un collegamento simbolico.
/J Crea una giunzione di directory.
Collegamento specifica il nome del nuovo collegamento simbolico.
Destinazione specifica il percorso (relativo o assoluto) a cui fa
riferimento il nuovo collegamento.
OT, @k0nt3: vedo che combattiamo per gli stessi ideali: no al TC e ai brevetti software :read:
\m/ :cool:
IT: volendo essere esaustivi oltre agli shell link il kernel di Windows NT prevede un ulteriore meccanismo di link: cfr. IoCreateSymbolicLink (http://msdn2.microsoft.com/en-us/library/aa490622.aspx). però MSDN dice che funziona solo con i Device Object, cioè i kernel objects che compongono i Device Stacks. i Device Objects non sono necessariamente uno a periferica: il Device Stack di una periferica è composto tipicamente da almeno due oggetti, talvolta anche di più perché "drivers filtro" ci piazzano gli oggetti loro.
si ma questo tipo di link è strettamente collegato alla struttura di windows.. su linux tutto è un file e quindi non avvrebbe senso.
@cdimauro
mi sembrava di aver letto che in Vista era stato introdotto il concetto di collegamento simbolico... 6.0 è Vista vero?
@cdimauro
mi sembrava di aver letto che in Vista era stato introdotto il concetto di collegamento simbolico... 6.0 è Vista vero? esatto, infatti su XP mklink non c'è. non sapevo di questa cosa: le novità introdotte da Windows Vista non finiscono mai.
ilsensine
14-05-2007, 11:59
ilsensine, dove sei?? :D
Il fine settimana LONTANO dai computer :D
ilsensine
14-05-2007, 12:00
esatto, infatti su XP mklink non c'è.
In qualche maniera si possono fare anche su XP, ma solo per le directory.
cdimauro
14-05-2007, 14:26
@cdimauro
mi sembrava di aver letto che in Vista era stato introdotto il concetto di collegamento simbolico... 6.0 è Vista vero?
Sì. Gli hard link, invece, esistono da un pezzo: http://msdn2.microsoft.com/en-us/library/aa363860.aspx
ma anche vero che, IMHO, sono i meno utili.
Hanno fatto bene a introdurre i link simbolici con Vista, copiandone il funzionamento dai sistemi Unix-like: sono comodissimi per risolvere in maniera semplice ed elegante tanti problemi. ;)
@71140
Ah, per lo stralcio di codice su setuid, mi sono accorto di un errore: meglio fare prima setgid, poi setuid (se fai prima setuid verso un utente meno privilegiato, poi la setgid giustamente fallisce).
Ho provveduto a correggere il post, invertendo le chiamate.
@ilsensine:
Mi sta venendo un dubbio: dopo aver fatto chroot+setgid+setuid, quali sarebbero i vantaggi nel fare una fork() (nel caso non si voglia "andare" in daemon mode o altro)?
Scusate lo spam, ma se qualcuno mastica un po' di programmazione OpenGL su C/C++ e potesse dare un'occhiata qui:
http://www.hwupgrade.it/forum/showthread.php?t=1472589
... :stordita:
@71140
Ah, per lo stralcio di codice su setuid, mi sono accorto di un errore: meglio fare prima setgid, poi setuid (se fai prima setuid verso un utente meno privilegiato, poi la setgid giustamente fallisce).
Ho provveduto a correggere il post, invertendo le chiamate. ottimo, grazie.
mi hai invertito due cifre del nick :Prrr:
(e mo la solita storia, tutti a chiedere il significato del nick :stordita: )
mi hai invertito due cifre del nick :Prrr:
(e mo la solita storia, tutti a chiedere il significato del nick :stordita: )
:doh: Non te lo chiedo, però può essere una data per te importante (7/11/04) :D
Oppure il tuo numero di matricola all'università...
:doh: Non te lo chiedo, però può essere una data per te importante (7/11/04) :D
Oppure il tuo numero di matricola all'università... l'ipotesi della data è stata avanzata più volte ma non è così; la matricola dell'università non è perché quella ha più cifre. in origine non era nemmeno 71104: era 71103, solo che poi per un problema del forum quell'account non mi funzionava più e così mi sono reiscritto (dubito che fosse un ban: senza nessun avviso... e poi per quanto io sia troll non avevo fatto niente :D).
l'ipotesi della data è stata avanzata più volte ma non è così; la matricola dell'università non è perché quella ha più cifre. in origine non era nemmeno 71104: era 71103, solo che poi per un problema del forum quell'account non mi funzionava più e così mi sono reiscritto (dubito che fosse un ban: senza nessun avviso... e poi per quanto io sia troll non avevo fatto niente :D).
Mmmh, il numero di righe di codice del programma più lungo da te sviluppato?
Mmmh, il numero di righe di codice del programma più lungo da te sviluppato? neanche; un programma così lungo lo dividerei in molti files, e mi peserebbe il :ciapet: a contare la somma delle righe di tutti i files :D
se lo vuoi sapere te lo dico, non è niente di che, anzi è una cretinata totale: sono due numeri, 71 e 103 (infatti il nick attuale si legge settantuno centoquattro); sono nati da scherzi e cavolate tra compagni di liceo: uno dei primi giorni di scuola del terzo liceo, durante la lezione di chimica (sigh, che bei ricordi :cry: ) mentre io mi annoiavo il mio compagno di banco mi fece notare che sulla tavola degli elementi c'erano due elementi (il 71 e il 103) che avevano due nomi che assomigliavano al cognome suo e a quello di un altro compagno, sicché sembrava che li avessero inventati loro :rotfl:
allora è nato sto numero che mi ossessionava e lo scrivevo dappertutto ogni volta che capitava di dover scrivere un numero fittizio :D
e con ciò il topic è bello che degenerato :P
e con ciò il topic è bello che degenerato :P
:D Vabbé avevamo finito mi pare ;)
ilsensine
15-05-2007, 08:25
@ilsensine:
Mi sta venendo un dubbio: dopo aver fatto chroot+setgid+setuid, quali sarebbero i vantaggi nel fare una fork() (nel caso non si voglia "andare" in daemon mode o altro)?
Nessuno, in verità. La fork in questi casi si usa per diventare demoni o per eseguire una exec. Se non devi fare nessuna di queste cose, non serve.
Nessuno, in verità. La fork in questi casi si usa per diventare demoni o per eseguire una exec. Se non devi fare nessuna di queste cose, non serve.
Benissimo, era quello che volevo sentire :) Infatti non mi tornava l'utilità della fork() in questo caso, ma temevo che mi stessi perdendo qualcosa.
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.