Applicazioni in chroot
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.
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.
Applicazioni in chroot
Qualcuno mi puo' spiegare come creare un ambiente chroot nel quale far girare appliazioni come apache, azureus, amule eccecc ?
-
- Linux 0.x
- Messaggi: 72
- Iscritto il: mer 7 set 2005, 0:00
- Kernel: 2.6
- Desktop: gnome
- Distribuzione: ubuntu
ciao .....io avevo trovato valide informazioni qui:
http://a2.pluto.it/a2474.htm#almlindex20658
saluti.
http://a2.pluto.it/a2474.htm#almlindex20658
saluti.
- masalapianta
- 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:
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" ?
- 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
- 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:
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?
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?
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.
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
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
- 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:
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?
- masalapianta
- 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:
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));
...
(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)
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
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.
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
Anche qui le zone sono un concetto un po' differente da quello di jail (altrimenti sarebbero la stessa cosa).
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.
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.
Ripeto: è una opinione personale e che altri possono confutare facilmente quindi non ci perdo più di tanto tempo.
ciao
- masalapianta
- 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:
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.
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 ?
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 ?