# chroot users

## Diggs

Qualcuno di voi ha mai avuto esperienze col chroot degli utenti?

Mi spiego... In parole povere vorrei che tutti gli utenti che addo alla mia box siano "chiusi" esclusivamente in /home/utente1 ... /home/utente2 e così via...

Personalmente, assieme ai consigli di Lilcash ( #gentoo.it at ircnet e Utente di questo forum), ho provato il pacchetto "jail" e non è male.

Ad ogni modo volevo sapere se qualcuno ha utilizzato altri metodi (che non siano possibilmente grsecurity selinux ed ecc ecc)   :Wink:  .

Chiedo cmq se è possibile poster un topic nella sezione "Networking & Security" (non so se sia possibile...   :Embarassed:  ).

My wayHere.

ho tolto il tag [HOW-TO] dal titolo del thread. Questo tag deve essere usato solo quando si postano propri HOW-TO

-- lavish

----------

## Diggs

Proprio nessuno? ...   :Crying or Very sad: 

----------

## cerri

E' quasi impossibile fare quello che dici tu, nel vero senso del termine. Anche jail ti permette un chroot virtuale.

Cosa devono fare i tuoi utenti?

----------

## Diggs

Si infatti jail mi ha permesso questo! YEAH.   :Razz: 

Il fatto è che volevo che gli utenti siano solo ed esclusivamente "confinati" in /home/utente ad esempio.

a) Ho provato rbash [restricted bash] e in effetti confina gli utenti solo che:

1) E' aggirabile.

