Alzi la mano il sysadmin che vuole tutti gli utenti con accesso via SSH ((Secure SHell)) che vi vagano per il sistema!
Vedo qualche mano alzata in fondo… ma probabilmente non sanno nemmeno di che si parla 😛
Andiamo al punto; noi vogliamo creare un sotto sistema in cui gli utenti si possono muovere senza inficiare la sicurezza del sistema vero.
Ingredienti:
- Debian Sarge 3.1 (meglio Debian ETCH)
- SSH
- Debootstrap
- libpam-chroot
Configurazione preliminare
Lanciamo aptitude update e aptitude upgrade che non fanno mai male.
Installiamo quindi quello che vi serve ovvero il daemon SSH e Debootstrap scrivendo su terminale dopo aver acquisito i permessi di root ((Amministratore di Sistema))
aptitude install ssh debootstrap libpam-chroot
guardatelo mente scarica installa e configura…
Al momento non ci interessa configurare SSH perch?? esulerebbe dallo scopo di questo HowTo, per cui passiamo alla pratica.
Creiamo una cartella che conterr?? il nostro pseudosistema, ad esempio digitando (sempre con privilegi di root) mkdir /chroot e procediamo con l’installazione di una delle versioni di Debian che pi?? ci sconfinfera tra woody, potato, sarge, etch, lenny e sid. Io personalmente opto per una etch quindi scrivo su terminale
debootstrap etch /chroot/ http://ftp.it.debian.org/debian/
ammirate…
Configurare la Chroot
Adesso dobbiamo configurare /etc/fstab del sistema “Padre” in modo da montare automaticamente all’avvio il filesystem /proc del sistema in /chroot per cui scriviamo sul terminale:
echo "proc-chroot /chroot/proc proc none 0 0" >> /etc/fstab
mount proc-chroot /chroot/proc -t proc
per la configurazione della rete dobbiamo copiare /etc/hosts nello pseudosistema digitando
cp /etc/hosts /chroot/etc/hosts
per verificare il corretto funzionamento del sistema ed esclamare “Ave Debian!” scrivete sul terminale:
chroot /chroot /bin/bash
come potrete constatare ?? impossibile risalire al sistema originale una volta entrati nella “gabbia” (vi baster?? scrivere exit per tornare alla vostra normale console di root).
Bene, abbiamo compiuto 3/4 del lavoro, adesso dobbiamo trovare un modo per ingabbiare gli accessi via SSH nella chroot appena creata e per fare ci?? editiamo((con vim, pico, xterm o tutto quello che volete)) /etc/pam.d/common-session ed aggiungiamo la riga
session required pam_chroot.so
Adesso PAM supporta chroot! Facile no? qualcuno direbbe: “a saperlo…”; ma procediamo editando /etc/security/chroot.conf in modo da avere qualcosa di simile al seguente:
# username chroot_dir
user1 /chroot
user2 /chroot
user3 /chroot
tu /
ovviamente sostituite “user1”, “user2” ecc con gli user che volete ingabbiare e “tu” con l’utente che non deve essere ingabbiato (almeno un utente non deve essere nella chroot).
Note:
Adesso ?? tutto, ma vi lascio un paio di indicazioni per la gestione:
- Quando create un utente da ingabbiare ricordatevi di creargli la home su
/chroot/homee non su/home - Quando create un utente aggiungete la riga relativa allo stesso utente presente in
/etc/passwdin/chroot/etc/passwd - non esister?? il file
/chroot/etc/shadowil che vuol dire che gli utenti della chroot non possono cambiare la loro password tramite il comandopasswdil che contribuisce per?? ad aumentare considerevolmente la sicurezza del sistema in quanto non gli sar?? possibile provare nemmeno per sbaglio attacchi di cracking sul file/etc/shadow(che peraltro non esiste ai suoi occhi).
Adesso gridiamo tutti insieme: “Evviva Debian!” 😛
Bell’howto 🙂 funziona tutto bene tranne una cosa: in questo modo gli utenti che non sono chrooted riescono ad accedere anche tramite SFTP (qualora ssh sia stato opportunamente configurato), mentre gli utenti chrooted vengono disconnessi appena tentato il login.
Come mai? Come si puo’ fare a dare accesso SFTP (nella jail) anche agli utenti chrooted?
Domanda intelligente e pertinente… rigiro la richiesta al nostro esperto 😉
@Gaglia: effettivamente c’ho provato pure io, per questo non ho parlato di SFTP nell’howto 😉 a dirla tutta non ho insistito più di tanto sull’argomento, però posso dirti che probabilmente è un problema di librerie…
art3k@titan-laptop:~$ ldd /usr/bin/sftp
libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8 (0x00002b8a101a0000)
libutil.so.1 => /lib/libutil.so.1 (0x00002b8a10521000)
libz.so.1 => /usr/lib/libz.so.1 (0x00002b8a10724000)
libnsl.so.1 => /lib/libnsl.so.1 (0x00002b8a1093b000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x00002b8a10b55000)
libresolv.so.2 => /lib/libresolv.so.2 (0x00002b8a10d89000)
libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0x00002b8a10f9e000)
libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x00002b8a111ca000)
libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x00002b8a1145e000)
libcom_err.so.2 => /lib/libcom_err.so.2 (0x00002b8a11683000)
libedit.so.2 => /usr/lib/libedit.so.2 (0x00002b8a11886000)
libncurses.so.5 => /lib/libncurses.so.5 (0x00002b8a11aa8000)
libc.so.6 => /lib/libc.so.6 (0x00002b8a11d04000)
libdl.so.2 => /lib/libdl.so.2 (0x00002b8a12060000)
libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0x00002b8a12264000)
libkeyutils.so.1 => /lib/libkeyutils.so.1 (0x00002b8a1246c000)
/lib64/ld-linux-x86-64.so.2 (0x00002b8a0ff82000)
in questo momento non ho tempo/hardware per provare, comunque queste sono le librerie richieste nella mia architettura… puoi provare a vedere se le dipendenze dentro la tua chroot sono soddisfate tramite il comando ldd…
Quindi teoricamente basta copiare le librerie necessarie? Caso mai quando ho tempo ci provo.
Se nel frattempo riesci a farlo funzionare fallo presente qui, questo metodo di chrootare gli utenti ssh e’ uno dei piu’ “eleganti” che ho trovato in rete finora, e’ un peccato che ci sia ‘sto noioso problema 🙂
Risolto!!! Erano proprio le librerie 😀
Basta cercare le librerie mancanti con “locate nomelibreria” e copiarle nella analoga posizione dentro la chroot. Quindi riavviare ssh.
perche non usare vserver?
@lastfeel: perchè debootstrap non virtualizza ma utilizza direttamente l’hardware della macchina saltando il passo della virtualizzazione utilizzando il sistema operativo in esecuzione come interfaccia, comunque grazie per lo spunto, metto in scaletta 😉
ti ricordo che vserver usa lo stesso hadware della macchina quindi se possiamo dire cosi vserver fa un chroot ma molti piu avanzato
apt-cache search vserver
ero giàandato a vedere la pagina ufficiale per le features perchè non lo conoscevo… 😉
mi funziona più o meno tutto.
quando l’utente ssh si collega ottiene questo messaggio:
Could not chdir to home directory /chroot/home/utente: No such file or directory
poi la shell non sembra funzionare “bene” in quanto non mette il $ e non trova i comandi… come mai?
Ho risolto facendo qualche modifica.
Praticamente la guida è ok ma bisogna fare queste cose:
1) io ho creato l’utente facendo adduser pippo –home /chroot/home/pippo
2) editare il file /etc/passwd togliendo /chroot/ (dovràquindi essere così: pippo:x:1001:1001:Pippo,,,:/home/pippo:/bin/bash che poi, come dice la guida, andràcopiato in /chroot/etc/passwd)
3) montare il dispositivo devpts:
a mano -> mount -t devpts devpts /chroot/dev/pts
fstab -> devpts /chroot/dev/pts devpts none 0 0
fatto ciò non ho più avuto problemi
Faccio presente che se dovete installare dei programmi nell’ambiente jailed dovete:
1) usare il vostro utente root
2) charoottarvi nell’ambiente jailed
3)installare
Correzione per l’automount del device devpts in fstab:
devpts /chroot/dev/pts devpts defaults 0 0