Applicazioni in chroot

Postate qui per tutte le discussioni legate alla sicurezza di Linux/Slackware

Moderatore: Staff

Regole del forum
1) Citare sempre la versione di Slackware usata, la versione del Kernel e magari anche la versione della libreria coinvolta. Questi dati aiutano le persone che possono rispondere.
2) Specificare se discussione/suggerimento o richiesta d'aiuto.
3) Leggere attentamente le risposte ricevute.
4) Scrivere i messaggi con il colore di default, evitare altri colori.
5) Scrivere in Italiano o in Inglese, se possibile grammaticalmente corretto, evitate stili di scrittura poco chiari, quindi nessuna abbreviazione tipo telegramma o scrittura stile SMS o CHAT.
6) Appena registrati è consigliato presentarsi nel forum dedicato.

La non osservanza delle regole porta a provvedimenti di vari tipo da parte dello staff, in particolare la non osservanza della regola 5 porta alla cancellazione del post e alla segnalazione dell'utente. In caso di recidività l'utente rischia il ban temporaneo.
Rispondi
Dani
Linux 4.x
Linux 4.x
Messaggi: 1447
Iscritto il: mer 26 apr 2006, 1:52
Desktop: gnome
Distribuzione: arch

Applicazioni in chroot

Messaggio da Dani »

Qualcuno mi puo' spiegare come creare un ambiente chroot nel quale far girare appliazioni come apache, azureus, amule eccecc ?

Avatar utente
alessiodf
Linux 3.x
Linux 3.x
Messaggi: 823
Iscritto il: ven 14 ott 2005, 21:04
Slackware: current
Kernel: 2.6.26.4
Desktop: Kde 4.1
Località: Roma
Contatta:

Messaggio da alessiodf »

:D l'argomento interessa anche a me! su su postate :p

Avatar utente
Luke88
Linux 3.x
Linux 3.x
Messaggi: 624
Iscritto il: mer 7 set 2005, 0:00
Slackware: 13.0
Kernel: 2.6.30-zen4
Desktop: xfce4
Località: Udine

Messaggio da Luke88 »

Meeting efficency = Average_Intelligence/( Number_Of_People^2 )

pont
Linux 0.x
Linux 0.x
Messaggi: 72
Iscritto il: mer 7 set 2005, 0:00
Kernel: 2.6
Desktop: gnome
Distribuzione: ubuntu

Messaggio da pont »

ciao .....io avevo trovato valide informazioni qui:

http://a2.pluto.it/a2474.htm#almlindex20658

saluti.

Dani
Linux 4.x
Linux 4.x
Messaggi: 1447
Iscritto il: mer 26 apr 2006, 1:52
Desktop: gnome
Distribuzione: arch

Messaggio da Dani »

Il link sembra interessante, lo rileggero' con piu' calma, grazie.

Ma se qualcuno mi exploita un'applicazione ritrovandosi in qualche modo in mano una shell, tenendo conto che l'applicazione bucata giri in chroot, l'attacker non puo' uscire in nessun modo dalla "finta root" ?

Avatar utente
alessiodf
Linux 3.x
Linux 3.x
Messaggi: 823
Iscritto il: ven 14 ott 2005, 21:04
Slackware: current
Kernel: 2.6.26.4
Desktop: Kde 4.1
Località: Roma
Contatta:

Messaggio da alessiodf »

no, in nessun modo! 8)

Avatar utente
masalapianta
Iper Master
Iper Master
Messaggi: 2775
Iscritto il: lun 25 lug 2005, 0:00
Nome Cognome: famoso porco
Kernel: uname -r
Desktop: awesome
Distribuzione: Debian
Località: Roma
Contatta:

Messaggio da masalapianta »

Dani ha scritto:Il link sembra interessante, lo rileggero' con piu' calma, grazie.