2) Da utente eseguendo ad esempio cat /etc/*.conf si legge tutto il contenuto di quel file   :Crying or Very sad: 

b) il tool jail è già ottimo di per se, ma permette cmq sia all'utente di muoversi anche in "/" del chroot e non esclusivamente in "/home/utente" del chroot.

Per farla breve: avete presente ad esempio gli isp che offrono accesso shell [sia per psybnc, eggdrop, spazio web ecc ecc]   :Arrow:   ecco io vorrei ottenere una cosa simile   :Sad:  .

----------

## bubble27

Potresti provare con la funzione 

```
        Grsecurity  --->                                 
```

che si trova nel kernel e mi pare ci fosse anche un pacchetto al riguardo.

Se metti un livello alto potrebbe fare quello che stai cercando, xò ti serve configurartelo e sinceramente "io" non saprei aiutarti in questo.

```

  x additional /proc restrictions                                           x   

 --> x chmod restrictions in chroot                                            x   

  x no signals, ptrace, or viewing processes outside of chroot              x   

  x capability restrictions in chroot                                       x   

  x deny fchdir out of chroot                                               x   

  x priority restrictions in chroot                                         x   

  x segmentation-based implementation of PaX                                x   

  x mprotect restrictions                                                   x   

  x removal of /proc/<pid>/[maps|mem]                                       x   

  x kernel stack randomization                                              x   

  x mount/unmount/remount logging                                           x   

  x kernel symbol hiding                                                    x   

```

quest'output proviene dall'help di grsecurity !!!!

non so prova a smanettarci un pò....  :Wink: 

----------

## Diggs

Esatto   :Wink:  .

Come dicevo... devo trovare solo un pò di tempo a disposizione.

"Speriamo che io me la cavo"   :Razz: 

----------

## cerri

Quel tool di grsecurity dovrebbe servire ad evitare i chmod dentro un chroot.

Non ho capito cosa intendi circa jail.

Gli isp che danno shell (e non web, che è un'altra cosa) in genere lavorano in maniera paranoica con i permessi. Ma non possono certo evitare che l'utente esca dalla propria home... altrimenti non farebbe manco un ls...

----------

## alexerre

Uhm, forse ho capito la domanda (ed effettivamente piacerebbe realizzare una cosa simile anche a me  :Rolling Eyes:  )

Ci sono degli ISP (es. quelli che montano sui webserver ENSIM) che danno un accesso via ssh. Dentro a quella sessione si ha un sistema composto dal calssico tree di directory (/ /usr /var /home etc) però sono evidentemente limitate. 

In un occasione ho avuto anche l'accesso come root ad una di queste macchine. Esiste tutta un'impalcatura soprastante - il vero e proprio sistema operativo - però per ogni cliente (che avrà accesso via ssh) viene creato un sottosistema in /var/homeX - dove X sta per il numero del cliente - e da questo sottosistema non si può uscire...

ci ho provato in parecchi modi...ma senza troppi risultati...

Si è capito qualcosa di quello che ho detto?

Ciao

----------

## cerri

Si, allora è chiaro.

Sostanzialmente si tratta di fare:

```
cerri@cerrito on GSM cerri $ ldd `which bash`

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

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

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

        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x43126000)

cerri@cerrito on GSM cerri $ mkdir temp

cerri@cerrito on GSM cerri $ mkdir temp/lib

cerri@cerrito on GSM cerri $ cp /lib/libdl.so.2 temp/lib/

cerri@cerrito on GSM cerri $ cp /lib/libc.so.6 temp/lib/

cerri@cerrito on GSM cerri $ cp /lib/ld-linux.so.2 temp/lib/

cerri@cerrito on GSM cerri $ mkdir temp/bin

cerri@cerrito on GSM cerri $ cp `which bash` temp/bin/

cerri@cerrito on GSM cerri $ su -

Password:

cerrito on GSM root # chroot /home/cerri/temp/ /bin/bash

cerrito on GSM / # ls

bash: ls: command not found

cerrito on GSM / #
```

Come si vede, c'è solo la shell in questo modo, e quella procedura va ripetuta per tutto quello che si vuole nella nuova chroot.

----------

## alexerre

Bella cerri =)

Però come faccio a fare in modo che un utente che mi apre una sessione ssh entri in quel - chiamiamolo sottosistema?

----------

## cerri

Fai uno script che esegue il chroot, dai questo script come shell dell'utente e setti chroot +s.

----------

## Diggs

Uhm!!!

Forse qualcosa tipo questo How-to. 

 :Wink: 

----------

## shev

Si, però ricordiamoci che è una menata pazzesca creare un ambiente chroot con un insieme di comandi, servizi e programmi standard a disposizione. Un lavoraccio. Senza contare che il chroot non è uno dei metodi più sicuri e inviolabili per chiudere un utente in un determinato posto (uscire dal chroot non è poi così difficile...)

----------

## cerri

 *Shev wrote:*   

> (uscire dal chroot non è poi così difficile...)

 

 :Shocked:  In linea teorica è impossibile. L'unica soluzione è avere una shell da un processo che non sia chrooted.

----------

## alexerre

 *Shev wrote:*   

> Si, però ricordiamoci che è una menata pazzesca creare un ambiente chroot con un insieme di comandi, servizi e programmi standard a disposizione. Un lavoraccio.

 

uhm..Altre idee?

 *Shev wrote:*   

> 
> 
>  Senza contare che il chroot non è uno dei metodi più sicuri e inviolabili per chiudere un utente in un determinato posto (uscire dal chroot non è poi così difficile...)

 

Qualche esempio?  :Rolling Eyes:   :Question:   :Question: 

----------

## cerri

 *alexerre wrote:*   

> uhm..Altre idee?

 

Accontentarsi della security data dai permessi sui files.

----------

## shev

 *alexerre wrote:*   

> uhm..Altre idee?

 

Non saprei, si potrebbe giocare di fino con i permessi come suggerito da cerri, usare patch o servizi appositi (non chiedermi quali  :Razz: ). Non ho mai implementato nulla di simile.

 *Shev wrote:*   

> Qualche esempio?   

 

Bhe, chroot di per sè non costruisce nessuna prigione, da solo non basta per mettere in gabbia qualcuno o qualcosa. Basta leggersi con attenzione la pagine di man per averne conferma, come per scoprire un primo metodo per evadere dal chroot (viene detto chiaramente nel man!). Inoltre ci sono vari shellcode ed exploit. Insomma, va bene usare chroot, ma di certo non vale l'equazione "chroot == sicurezza". Bisogna prendere anche altri accorgimenti per creare una gabbia "più" sicura (perchè sicura al 100% non sarà mai).

Di letteratura a riguardo se ne trova parecchia in rete, basta cercare  :Wink: 

----------

## alexerre

ok..cercherò

cmq mi avete dato spunti interessanti...

 :Cool:   :Twisted Evil: 

----------

## randomaze

 *alexerre wrote:*   

> 
> 
>  *Shev wrote:*   
> 
>  Senza contare che il chroot non è uno dei metodi più sicuri e inviolabili per chiudere un utente in un determinato posto (uscire dal chroot non è poi così difficile...) 
> ...

 

Su Linux&C datato Ottobre ne parlano... e pubblicano anche il codice di un exploit.

In sintesi, da dentro il chroot fanno una setreuid() per ritornare ad essere root e dopo un giochino di mkdir, chroot, e cd ..

Se interessa vedo di trascrivere un pezzo di articolo (quando ho tempo e non ho sonno  :Razz:  )

----------

## Diggs

Concordo nel fatto che il chroot o il jail o tool simili possano essere aggirabili. Ritengo tuttavia possano essere un aiuto nel contrasto verso gli attacchi al sistema   :Wink: 

----------

## alexerre

 *proudhomm wrote:*   

> Concordo nel fatto che il chroot o il jail o tool simili possano essere aggirabili. Ritengo tuttavia possano essere un aiuto nel contrasto verso gli attacchi al sistema  

 

senz'altra offrono un limite agli utenti, anche ai più smaliziati...Poi se uno ha voglia di violare la legge/sistemi ... bhe allora   :Rolling Eyes: 

----------

## Diggs

Ho risolto temporaneamente utilizzando per ora grsecurity abbinato all'utility jail (presente nel portage)   :Arrow:   gli utenti hanno i comandi base (tipo ls, mkdir, nano ed ecc ecc) e posono "circolare" esclusivamente nell'ambiente "chrooted".

Per me è più che sufficiente   :Razz: 

----------

## alexerre

 *proudhomm wrote:*   

> Ho risolto temporaneamente utilizzando per ora grsecurity abbinato all'utility jail (presente nel portage)    gli utenti hanno i comandi base (tipo ls, mkdir, nano ed ecc ecc) e posono "circolare" esclusivamente nell'ambiente "chrooted".
> 
> Per me è più che sufficiente  

 

lol  :Very Happy: 

Potresti scrivere un howto su come hai fatto?

I passi fondamentali  :Rolling Eyes: 

grazie  :Wink: 

----------

## Diggs

Ecco qua:

N.B.: Il procedimento di seguito illustrato è adattato secondo le mie esigenze, per cui è a titolo indicativo, per specifiche prendere riferimento agli howto postati a fine reply  :Wink:  .

Compilazione del kernel, aggiungere:

```

[b]Grsecurity  --->

[Selezionare Customized Security Level]

Address Space Protection -->

[*] Address Space Layout Randomization                                     

[*]   Randomize user stack base                                                  

[*]   Randomize mmap() base

[*] Deny writing to /dev/kmem, /dev/mem, and /dev/port

ACL options  --->

[*] Hide kernel processes

Filesystem Protections  --->

Selezionare tutto

Kernel Auditing -->

[*] Exec logging

[*] Resource logging

[*] Log execs within chroot

[*] Chdir logging 

[ ] (Un)Mount logging

[*] IPC logging

[*] Signal logging

[*] Fork failure logging

[ ] Time change logging

Executable Protections  --->

[ ] Enforce RLIMIT_NPROC on execs

[*] Dmesg(8) restriction

[*] Randomized PIDs

[ ] Trusted path execution

Network Protections  --->

[*] Larger entropy pools

[*] Truly random TCP ISN selection

[*] Randomized IP IDs

[*] Randomized TCP source ports

[*] Randomized RPC XIDs

[ ] Socket restrictions

Sysctl support  --->

[*] Sysctl support

Logging Options -->

Così come è

```

N.B: Le parti non specificate od omesse nella configurazione significa che non sono abilitate.

Compilare il kernel.

Emergere chpax gradm grsecurity-base-policy poi:

```

gradm -P

```

e settare la pass di controllo.

Poi:

```
 rc-update add grsecurity default
```

Compilare e rebootare   :Wink: 

Dare le seguenti variabili a sysctl - magari si possono salvare direttamente in /etc/sysctl.conf:

```

kernel.grsecurity.grsec_lock = 0 # Se attivata non potrete modificare dopo le variabili sysctl

kernel.grsecurity.chroot_findtask = 1

kernel.grsecurity.rand_rpc = 1

kernel.grsecurity.dmesg = 1

kernel.grsecurity.rand_isns = 1

kernel.grsecurity.rand_tcp_src_ports = 1

kernel.grsecurity.rand_ip_ids = 1

kernel.grsecurity.chroot_deny_sysctl = 1

kernel.grsecurity.chroot_caps = 1

kernel.grsecurity.chroot_restrict_nice = 1

kernel.grsecurity.chroot_deny_mknod = 1

kernel.grsecurity.chroot_deny_chmod = 1

kernel.grsecurity.chroot_enforce_chdir = 1

kernel.grsecurity.chroot_deny_pivot = 1

kernel.grsecurity.chroot_deny_chroot = 1

kernel.grsecurity.chroot_deny_fchdir = 1

kernel.grsecurity.chroot_deny_mount = 1

kernel.grsecurity.chroot_deny_unix = 1

kernel.grsecurity.chroot_deny_shmat = 1

kernel.grsecurity.execve_limiting = 1

kernel.grsecurity.fifo_restrictions = 1

kernel.grsecurity.linking_restrictions = 1

```

O cmq sia dare un bel "sysctl -a | grep grsecurity" e settare i valori trovati a 1.

D'ora in poi i vostri utenti non potranno eseguire completamente ad esempio il comando "ps aux", riporto un esempio:

```

login as: rotweil

rotweil@192.168.1.1's password:

Last login: Fri Feb  6 06:20:27 2004

Ciao :-)

rotweil@gateway rotweil $ ps aux

USER       PID %CPU %MEM   VSZ  RSS TTY      STAT START   TIME COMMAND

rotweil   3246  0.5  0.9  5992 1744 ?        S    08:35   0:00 sshd: rotweil@pty

rotweil   3248  1.5  0.7  4692 1420 pty/s2   S    08:35   0:00 -bash

rotweil   3254  0.0  0.4  2892  824 pty/s2   R    08:35   0:00 ps aux

rotweil@gateway rotweil $

```

Preparare l'ambiente "virtuale"

```

emerge jail

```

L'utility verrà installata   :Wink: 

Dopo cioò, per testare proviamo a crare una directory in cui chiudiamo gli utenti e che faremo risiedere in /var/chroot.

```

adduser test -m -G users -s /usr/bin/jail

nano /etc/passwd -- cercare entry di test e sostituire la sua home con /var/chroot

mkjailenv /var/chroot # /var/chroot è la director in cui "chiudiamo" gli utenti

addjailuser /var/chroot /home/test /bin/bash test # addiamo l'utente test alla jail

addjailsw /var/chroot # addiamo utility di base come ls, chdir, cat alla jail

addjailsw /var/chroot -P bash # addiamo la bash alla jail

```

Come si nota dall'ultima riga il comando per aggiungere programmi alla jail è

```

addjailsw /var/chroot -P *programma*

```

Et voilà la jail è pronta per l'uso   :Wink:  .

Se poi ad esempio vogliamo che i nostri utenti chiusi nella jail possano utilizzare i comandi "uptime ps w" ed ecc ecc basterà creare la directory proc nella dir in cui chiudiamo gli utenti: nel mio caso sarà:

```

mkdir /var/chroot/proc

mount -t proc proc /var/chroot/proc

```

e quindi

```

addjailsw /var/chroot -P ps

addjailsw /var/chroot -P uptime

addjailsw /var/chroot -P w

```

Riporto il mio caso: user test e jail in /var/chroot   :Wink: 

```

gateway etc # su tester

gateway tester $ w

 08:52:08 up  2:34,  3 users,  load average: 0,12, 0,03, 0,01

USER     TTY        LOGIN@   IDLE   JCPU   PCPU WHAT

gateway tester $ ps

  PID TTY          TIME CMD

 3317 pty/s1   00:00:00 su

 3318 pty/s1   00:00:00 bash

 3320 pty/s1   00:00:00 ps

gateway tester $ ps aux

USER       PID %CPU %MEM   VSZ  RSS TTY      STAT START   TIME COMMAND

tester    3317  0.0  0.5  4500  992 pty/s1   S    08:52   0:00 su tester

tester    3318  0.0  0.7  4680 1336 pty/s1   S    08:52   0:00 jail

tester    3321  0.0  0.4  2868  820 pty/s1   R    08:52   0:00 ps aux

gateway tester $

```

Come si può ben vedere anche la jail risente dell'effetto di grsecurity   :Wink: 

Inoltre:

1) in questo modo neghiamo l'accesso a comandi tipo ifconfig sysctl ed ecc ecc in quanto non li abbiamo addati alla jail con "addjailsw /var/chroot -P programma"   :Wink: 

2) Volendo possiamo utilizzare le utility chattr e lsattr per prevenire script kiddies, riporto da un tips&trick della gwn [non mi ricordo di che settimana]:

```

Per settare gli attributi di un file, usate il comando chattr mentre per visualizzare gli attributi, utilizzate il comando lsattr 

Code listing 8.2: Esempio di utilizzo di chattr e lsattr

 

// Imposta il bit 'immutable' su un file in modo che non possa essere né modificato né cancellato

# chattr +i myfile

# lsattr myfile

----i-------- myfile

// Testiamo il flag 'immutable' cercando di cancellare il file

# rm myfile

rm: cannot remove `myfile': Operation not permitted

// Impostiamo myfile in modalità 'solo concatenamento'

# chattr +a myfile

# lsattr myfile

-----a------- myfile

# echo testing > myfile

myfile: Operation not permitted

# echo testing >> myfile

// nessun errore - il file è stato concatenato

 

Questi attributi sono utili, ad esempio, per assicurarsi che alcuni file importanti non siano accidentalmente candellati. Ricordate che nemmeno root può cancellare un file con gli attributi 'immutable' o 'append-only' senza prima rimuovere esplicitamente questi attributi. L'uso di questi flag sui file /etc/passwd o /etc/shadow li mette al sicuro da un accidentale rm -f e oltretutto assicura che con un exploit non possano essere creati nuovi account. Mantere dei file 'append-only' implica che, una volta scritti, i dati che contengono non possono essere cancellati. I log sono ottimi candidati a questo utilizzo, in modo che non possano essere alterati. Con chattr e lsattr, avete dunque dei nuovi strumenti per mantenere sicuro il vostro sistema. 

```

Tali utility possono essere usate nell'ambiente /var/chroot/bin /var/chroot/usr/bin e così via...

3) E' possibile [e nessuno lo vieta] cancellare eventualmente i file e directory che non sono necessari all'interno di /var/chroot   :Wink: 

The end!!!  

Ulteriori note:

1) Sono un lamer   :Razz:   per cui ciò che ho scritto può non andare nel caso vostro   :Razz:  , difatti sono felicissimo se qualcuno possa correggermi   :Razz: 

2) Per la parte relativa all'utility jail i miei ringraziamenti a Lilcash di #gentoo.it su IRCNET   :Wink: 

3) Se qualcuno ha idee migliori ed ecc ecc è pregato di postare   :Wink: 

Riferimenti:

Gentoo&grsecurity

The jail utility

----------

## alexerre

 *proudhomm wrote:*   

> Ecco qua:
> 
> 

 

grazie proudhomm appena ho un attimo di tempo provo anch'io a creare questa "prigione" con jail  :Very Happy: 

PS Per curiosita': che kernel hai usato?

----------

## Diggs

Ho usato gentoo-sources   :Wink:  Che contiene già la patch grsecurity nonchè il supporto acl in ext3 e ext2 [utili nel mio caso].

Ho riportato anche alcune cose che mi ero tralasciato, i'm sorry!

----------

## Diggs

Ecco l'output di nmap dopo aver applicato grsecurity:

```

nmap -O [my_ip]

Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) at 2004-02-07 05:04 CET

Interesting ports on [my_ip]:

(The 1658 ports scanned but not shown below are in state: closed)

PORT    STATE SERVICE

110/tcp open  pop3

No exact OS matches for host (If you know what OS is running on it, see http://www.insecure.org/cgi-bin/nmap-submit.cgi).

TCP/IP fingerprint:

SInfo(V=3.50%P=i686-pc-linux-gnu%D=2/7%Time=402463FD%O=110%C=1)

TSeq(Class=TR%IPID=RD%TS=U)

T1(Resp=Y%DF=Y%W=7FFF%ACK=S++%Flags=AS%Ops=MNW)

T2(Resp=N)

T3(Resp=Y%DF=Y%W=7FFF%ACK=S++%Flags=AS%Ops=MNW)

T4(Resp=Y%DF=Y%W=0%ACK=O%Flags=R%Ops=)

T5(Resp=Y%DF=Y%W=0%ACK=S++%Flags=AR%Ops=)

T6(Resp=Y%DF=Y%W=0%ACK=O%Flags=R%Ops=)

T7(Resp=Y%DF=Y%W=0%ACK=S++%Flags=AR%Ops=)

PU(Resp=Y%DF=N%TOS=C0%IPLEN=164%RIPTL=148%RID=E%RIPCK=E%UCK=E%ULEN=134%DAT=E)

```

 :Surprised: 

----------

## alexerre

Riuppo questo thread xke' ho provato ad usare jail ma ho qualche problema  :Sad: 

 *proudhomm wrote:*   

> 
> 
> ```
> 
> adduser test -m -G users -s /usr/bin/jail
> ...

 

qui fai addjailsw /home/chroot ma nn dovrebbe essere /var/chroot?

 *proudhomm wrote:*   

> 
> 
> Come si nota dall'ultima riga il comando per aggiungere programmi alla jail è
> 
> ```
> ...

 

Sono arrivato fino ad aggiungere mutt come ulteriore programma. 

Una volta finito se cerco di fare 

```

#su - pippo //pippo e' il mio utente chrootato

```

l'errore che jail mi restituisce e' il seguente:

```

jail: execve() : Permission denied

```

premetto che non ho grsecurity installato e che ho seguito punto per punto le tue istruzioni..Qualche idea??

 EDIT 

Non avevo impostato la partizione dove eseguo il chroot come eseguibile quindi jail falliva...

Ho risolto  :Very Happy: 

EDIT 2.0

Allora l'ambiente chrootato funziona alla perfezione, pero' ho un dubbio/problema: ho "importato" mutt nel chroot. Se provo a spedire una mail mutt mi dice

```

Error sending message, child exited 127 (Exec error.).

```

mi e' venuto il sospetto che io debba importare anche postfix la dentro...E' una vaccata quella che ho pensato oppure sa' da fare?

----------

## Diggs

Hai ragione alexerre, mi sono sbagliato a scriver   :Embarassed:  .

Per quanto riguarda mutt: si dovresti "chrootare" anche postfix.

Sto "testando" e "smanettando" svariate soluzioni co questo "howt-to" [sono una frana   :Crying or Very sad:  ]. 

Ad ogni modo, posterò modifiche ed altro   :Wink: 

----------

## alexerre

 *proudhomm wrote:*   

> Hai ragione alexerre, mi sono sbagliato a scriver   .
> 
> Per quanto riguarda mutt: si dovresti "chrootare" anche postfix.
> 
> 

 

Stavo pensandoci anche io, infatti è tra i miei TODO [sto anche cercando di installare una rete wireless ipsec in casa  :Smile: ]

 *proudhomm wrote:*   

> 
> 
> Sto "testando" e "smanettando" svariate soluzioni co questo "howt-to" [sono una frana   ]. 
> 
> Ad ogni modo, posterò modifiche ed altro  

 

 :Question:  mi sa che ti sei dimenticato un link  :Rolling Eyes: 

----------

## kaio

[quote="alexerre"]Riuppo questo thread xke' ho provato ad usare jail ma ho qualche problema  :Sad: 

Anche a me dà il seguente problema:

```
jail: execve() : Permission denied 
```

Che posso fare?

----------

## ProT-0-TypE

Qua hanno un errore simile. 

Io uso jail emerso dal portage è ho avuto lo stesso errore segnalato nel bug (jail: execve() : No such file or directory, che non è proprio lo stesso tuo..)

Tra l'altro tramite /etc/security/chroot.conf e pam è possibile avere un ssh chrooted

----------

## kaio

Alla fine ho risolto facendo un 

```
ldd /bin/bash
```

 per vedere le dipendenze ed in effetti mancava una libreria da copiare nell'ambiente chroot ovvero ld-linux.so

Ora però avrei un altro problema, ovvero dovrei dare la possibilità all'utente chrootato di cambiarsi la password. La sola copia di passwd ovviamente non basta, immagino che bisogna tirarsi dietro le librerie PAM etc.. 

Qualcuno ha fatto qualcosa del genere?

----------

## kaio

Finalmente ho ottenuto col pacchetto jail un ambiente ristretto e dopo che l'utente ha fatto login viene buttato nell'ambiente chroottato.

Ora però dovrei dare la possibilità agli utenti di cambiarsi la password. Purtroppo però, da quello che ho capito, bisognerebbe far cambiare la password al di fuori del chroot, ovvero sul /etc/shadow non chrootato.

Qualcuno di voi ha qualche idea?

Grazie!

----------

## X-Drum

dai la possibilità di cambiarla nel chroot (agirai sul file fittizzio delle password)

poi fai uno script (da mettere in cron) che ogni N minuti o N volte al giorno,

sincronizza le password degli utenti se modificati con il file al di fuori

del chroot....ma:

-il cambio di pswd non è immediato, devi dare notifica di questo

-non è una soluzione elegantissima ma dovrebbe preservare la sicurezza

questa è una strada non la migliore lo ammetto ma vedi se puo fare 

al caso tuo

----------

## kaio

Tu l'hai già provata? Hai qualche esempio dal quale trarre spunto?

Grazie!

----------

## gutter

Solo una domanda: ma in questa situazione non sarebbe meglio usare un sistema di autenticazione di rete?

----------

## kaio

Sì, è vero, però non ho a disposizione nessun altro sistema di autenticazione.

Avevo letto della possibilità di far girare un demone che giri su localhost che intercetti tutte le chiamate di passwd e che le rigira nel sistema chrootato (vedi pacchetto socat)

----------

