Applicazioni in chroot

[Dani]

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

[alessiodf]

l'argomento interessa anche a me! su su postate

[Luke88]

http://www.slacky.eu/wikislack/index.ph ... oot&go=Vai

di + non zo.

[pont]

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

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

saluti.

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

[alessiodf]

no, in nessun modo!

[masalapianta]

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

[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]

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

[masalapianta]

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

[masalapianta]

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]

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

[masalapianta]

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]

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 ?