[ImoLUG] Titolo della conferenza a Faenza

[Daniele Tampieri]

Buongiorno Marco,
      scusa se ti rispondo con un notevole ritardo: la mia domanda
era intesa a verificare la possibilità del controllo dell'accesso a certe
risorse (tra i quali i file, intesi nella maniera ampia 'Unix/Linux Docet'
sia come file dati che come eseguibili, che come risorse del sistema),
e tu hai risposto in maniera piuttosto completa (così credo): occorre
valutare i costi di una operazione di questo tipo, e forse anche gli
obiettivi di una operazione simile. La motivazione alla base della mia
domanda era che è molto più efficace fornire strumenti di lavoro che
siano ottimi ed efficienti nel permetterti di eseguire i tuoi compiti ma
completamente inutili come passatempo, piuttosto che minacciare
ritorsioni basate sull'analisi dei log. Un'ultima cosa: hai nulla in contrario
se aggiungo questa conversazione come follow-up alla pagina wiki del
LUG con il testo e il video della tua conferenza?

Ciao, Daniele



Il 30 ottobre 2011 18:44, Marco Pizzoli <marco.pizzoli@gmail.com> ha scritto:
> 2011/10/30 Daniele Tampieri <daniele.tampieri@ieee.org>
>>
>> Ciao Marco,
>>      mi dispiace di essere dovuto scappare prima della fine
>> della tua conferenza e della discussione finale. Ho però una
>> domanda che vorrei farti sulle policy di SELinux: visto che
>> supporta varie policy, sarebbe possibile, almeno in linea di
>> principio, un azienda possa decidere di installare il pacchetto
>> su tutte le sue macchine Linux per avere un controllo fine
>> sull'impiego delle macchine in ambito lavorativo, dettagliando
>> una propria policy?
>>
>> Daniele Tampieri
>
> Ciao,
> non me la sono presa, tranquillo :-)
>
> La tua domanda potrebbe essere ambigua. Provo a buttare giu' diverse
> considerazioni e poi tu mi dici esattamente cos'e' che ti interessa
> principalmente.
>
> "Avere il controllo" puo' intendersi come auditing oppure (nella semantica
> anglosassone) anche il comandare.
>
> Se tu intendi fare auditing, SELinux non e' lo strumento su cui puntare,
> quanto piuttosto "auditd". Combinato con audisp ti consente di inviare tutti
> i log di tuo interesse a syslog e poi ci fai quello che vuoi.
> L'audit daemon ti consente di definire un "listener" su un determinato
> evento che avviene (a livello kernel) su un determinato oggetto:
> es. una "read" su un determinato file.
>
> SELinux si occupa di controllo accessi. Prende *solo* decisioni su se un
> determinato accesso (es. la lettura di un file) puo' essere compiuto oppure
> no ed ha il vantaggio di riuscire ad agire ad un livello molto capillare,
> oltre che ad andare ad agire anche su quanto gia' in essere: es. nel mondo
> DAC una volta che hai fatto una open() e ti viene ritornato un descrittore,
> te ne freghi di quello che avviene sui permessi del file (compreso se il
> file viene rimosso!). In SELinux invece il controllo accessi avviene per
> ogni singola read() e di conseguenza puoi interrompere qualcosa di attivo in
> quel momento.
>
> La scelta di adottare SELinux potrebbe essere un salto troppo grosso
> (investimento di tempo/soldi, complessita' dell'ambiente rispetto alla
> formazione degli operatori/lavoratori, ecc...) per lo scopo che ci si
> prefigge, quindi occorre pensare bene a (fino a) cosa si vuole ottenere.
> Personalmente vedo SELinux come uno strumento utile per arrivare la' dove
> altri strumenti semplicemente non possono arrivare, ma a condizione che
> siano gia' hardenizzati gli altri livelli prima di arrivare a SELinux: il
> concetto della defense-in-depth.
> Una condizione importante, a mio avviso, e' che il sistema (di persone) nel
> quale viene eventualmente inserito SELinux sia "pronto" per accogliere uno
> strumento cosi'... Il piu' grande buco di sicurezza e' quello che sta tra il
> computer e la sedia :-)
> Scherzi a parte, il rischio che uno poi decida (faccia pressioni
> psicologiche) per disattivarlo al boot e' da tenere in considerazione...
>
> Venendo alla tua richiesta specifica. A livello teorico ha sempre senso
> mettere in campo tutte le attivita' tali da ridurre la posibilita' di una
> violazione di accessi alle risorse. L'investimento in un SELinux che usa una
> policy personalizzata potrebbe non essere cosi' "a costo zero"... quindi
> prima di tutto occorre farsi 2 domande:
> - l'analisi del rischio come valuta il danno provocato da uso illecito di
> strumenti informatici?
> - il modo di lavorare all'interno della mia azienda (l'insieme dei processi
> aziendali) e' riconducibile ad un modello dal quale ricavare le regole
> SELinux da inserire nella mia policy?
>
> Ho buttato diverse considerazioni. Dimmi te se ho risposto alla tua domanda
> e, se no, dammi qualche elemento in piu' :-)
> Ciao
>    Marco
>
>
>