Ma se qualcuno mi exploita un'applicazione ritrovandosi in qualche modo in mano una shell, tenendo conto che l'applicazione bucata giri in chroot, l'attacker non puo' uscire in nessun modo dalla "finta root" ?
si, una volta bucato il servizio chrootato ed aver ottenuto accesso locale nella chroot, i primi modi che mi vengono in mente:
- bug del kernel per elevazione dei privilegi da locale
- bug di un demone che gira come root ed e' contattabile via socket di rete passando per loopback (ad esempio se sulla medesima macchina gira un servizio A chrootato e un servizio B utilizzato solo in locale ma che non usa socket di dominio unix, come potrebbe essere un dns solo caching)
- bug di un'applicazione setuid root, disponibile all'interno della jail chroot

Ovviamente sono tutti dei bei "se", ma tu hai chiesto se si puo' uscire dalla jail e non quanto possa esser difficile ;)

Avatar utente
goldy
Packager
Packager
Messaggi: 1267
Iscritto il: lun 3 mag 2004, 0:00
Slackware: Current
Kernel: 2.6.26.5
Desktop: KDE 3.5.10
Località: Bologna
Contatta:

Messaggio da goldy »

masa tu che sei esperto di queste cose ,
discutendo con un mio amico , grande utilizzatore di bsd sui server
mi faceva notare che da questo punto di vista linux
è più vulnerabile , e tra l'altro anche per le ragioni che hai scritto tu appena sopra
Io per curiosità personale avevo fatto alcune ricerche per cercare di capire meglio le differenze tra i due kernel
e ho trovato questo
http://www.programmazione.it/index.php? ... Item=32966
Questa ulteriore "sicurezza" adottata in BSD potrebbe attutire i danni di eventuali bug delle applicazioni che girano sui server?
Sempre in merito alla sicurezza del sistema, ecco un'altra feature interessante: la versione di Apache di OpenBSD, per esempio, viene eseguita in jail (una specie di gabbia da cui il processo non può uscire); niente di nuovo, se non fosse che il chroot del processo è predefinito. In questo modo un malintenzionato potrebbe soltanto far andare in crash il Web Server, senza poter accedere al contenuto del disco, in quanto il processo non ha i diritti per farlo.
C'è anche nel kernel di Linux una cosa del genere?

bloodlust
Linux 3.x
Linux 3.x
Messaggi: 523
Iscritto il: mar 14 feb 2006, 12:02
Slackware: -1
Località: it_IT

Messaggio da bloodlust »

i vserver su Linux sono similari (non la stessa cosa) e non paragonabili a livello di sicurezza e stabilità.
per farti un es. su freebsd sono presenti chiamate di sistema nel kernel già dalla versione 4.x (non ricordo quale nello specifico) mentre su linux devi patchare kernel etc.. e quindi molto più sperimentali.
più che altro il parallelo lo farei con le zone di solaris 10 (con la pecca che non ci puoi far girare nfs..).
inoltre vserver non ha per esempio le delegation e comunque per un minimo di sicurezza dovresti almeno ricorrere a rbac tipo grsecurity (lasciamo perdere selinux che IMO è 'na schifezza).
notte

Avatar utente
masalapianta
Iper Master
Iper Master
Messaggi: 2775
Iscritto il: lun 25 lug 2005, 0:00
Nome Cognome: famoso porco
Kernel: uname -r
Desktop: awesome
Distribuzione: Debian
Località: Roma
Contatta:

Messaggio da masalapianta »

goldy ha scritto:masa tu che sei esperto di queste cose ,
discutendo con un mio amico , grande utilizzatore di bsd sui server
mi faceva notare che da questo punto di vista linux
il tuo amico paragona mele con pere, non puoi paragonare un normale chroot() con le jail di *bsd in quanto il primo ha il solo scopo di far vedere a un processo e i suoi figli una data porzione di fs, mentre il secondo lo isola non solo dal resto del fs; btw su linux si possono implementare delle policy via LSM per far le stesse cose delle jail bsd (ma ha ben poco senso)
Questa ulteriore "sicurezza" adottata in BSD potrebbe attutire i danni di eventuali bug delle applicazioni che girano sui server?
e' pensato per quello, ma ormai son concetti abbastanza superati, in quanto prevedono l'isolamento di un certo ambiente all'interno di un sistema DAC (che in quanto tale, per ottenere un certo grado di sicurezza richiede perlappunto l'isolamento di alcuni processi), mentre e' molto piu' pulito e flessibile adottare un sistema MAC che ti permette di ottenere lo stesso grado di sicurezza senza dover creare dei sottoambienti e mantendendo un enorme flessibilita')

