Applicazioni in chroot
Inviato: dom 15 apr 2007, 3:02
Qualcuno mi puo' spiegare come creare un ambiente chroot nel quale far girare appliazioni come apache, azureus, amule eccecc ?
si, una volta bucato il servizio chrootato ed aver ottenuto accesso locale nella chroot, i primi modi che mi vengono in mente: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" ?
C'è anche nel kernel di Linux una cosa del genere?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.
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)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
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')Questa ulteriore "sicurezza" adottata in BSD potrebbe attutire i danni di eventuali bug delle applicazioni che girano sui server?
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 diversibloodlust 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.
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:più che altro il parallelo lo farei con le zone di solaris 10 (con la pecca che non ci puoi far girare nfs..).
Codice: Seleziona tutto
clock_settime(3, 0xFFBFFC18) Err#1 EPERM [sys_time]
Codice: Seleziona tutto
int
clock_settime(clockid_t clock, timespec_t *tp)
{
...
if (secpolicy_settime(CRED()) != 0)
return (set_errno(EPERM));
...
perche' pensi questo?(lasciamo perdere selinux che IMO è 'na schifezza).
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).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
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.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)
questo è un comportamento voluto e conosciuto (e scaturito da una visione di sicurezza e da una struttura sottostante differente rispetto ad altre).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
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).(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)
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.perche' pensi questo?
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 virtualizzazionebloodlust ha scritto: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).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
Più che mele e pere direi mele e meline.
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)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.
no, anche le zone di solaris si prefiggono come scopo la virtualizzazione (a differenza di jail)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.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)
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 è un comportamento voluto e conosciuto (e scaturito da una visione di sicurezza e da una struttura sottostante differente rispetto ad altre).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
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)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).(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)
Se si hanno esigenze differenti si sceglie una tecnologia differente.
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.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.perche' pensi questo?
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.