# Chroot e servizi

## m_wakko

Ciao a tutti, ho una domanda sul chroot...

Facendo il chroot diciamo in "/pippo" ed avviando lì dentro alcuni servizi, ad esempio apache o dei compilatori, questi possono accedere al fs fuori da pippo?

Credo di no, ma nn ci giurerei.

il fatto è lì dentro si potrebbero ancora fare dei danni (es.lanciare fdisk, accedere alla rete)...

La mia necessità è di creare una specie di "sandbox" dove poter compilare vari programmi (pascal,c,c++,java,etc...) in sicurezza senza che loro possano accedere filesystem e rete (in tal caso possono tranquillamente crashare...)

Questo è un problema scolastico di un mio conoscente professore, se non riesco a trovare velocemente una soluzione credo che potrebbe perdere il treno per le sovvenzioni che ha richiesto per poter far partecipare i suoi alunni ad alcune gare d'informatica.

Grazie per tutto l'aiuto che potete darmi.

Ciao.

----------

## gutter

 *m_wakko wrote:*   

> 
> 
> Facendo il chroot diciamo in "/pippo" ed avviando lì dentro alcuni servizi, ad esempio apache o dei compilatori, questi possono accedere al fs fuori da pippo?
> 
> 

 

No.

 *m_wakko wrote:*   

> 
> 
> La mia necessità è di creare una specie di "sandbox" dove poter compilare vari programmi (pascal,c,c++,java,etc...) in sicurezza senza che loro possano accedere filesystem e rete (in tal caso possono tranquillamente crashare...)
> 
> 

 

Emerge utilizza una sandbox per la compilazione del sw.

----------

## drizztbsd

Ciao,

la cosa piu' semplice sarebbe usare una jail bsd (gentoo/freebsd?)

Con linux puoi provare con grsec/selinux che comprendono delle patch per rendere le chroot sicure e altre cosette oppure con uml, xen, virtuozzo, etc

----------

## m_wakko

Esattamente...ho postato qui per questo motivo (oltre ad essere un utente fissato  :Smile:  )

Portage utilizza qualche tool esterno per fare la compilazione in sandbox oppure fa tutto lui?

I vari pacchetti per gentoo devono essere consapevoli di essere in una sendbox?

Cosa mi consigliate per informarmi?

Leggere il sorgente di portage? :-O

Invece com'è l'utilizzo di xen su gentoo?

E' possibile avviare una macchina virtuale con delle limitazioni?

Grazie ancora.

----------

## m_wakko

@Drizzt Do` Urden

Ho letto adesso il tuo post...

vorrei approfondire le tue idee.. ma ora devo scappare ad un appuntamento.

Riposto più tardi.

Ciao

----------

## Scen

Ti consiglio di valutare l'utilizzo di UserMode Linux, se ti vuoi creare degli ambienti isolati dal sistema principale, nel quale fare tutte le schifezze che vuoi!  :Laughing: 

con UML, inoltre, hai la possibilità di accedere ai file dell'host principale dalla virtual machine (il che è comodo, in molti casi), e altre cose ancora  :Cool: 

----------

## m_wakko

Grande, mi sa che uml è la soluzione migliore!

Se ho capito bene 2 sistemi "virtuali" possono essere eseguiti contemporaneamente, giusto?

Se sì, possono comunicare tra loro, ed in che modo?

Un ultima cosa.

Qualcuno ha provato questa soluzione?

Mi interesserebbero 3 aspetti:

1) Performance

2) Stabilità

3) Sicurezza (vabbè, questa credo sia intrinseca...)

Ciao

----------

## Scen

Puoi creare ed usare anche più di 2 sistemi virtuali, l'unica limitazione è la capacità del sistema ospitante (processore, memoria, dischi rigidi); puoi farli comunicare tra di loro creando delle reti virtuali, puoi anche collegarli al mondo esterno tramite l'host principale, e per queste cose puoi usare il pacchetto NetKit, definito anche  The poor man system for experimenting computer networks  :Wink: 

Per i 3 aspetti:

1) Performance: abbastanza buona, anche se al crescere delle vm attive cresce il carico totale sul sistema, con conseguente decadimento delle prestazioni. Penso che se l'host principale è un computer abbastanza recente e abbastanza carrozzato, 2-3 vm riesci a gestirle senza problemi!

2) Stabilità: sto provando anche io da poco UML, quindi non so dirti con certezza come sia la stabilità, ma leggendo un pò di pareri qui e lì nel forum sembra vada bene  :Smile:  Poi tutto dipende da cosa esegui nella vm!  :Razz: 

3) ci mancherebbe  :Rolling Eyes: 

----------

## m_wakko

ok ok...figo!

mi sta esaltando tantissimo questa cosa!

Soprattuto il fatto che si possono collegare gli standard input/output dei vari sistemi virtuali.

Su internet si trovano immagini diverse a seconda dei servizi che si vuole avere...

Ad esempio:

-immagine1:sistema_base

-immagine2:sistema_base+apache+php

Non ho capito bene la cosa...

Cioè io posso installare il base e poi tramite "uml_switch" entrare nel sistema virtuale ed installare le varie cose?

----------

## comio

ti crei un ambiente in cui: in dev metti solo quello che serve (nulla?) in /bin, /usr/bin, /sbin, /usr/sbin, ci metti solo le cose che servono (praticamente bash ed il compilatore).

Attento solo alle librerie che servono per eseguire i vari comandi. Per sapere quali librerie sono necessarie per un programma usa ldd. Per esempio:

```

 comio@fermi ~ $  ldd /bin/bash

        linux-gate.so.1 =>  (0xffffe000)

        libncurses.so.5 => /lib/libncurses.so.5 (0xb7ed5000)

        libdl.so.2 => /lib/libdl.so.2 (0xb7ed1000)

        libc.so.6 => /lib/libc.so.6 (0xb7db5000)

        /lib/ld-linux.so.2 (0xb7f1b000)