Avatar utente
masalapianta
Iper Master
Iper Master
Messaggi: 2775
Iscritto il: lun 25 lug 2005, 0:00
Nome Cognome: famoso porco
Kernel: uname -r
Desktop: awesome
Distribuzione: Debian
Località: Roma
Contatta:

Messaggio da masalapianta »

bloodlust ha scritto:i vserver su Linux sono similari (non la stessa cosa) e non paragonabili a livello di sicurezza e stabilità.
per farti un es. su freebsd sono presenti chiamate di sistema nel kernel già dalla versione 4.x (non ricordo quale nello specifico) mentre su linux devi patchare kernel etc.. e quindi molto più sperimentali.
paragonare jail di bsd con sistemi tipo vserver o uml e' come paragonare chroot con jail (mele con pere), son cose diverse che si prefiggono scopi diversi
più che altro il parallelo lo farei con le zone di solaris 10 (con la pecca che non ci puoi far girare nfs..).
le zone di solaris non sono ne carne ne pesce, da una parte vorrebbero creare una sorta di virtualizzazione, dall'altra zone e global zone condividono un sacco di cose (che sarebbe stato meglio virtualizzare) e ne negano l'accesso, sotto certe condizioni, alle zone; ad esempio il clock di sistema, se chiami clock_settime() da una zona ti becchi un bellissimo EPERM:

Codice: Seleziona tutto

clock_settime(3, 0xFFBFFC18)     Err#1 EPERM [sys_time]
in quanto nel kernel viene verificato che il chiamante sia la global zone, in caso contrario ti manda a quel paese:

Codice: Seleziona tutto

