Newsgroup: it.comp.os.linux.sys
Titolo: Client linux 'sicuro' per utenti smanettoni o meno...

Ciao a tutti.
Sto pensando ad una serie di client basati su debian ( o derivate da
debian ) con ambiente gnome sui quali ci si loggheranno ogni giorno
svariate persone, con svariati account e soprattutto con svariate
competenze informatiche e smanettonistiche...
Ho già cercato un po' in rete ma non ho ancora trovato una
soluzione...
come posso creare un client sicuro, nel senso che duri un pò di tempo
e non permetta anche ai più smanettoni di fare cose diverse da quanto
possa essere navigazione internet / open office / gimp ?
Per sfizio, visto che è un comando che mi ha sempre affascianato per i
suoi scopi ho dato un bel:
chmod o-x /bin/nohup
e sembra non aver dato effetti collaterali se non quello di negare ad
un utente standard la possibilità di appendere dei processi in
background...però mi chiedo quanti altri possano essere "pericolosi" o
"indispensabili"...
Avete qualche esperienza o linea guida su come creare un client sicuro
a prova di vandali?
Grazie.

 a prova di vandali?
Semplicemente non dando agli utenti la password di root, né la
possibilità di usare "sudo".
A quel punto al massimo un utente distrugge la propria $HOME, visto che
è l'unica area dove ha permessi di scrittura. Su tutto il resto del
filesystem ha solo permessi in lettura, e danni non ne fa.
Non ti mette al riparo da bachi nel kernel o buffer overflow che
permettano di passare comandi con privilegi di root, ma dire che ormai
questi siano rarità assolute (e prontamente corrette) non è blasfemo,
per cui non mi preoccuperei troppo di quello.
-- 
Massimo Bacilieri AKA Crononauta

 per cui non mi preoccuperei troppo di quello.
idem.

 Questo è abbastanza corretto.
Azz, tu sei tra i pochi al mondo a possedere in originale un temperino
per supposte, vero?! ;-)


 per supposte, vero?! ;-)
Lol!
non per le supposte, per i peni.
Ad ogni modo non era per fargli la punta semplicemente, era perchè sono 
alquanto incazzato su come butta l'argomento.

 writes:

Boh ad esempio potresti
- rendere accessibili solo gli eseguibili che possono eseguire
- montare la home con noexec
Certo che se poi possono usare la shell è dura limitare quello che
possono fare...
Ma la domanda piuttosto è, se questi sono in gamba magari credo che
saranno piuttosto scocciati di tutte queste limitazioni e useranno molto
poco volentieri uno strumento così castrato.

 possa essere navigazione internet / open office / gimp ?