```

in giro credo che ci siano degli ambienti minimali, dovresti cercarli.

luigi

----------

## Luca89

 *m_wakko wrote:*   

> Cioè io posso installare il base e poi tramite "uml_switch" entrare nel sistema virtuale ed installare le varie cose?

 

uml_switch serve solamente per creare uno switch virtuale in modo da poter far comunicare le varie macchine virtuali. Qua trovi una guida che ti spiega tutto, compilazione del kernel, installazione del sistema operativo, creazione di un rete virtuale.

----------

## .:chrome:.

 *m_wakko wrote:*   

> Grande, mi sa che uml è la soluzione migliore!

 

non sempre.

l'emulazione è conveniente quando devi replicare ed isolare porzioni importanti si un sistema in produzione. se devi siolare un solo servizio non ne vale la pena (spendo 100 per avere 10), ed avere una VM dedicata per ogni servizio è improponibile (spendo 10000000 per avere 10).

personalmente ti direi di rimanere su chroot, che con portage è anche molto semplice da realizzare in modo semi-automatico, e di incattivirla con GRSecurity. io ho fatto qualche prova, e per quello che devo fare io è ancora la soluzione migliore (quella che mi permette di fare tutto ciò che voglio, nulla di meno, con il minimo sforzo). ovviamente bisogna valutare bene caso per caso, quindi se specifichi chiaramente cosa e quanti servizi vuoi ingabbiare, su quante macchine, ecc... se ne può parlare in termini più concreti.

HINT: se scegliessi la strada dell'emulazione, guardati bene in giro. UML non è l'unico sistema, ce ne sono molti altri. anche qui vale il solito discorso: dipende dal tuo caso; ma in generale si puuò dire che ormai UML sia stato ampiamente superato su tutti i fronti. oggi come oggi io non lo considererei neanche più a favore di uno tra XEN e VServer

----------

## ProT-0-TypE

io opterei per vserver. Utilizzando un solo kernel (quello del sistema principale) sicuramente ci guadagni in prestazioni.

Diciamo che è la cosa più simile alle jail di freebsd

----------

## m_wakko

Umh...ora ho le idee un po' confuse...

Ok, vi spiego bene qual'è il problema...

Praticamente il sistema è un client-server. Il server riceve degli stralci di codice da i vari client e per ognuno deve:

1) Compilarlo

2) Eseguirlo

3) Rispondere con alcuni messaggi di errore o un bel ok.

Prima che mi chiediate l'utilità di tale sistema vo lo dico io...serve per delle gare di programmazione.

I vari utenti possono mandare codice in c,c++,pascal,java,perl,c#,python,etc... (comunque un numero limitato di linguaggi).

Il problema è che il codice che il server deve eseguire potrebbe essere di tutto... ad esempio un semplice "rm -r /" fatto dal primo simpaticone tirerebbe giù il servizio.

Chiamerò "sistema ospite" quello normale e "sistema ospitato" quello emulato.

Fino ad ora consideravo UML, quindi avevo pensato una soluzione del genere.

- Nel server, sul sistema ospite gira apache 

- Questo tramite qualcosa gira il codice ricevuto al sistema ospitato

- In quest'ultimo si compila e si esegue il codice

- Apache nel sistema ospite legge il risultato dal sistema ospitato

- Ogni tanto (oppure ad ogni esecuzione) viene dato un bel "mv SistemaTemplate SistemaUML" tanto per non rischiare

Questo è più o meno tutto...Certo si potrebbe dare dei cappi agli utenti (tipo nn possono accedere al fs o alla rete), ma poi bisognerebbe sbattersi nel parserizzare tutti i codici...

Aspetto vostri consigli

Tnx

----------

## m_wakko

ok, ho detto una cavolata...quella di riavviare il sistema ospitato spesso...

non avevo capito che c'è un tempo di avvio (almeno così ho capito ora)...avevo in mente il modello di chroot...

----------

## Luca89

Ma perchè non usare semplicemente un accesso ssh da parte dei client al server? Gli utenti solitamente possono scrivere file solo nella loro home, quindi non vedo perchè dovrebbero distruggerti tutto. Al limite se proprio vuoi stare ultra-tranquillo metti un chroot o una macchina virtuale con sshd,gcc,python,perl,bash,coreutils e tutto ciò che serve ai client.

----------

## m_wakko

Gli utenti non potranno accedere assolutamente al server.

Loro interagiscono con il programma client che comunicherà con il serve al quale è diretto il "lavoro sporco".

L'idea di macchina virtuale (intesa come vmware o qemu) non piaceva per via della stabilità/disponibilità/performance.

Ma se uno fa il chroot in /pippo e da lì esegue il programma "sw_pericolosissimo_che_ti_fotte_il_fs" questo influisce solo su /pippo oppure su tutto?

Ad esempio può fare fdisk?

----------

## Luca89

 *m_wakko wrote:*   

> Ma se uno fa il chroot in /pippo e da lì esegue il programma "sw_pericolosissimo_che_ti_fotte_il_fs" questo influisce solo su /pippo oppure su tutto?
> 
> Ad esempio può fare fdisk?

 

A meno che non vi siano falle di sicurezza nel kernel le applicazione lanciate da un ambiente chroot non possono interagire con il sistema principale. fdisk credo che possano farlo, basta che hanno il corrispondente file in /dev.

----------

## randomaze

 *Luca89 wrote:*   

> A meno che non vi siano falle di sicurezza nel kernel le applicazione lanciate da un ambiente chroot non possono interagire con il sistema principale. fdisk credo che possano farlo, basta che hanno il corrispondente file in /dev.

 

Infatti, se lo scopo del chroot é la sicurezza, dovrebbe essere minimale anche il numero di device presenti in /dev.

Se é presente /dev/hda ci vuole poco a brasare il sistema...

----------

## m_wakko

Ma i dispositivi in dev nn vengono messi automaticamente quando si fa il chroot...tipo copiati dal dev originale (centra qualcosa l'opzione bind???)  ?

Si può fare un chroot tenendo una dev vuota o quasi? I compilatori in fin dei conti a che dispositivi devono accedere?

Risolto questo a qualcuno vengono in mente altri problemi? Cioè che danni potrebbe fare un programma qualsiasi che viene fatto girare in un chroot (con pochi dispositivi) che non si possano risolvere riscrivendo la directory da chrootare...qualcosa con la rete? beh, se nn c'è /dev/eth* però....

@randomaze: Bellissimo il termine "Brasare il sistema"...da oggi userò sempre quello! Inoltre è multipiattaforma!

----------

## randomaze

 *m_wakko wrote:*   

> Ma i dispositivi in dev nn vengono messi automaticamente quando si fa il chroot...tipo copiati dal dev originale (centra qualcosa l'opzione bind???)  ?

 

Non automaticamente ma quando fai il "mount -o bind ..." della dierctory  :Wink: 

Per sapere quali mettere e quali no... io approccerei con "nessuno" aggiungendo di volta in volta quelli necessari. Ma con questo sistema ci vuole un poco di tempo e pazienza.

----------