int
clock_settime(clockid_t clock, timespec_t *tp)
{
...
    if (secpolicy_settime(CRED()) != 0)
        return (set_errno(EPERM));
...
il che e' na bella zozzeria, in quanto, per rimanere sull'esempio del clock di sistema (ma ce ne sarebbero molti altri), se io ho necessita' di sincronizzare l'orario in maniera differente nelle varie zone non posso, mi becco per forza quello settato dalla global zone
(questo, ripeto, e' un esempio stupido, ci sono altri esempi, come lo stack di rete condiviso e relative tabelle di routing, che creano problemi ben piu' seri)
(lasciamo perdere selinux che IMO è 'na schifezza).
perche' pensi questo?

bloodlust
Linux 3.x
Linux 3.x
Messaggi: 523
Iscritto il: mar 14 feb 2006, 12:02
Slackware: -1
Località: it_IT

Messaggio da bloodlust »

masalapianta ha scritto:paragonare jail di bsd con sistemi tipo vserver o uml e' come paragonare chroot con jail (mele con pere), son cose diverse che si prefiggono scopi diversi
non li vedo appartenenti a categorie di virtualizzazione differenti (entrambi virtualizzazione a livello os) tuttalpiù approcci (e risultati) un po' differenti. infatti ho specificato "similari" (ma forse sarebbe più corretto dire simili).
Più che mele e pere direi mele e meline.
Mele e pere potrebbe essere paragonare jail a lpar di ibm.
UML appartiene ad una categoria differente di virtualizzazione (UML esegue in userspace kernel differenti, viene infatti usato anche per debug, cosa che con jail (o vserver o container di sun) non puoi fare).
non si può ridurre vserver ad un semplice chroot perchè non è solo quello (è uno degli strumenti che usa per ottenere lo scopo) ma concordo se mi dici che non si può paragonare il livello di sicurezza offerto dai due.
le zone di solaris non sono ne carne ne pesce, da una parte vorrebbero creare una sorta di virtualizzazione, dall'altra zone e global zone condividono un sacco di cose (che sarebbe stato meglio virtualizzare)
concordo se mi dici che questa tecnologia è ancora (molto) immatura (basta pensare che è una novità di solaris 10 mentre jail è presente nel kernel freebsd già da svariate versioni (e tempo)), ma come concetto e funzionalità offerte è molto più vicina a jail che non vserver o altri.
e ne negano l'accesso, sotto certe condizioni, alle zone; ad esempio il clock di sistema, se chiami clock_settime() da una zona ti becchi un bellissimo EPERM:
in quanto nel kernel viene verificato che il chiamante sia la global zone, in caso contrario ti manda a quel paese:
il che e' na bella zozzeria...se io ho necessita' di sincronizzare l'orario in maniera differente nelle varie zone non posso
questo è un comportamento voluto e conosciuto (e scaturito da una visione di sicurezza e da una struttura sottostante differente rispetto ad altre).
Anche qui le zone sono un concetto un po' differente da quello di jail (altrimenti sarebbero la stessa cosa).
(questo, ripeto, e' un esempio stupido, ci sono altri esempi, come lo stack di rete condiviso e relative tabelle di routing, che creano problemi ben piu' seri)
questa è una peculiarità di questo tipo di virtualizzazione nella quale il kernel è uno soltanto, per cui è normale che determinate strutture di kernel siano uniche e non modificabili dalle zone (es. anche con jail non puoi modificare la routing table. sarebbe venir meno a certi requisiti di sicurezza).
Se si hanno esigenze differenti si sceglie una tecnologia differente.
perche' pensi questo?
affermazione dovuta a (negative) esperienze passate. probabilmente dovute alla mia scarsa conoscenza in merito. lo vedo un po' troppo complicato da gestire per cui questo può portare ad avere sistemi che vengono creduti sicuri ma che in realtà non lo sono.
Non essendo io un esperto di sicurezza spesso mi devo basare sul lavoro fatto da altri e se questo lavoro non è fatto bene chi ci rimette sono anche io.
Ripeto: è una opinione personale e che altri possono confutare facilmente quindi non ci perdo più di tanto tempo.

ciao

Avatar utente
masalapianta
Iper Master
Iper Master
Messaggi: 2775
Iscritto il: lun 25 lug 2005, 0:00
Nome Cognome: famoso porco
Kernel: uname -r
Desktop: awesome
Distribuzione: Debian
Località: Roma
Contatta:

Messaggio da masalapianta »

bloodlust ha scritto:
masalapianta ha scritto:paragonare jail di bsd con sistemi tipo vserver o uml e' come paragonare chroot con jail (mele con pere), son cose diverse che si prefiggono scopi diversi
non li vedo appartenenti a categorie di virtualizzazione differenti (entrambi virtualizzazione a livello os) tuttalpiù approcci (e risultati) un po' differenti. infatti ho specificato "similari" (ma forse sarebbe più corretto dire simili).
Più che mele e pere direi mele e meline.
jail si prefigge come scopo l'isolamento di determinati processi a fini di sicurezza, vserver e uml hanno come scopo la virtualizzazione e l'isolamento dei processi ne e' solo una conseguenza, al limite volendo fare un paragone con jail bisognerebbe prendere in considerazione roba tipo vSecurity (http://pearls.tuxedo-es.org/vsecurity/) e non sistemi di virtualizzazione
non si può ridurre vserver ad un semplice chroot perchè non è solo quello (è uno degli strumenti che usa per ottenere lo scopo) ma concordo se mi dici che non si può paragonare il livello di sicurezza offerto dai due.
uh? e chi ha detto che vserver si riduce ad una chroot()? quel che sto dicendo e' che vserver si prefigge la virtualizzazione come fine, mentre jail no (lo scopo e' isolare, a fini di sicurezza, un gruppo di processi dal resto del sistema)
le zone di solaris non sono ne carne ne pesce, da una parte vorrebbero creare una sorta di virtualizzazione, dall'altra zone e global zone condividono un sacco di cose (che sarebbe stato meglio virtualizzare)
concordo se mi dici che questa tecnologia è ancora (molto) immatura (basta pensare che è una novità di solaris 10 mentre jail è presente nel kernel freebsd già da svariate versioni (e tempo)), ma come concetto e funzionalità offerte è molto più vicina a jail che non vserver o altri.
no, anche le zone di solaris si prefiggono come scopo la virtualizzazione (a differenza di jail)
e ne negano l'accesso, sotto certe condizioni, alle zone; ad esempio il clock di sistema, se chiami clock_settime() da una zona ti becchi un bellissimo EPERM:
in quanto nel kernel viene verificato che il chiamante sia la global zone, in caso contrario ti manda a quel paese:
il che e' na bella zozzeria...se io ho necessita' di sincronizzare l'orario in maniera differente nelle varie zone non posso
questo è un comportamento voluto e conosciuto (e scaturito da una visione di sicurezza e da una struttura sottostante differente rispetto ad altre).
ovvio he e' voluto (quel codice nel kernel non e' certo frutto d'un bug), ma il tutto e' pensato male e crea enormi problemi, in quanto il sistema delle zone non viene proposto come sistema di sicurezza per isolare gruppi di processi dal resto del sistema ma come sistema di virtualizzazione (e come tale non puo' permettersi di avere un design come quello di cui ho portato degli esempi nel precedente post)
(questo, ripeto, e' un esempio stupido, ci sono altri esempi, come lo stack di rete condiviso e relative tabelle di routing, che creano problemi ben piu' seri)
questa è una peculiarità di questo tipo di virtualizzazione nella quale il kernel è uno soltanto, per cui è normale che determinate strutture di kernel siano uniche e non modificabili dalle zone (es. anche con jail non puoi modificare la routing table. sarebbe venir meno a certi requisiti di sicurezza).
Se si hanno esigenze differenti si sceglie una tecnologia differente.
ripeto, continui a paragonare mele con pere: in jail e' giusto e' corretto che la routing table sia una, in quanto jail si prefigge di isolare alcuni processi a fini di sicurezza e non di implementare un sistema di virtualizzazione, mentre le zone di solaris bengono proposte come sistema di virtualizzazione e, in quanto tale, non si puo' permettere di avere grossolani errori di design come quelli di cui ho portato esempi (e che probabilmente son dovuti all'eccessiva fretta di sun di rilasciare un sistema di virtualizzazione, visto che ultimamente questo campo e' in larga espansione e ritardare anche poco, nel proporre un proprio prodotto, significa perdere consistenti quote di mercato)
perche' pensi questo?
affermazione dovuta a (negative) esperienze passate. probabilmente dovute alla mia scarsa conoscenza in merito. lo vedo un po' troppo complicato da gestire per cui questo può portare ad avere sistemi che vengono creduti sicuri ma che in realtà non lo sono.
Non essendo io un esperto di sicurezza spesso mi devo basare sul lavoro fatto da altri e se questo lavoro non è fatto bene chi ci rimette sono anche io.
qualsiasi sistema di MAC e' complesso, o meglio e' complessa la definizione di ruoli e relative regole (rispetto alla controparte DAC), anche grsec piuttosto che rsbac, quando vai a definire i ruoli e le acl, diventano molto complessi, ma non e' un problema di implementazione, piuttosto e' una caratteristica intrinseca dell'architettura; di buono selinux ha che si basa su LSM, il che in ambiente enterprise e' un grossissimo vantaggio.

Dani
Linux 4.x
Linux 4.x
Messaggi: 1447
Iscritto il: mer 26 apr 2006, 1:52
Desktop: gnome
Distribuzione: arch

Messaggio da Dani »

Sono riuscito a chrootare ma credo che ho optato per la soluzione sbagliata...Ad esempio per usare amule in chroot dovrei ricopiare la marea di librerie necessarie, con tutto xorg mi sa :-/
Avrei un sistema "doppio", faccio prima ad usare una macchina virtuale, o sbaglio ?

Magari usare apache o bind, anzichè amule, azureus e simili, potrebbe essere piu' semplice ? Che dite ?

Rispondi