Come ti hanno gia` detto utente senza privilegi e senza sudo.
Oltre a questo, io sposterei il client in una macchina virtuale su un 
server "nascosto" e sulla/sulle postazione client farei un'installazione 
minimale di X giusto per accedere in remoto alla macchina virtuale sul 
server.
Questo avrebbe l'enorme vantaggio di poter ripristinare l'ambiente 
iniziale nel giro di pochi minuti e senza dover reinstallare nulla.
-- 
Vincenzo

 a prova di vandali?
  La rete abbonda di tali guide.  Sii più specifico, che su un tema tanto
generico sono state scritte opere immense e monumentali (e anche qualche
bestialità).
  Ciao,
-- 
Alessandro Selli 
http://alessandro.route-add.net
AVVERTENZA: i messaggi inviati a "trappola" non mi arriveranno.
WARNING: messages sent to "trappola" will never reach me.
Chiave PGP/GPG: EC885A8B

 Grazie.
http://brainextender.blogspot.com/2009/01/look-down-ubuntus-gnome-
desktop.html

 a prova di vandali?
a prova di vandalo, puoi far lavorare gli utenti in un ambiente chroot, 
che potrari ripristinare facilmente dall'ambiente soprastante, con un 
bel untar di un file.
-- 
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
   printf $i }'; echo


In sostanza quel che mi preoccupa di più è che un utente abbandonando
la sua postazione possa lasciare in eseguzione download, portscanners,
spam bot e menate del genere...
Per il resto d'accordo che basta lasciare l' utente senza possibilita
di sudo e ovvio senza password di root...
Ma mettiamola sui termini di sicurezza in generale.
Ha senso che un utente possa accedere ad etc (ovviamente in lettura) e
possa carpire chessò qual'è il timeserver o altre informazioni sulla
configurazione della macchina utili magari a far dei danni o conoscere
come la rete è strutturata?
Come fare a rendere il tutto "sicuro" nei limiti del possibile? Dove
ci si deve fermare per non passare alla "paranoia"?
Purtroppo in ambiente linux sono questioni da me ancora un po'
lontane... e che forse mi preoccupano di più se orientate ad un client
"pubblico" piuttosto che ad un server...
PS: se può essere utile il progetto prevede l' eliminazione della home
utente ad ogni sua disconnessione, sono macchine per un uso temporaneo
dove se qualcuno deve salvare lo fa su un suo supporto di massa, e
dove vedrà passare all' incirca dalle 8.000 alle 11.000 persone + o
- :-|

 - :-|
Secondo me se devi permettere loro di lavorare non ha senso nemmeno
mettersi a fare un sistema troppo sicuro, se sono in gamba sarebbe
inutile.
Un approccio più pragmatico del tipo:
"potete fare questo questo e questo, se vi becchiamo a fare altro sono
ca*** amari"
mi sembra decisamente più maturo.
Al massimo ci piazzi qualcosa (proxy trasparenti, snort o altro) nella
rete per vedere cosa combinano, ma tutto qui...

 rete per vedere cosa combinano, ma tutto qui...
Purtroppo è un lavoro per un cliente che non seguiamo direttamente (le
macchine sono credo a noleggio, con assitenza e ripristino a carico
nostro).
Ora la realtà funziona con client Windows e GPO di restrizione dove
tutto sommato grossi problemi negli anni non ci sono mai stati.
Giriamola così, se voi doveste mettere su 100 client a 200 km di
distanza non remotamente amministrabili per svariate questioni di rete
a monte, come dormireste sonni tranquilli sapendo che i vostri client
per almeno 3 mesi non dovete toccarli e nessuno vi chiederà mai
spiegazioni per portscan, downlaod continui, etc...?

 possa essere navigazione internet / open office / gimp ?
li fai lavorare su macchine virtuali, al login prendi una snapshot, al
logout fai il revert alla snapshot.
Così saranno sempre immacolate ;^)
bye!

 
E se sono abbastanza "smanettone" mi posso compilare screen o tmux
con il linking statico e da li eseguire tutto ciò che voglio.
 Giovanni

 bye!
Mi sembra eccessivo e dubito che non esista una soluzione più
sicura...
Sto in sostanza cercando un hardening per mettermi un po' con le
spalle al coperto...

> bye!
Mi sembra decisamente la soluzioni migliore anche a me, qualsiasi altra
cosa non ti farà sicuramente dormire sonni tranquilli.
E comunque non hai risposto (o io non ho capito) alla domanda
fondamentale.
Chi e soprattutto cosa ci possono/devono fare con questi pc gli utenti?

 Chi e soprattutto cosa ci possono/devono fare con questi pc gli utenti?
Navigare - Openoffice - Eventulamente Gimp/Inkscape e assolutamente
non avere/dovere salvare nulla localmente.
Mi vorrete mica dire che gli omini IT di grosse multinazionali con
grossi parchi macchine (>1000 pc) migrate a linux adottino la
virtualizzazione su ogni singolo pc per risparmiarsi grattacapi degli
utenti smanettoni?
Sinceramente non voglio crederci, mentre credo ci possano essere
soluzioni di hardening che però mi sfuggono, ed è su questo che
porterei avanti la discussione...

 porterei avanti la discussione...
Allora come dicevo dargli l'accesso a SOLO quegli eseguibili, configura
http://www.novell.com/linux/security/apparmor/
o equivalenti e sei a posto (o quasi insoma), ma francamente non credo
che questa soluzione possa funzionare.
Ti chiederanno sicuramente di usare x,y,z e sarai sempre punto a capo,
con una sola macchina virtuale che si rigenera fai molto prima.

 con una sola macchina virtuale che si rigenera fai molto prima.
Diciamo che il servizio non sarà dato all' utente ma al cliente,
altrimenti immagina 9000 teste quante altrettante idee possano
avere... si definisce uno standard e quello rimarrà...
Macchina virtuale vuol però anche dire ogni tanto aggiornarla
altrimenti i pacchetti rimangono alla versione al momento dell'
installazione...
AppArmor ad esempio non lo conoscevo...e potrebbe essere interessante
approfondirlo.
Per quanto riguarda l' esplorabilità del filesystem, ho un modo per
far si che in user space l' utente sia all' oscuro delle
caratteristiche/configurazioni del sistema?

 server ma restrizioni locali.
Hai un'ampia gamma di scelte, in tal senso; SELinux è già presente
nel kernel ufficiale, ma esistono anche altre possibilità.

 anche se vengono lanciati come "nohup comando &" ?!
Al logout un bel
ps -U $USER | while read pid x; do kill -9 $pid ; done
E lascia pure che si compili screen o altre robe simili. (che poi il
compilatore è cosa buona e giusta non lasciarlo MAI installato su server o
macchine che devono essere un po' sicure).
-- 
Flavio Visentin
Ubuntu in Zulu significa "Non so usare Debian". (cit. CtRiX)

 nel kernel ufficiale, ma esistono anche altre possibilità.
SELinux applica restrizioni sulle chiamate di sistema che un'applicazione
può effettuare e impedisce agli utenti di fare danni. Purtroppo non entra
nel merito dell'applicazione, quindi è necessario affiancargli qualcos'altro.
Qualcosa che può tornar utile in questo caso può essere Pessulus
http://www.oneopensource.it/30/05/2007/pessulus-gnome-con-le-mani-legate/


 affiancargli qualcos'altro.
Scusa, ma non sono certo di aver capito cosa intendi quando affermi che
"non entra nel merito dell'applicazione".

 "non entra nel merito dell'applicazione".
Nel senso che SELinux limita l'*interazione* dell'applicazione con il
sistema operativo, ma l'applicazione in sè non è affare di cui SELinux abbia
concezione. Per esempio con SELinux puoi impedire all'applicazione di aprire
connessioni di rete, puoi impedirle di vedere porzioni di disco, puoi
limitarne i diritti, ma non puoi 
p.es
. disabilitare determinati menu o
impedire che possa essere ridotta a icona, ecc.ecc.
Nel raffronto con le GPO di Windows quindi SELinux rappresenta solo una
parte del sistema di gestione e di enforcing delle policy. La parte
rimanente invece deve essere gestita con qualcosa che abbia coscienza delle
applicazioni ed interagisca con esse; per l'ambiente Gnome questo qualcosa è
Pessulus (c'è anche un corrispondente per KDE).


 disco, puoi limitarne i diritti
Beh, pensavo che, per quanto esposto dall'OP potesse 
bastare, sinceramente.:-P

 
S.

 non avere/dovere salvare nulla localmente.
  La soluzione classica (ma un po' antiquata) e di avere la home directory
degli utenti su un filesystem montato in sola lettura.  Magari in un
ambiente chroot, con una shell ristretta per tutti gli utenti (ad es.
/bin/rbash).  Il prezzo di un ambiente chroot+rbash è un maggiore peso
amministrativo in fase di impostazione e di aggiornamento del sistema: si
deve predisporre l'ambiente chroot con tutti gli applicativi e librerie nel
posto giusto, più una directory unica nel PATH degli utenti con i soli
applicativi che questi devono poter utilizzare (che deve includere anche
tutte le utility dell'ambiente grafico) e, dentro questo ambiente, montare
la home in sola lettura.  Probabilmente la soluzione proposta da Stefano
Zamboni, di usare l'infrastruttura del Linux Terminal Server Project, ti
semplificherebbe molto il lavoro.



Quoto il tuo post, ma ringrazio tutti quanti.
Volendo ottenere nello specifico:
-Nascondere da occhi indiscreti il contenuto di /etc
-Disabilitare o limitare fortemente l' uso delle console.
Cosa potrei fare?
Al momento della creazione dell' utente la shell /bin/false mi pare mi
impedisca di utilizzare qualsiasi ambiente/applicazione grafica...

 impedisca di utilizzare qualsiasi ambiente/applicazione grafica...
  Si, anche se il metodo canonico è di disabilitargli la password con il
comando passwd -l utente.  In questo modo è impossibile capire se, in un
attacco a forza bruta, si è indovinata la password giusta di un account
che ha (momentaneamente) una shell non valida.  Per gli utenti di
sistema che non useranno mai una shell di login si può mettere
/bin/false, ma c'è il file /sbin/nologin fatto apposta per questi casi.
