chroot

[-fidel-]

Originariamente inviato da ^TiGeRShArK^

che casino

Addirittura per 4 linee di codice....

Originariamente inviato da ^TiGeRShArK^

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.

[71104]

sigh fidel non so come ringraziarti

però non ho ancora finito con le domande

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)??
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??
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

grazie 1000 per la tua pazienza

[-fidel-]

Originariamente inviato da 71104

sigh fidel non so come ringraziarti

però non ho ancora finito con le domande

Originariamente inviato da 71104

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)??

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)

Originariamente inviato da 71104

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").

Originariamente inviato da 71104

e poi altra cosa: come mai per cambiare l'UID di un processo non devo fare nessun tipo di logon??
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

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

[^TiGeRShArK^]

Originariamente inviato da -fidel-

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
l'unica riga di codice senza bug è quella che non è stata scritta
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

[-fidel-]

Originariamente inviato da ^TiGeRShArK^

:
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:

Originariamente inviato da ^TiGeRShArK^

in questo modo si ha una soluzione che funge sia su win che su linux

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) ).

[^TiGeRShArK^]

Originariamente inviato da -fidel-

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) ).

La versione Real-Time però è un discreto casino dal poco ke ho visto

[71104]

Originariamente inviato da -fidel-

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

OOOOOOOOOOOOra ho capito

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
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?

[71104]

ah poi altra cosa, a proposito di questa getpwnam: ma quand'è che fallisce questa funzione? perché vedo che restituisce informazioni direi abbastanza sensibili...
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.

[k0nt3]

Originariamente inviato da -fidel-

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?

[-fidel-]

Originariamente inviato da 71104

ah poi altra cosa, a proposito di questa getpwnam: ma quand'è che fallisce questa funzione? perché vedo che restituisce informazioni direi abbastanza sensibili...

Fallisce al solito per errori di I/O, o per interruzione causata da una signal, memoria insufficiente a contenere la struct ( )
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".

Originariamente inviato da 71104

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.

[71104]

Originariamente inviato da k0nt3

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
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?

[71104]

Originariamente inviato da -fidel-

Fallisce al solito per errori di I/O, o per interruzione causata da una signal, memoria insufficiente a contenere la struct ( )
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"...

ma poi ad essere sincero anche il solo elenco degli utenti a me sembra una informazione potenzialmente sensibile
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?

[-fidel-]

Originariamente inviato da k0nt3

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()).

[-fidel-]

Originariamente inviato da 71104

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"...

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".

Originariamente inviato da 71104

ma poi ad essere sincero anche il solo elenco degli utenti a me sembra una informazione potenzialmente sensibile
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 () 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.

[-fidel-]

Originariamente inviato da 71104

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?

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ò )

[71104]

Originariamente inviato da -fidel-

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

[k0nt3]

Originariamente inviato da 71104

premesso che non lo so e che sto solo gettando i miei 2 cents
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

[71104]

OT, @k0nt3: vedo che combattiamo per gli stessi ideali: no al TC e ai brevetti software

IT: volendo essere esaustivi oltre agli shell link il kernel di Windows NT prevede un ulteriore meccanismo di link: cfr. IoCreateSymbolicLink. 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]

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.

[k0nt3]

Originariamente inviato da 71104

OT, @k0nt3: vedo che combattiamo per gli stessi ideali: no al TC e ai brevetti software

\m/

Originariamente inviato da 71104

IT: volendo essere esaustivi oltre agli shell link il kernel di Windows NT prevede un ulteriore meccanismo di link: cfr. IoCreateSymbolicLink. 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?