Sicurezza e GNU/Linux (parte 1): tipologie di attacco

Un viaggio a puntate sulle tematiche legate alla sicurezza, ai sistemi Unix e al software libero.

Le tipologie di attacco

Prima di parlare di come proteggere un software, è bene capire da cosa un software va protetto. Possiamo distinguere grossolanamente i tipi di attacco informatico in tre categorie:

1. Attacchi che sfruttano la “buona fede” dell’utente (social engineering);

2. Attacchi che sfruttano una falla (vulnerabilità) involontaria del software;

3. Attacchi che sfruttano un difetto di progettazione del software, di un protocollo di comunicazione o di un formato dati (by design);

4. Attacchi che sfruttano una configurazione debole (o persino del tutto errata) del software.

La prima tipologia parte dall’assunto che l’utente è l’anello più debole di un sistema informatico. Sebbene a prima vista possa sembrare una banalità, in realtà si tratta di una vera filosofia, il cui postulato (corretto, ma non scontato) è che l’utente fa parte del sistema informatico stesso. Oggi l’ingegneria sociale è senza dubbio la metodologia preferita negli attacchi informatici a causa della larghissima diffusione dei computer presso utenti del tutto privi di ogni nozione fondamentale sulla sicurezza informatica. Inoltre, dal punto di vista tecnico, sfruttare l’ingenuità dell’utente è decisamente più semplice di studiare in modo approfondito un software per scoprire i suoi punti deboli.

La seconda tipologia di attacco si basa invece proprio sulla scoperta di errori di programmazione all’interno del software.

La terza tipologia invece non si appoggia su un vero e proprio errore di programmazione, ma su un errore di progettazione. La differenza a volte è sottile, ma ha (in certi casi) delle conseguenze pratiche molto rilevanti. Mentre una falla dovuta ad un errore di programmazione può essere facilmente corretta nelle versioni successive del programma, una falla dovuta ad un difetto di progettazione può voler dire dover riscrivere parti molto consistenti del software, disattivare funzionalità o realizzarle in modo differente, perdendo a volte la compatibilità verso il passato. Nel casi peggiori, la falla non potrà mai venire corretta, ma eventualmente si dovranno tamponare le conseguenze. Si tratta quindi di un caso più grave rispetto alla tipologia 2.

Per capire la differenza, possiamo fare questo esempio: in una partita di calcio, l’allenatore decide di usare lo schema 4-4-2. La partita va bene ma ad un certo punto un giocatore dà un pugno in faccia ad un avversario in area: il giocatore viene espulso, la sua squadra subisce un rigore e perde il confronto. Questo non significa che lo schema 4-4-2 sia errato: semplicemente un fattore contingente ha determinato la sconfitta. Nelle partite successive l’allenatore eviterà di schierare il giocatore troppo violento per risolvere il “bug”.

Un altro allenatore invece decide di adottare lo schema (assurdo, si intende) 1-1-8. La squadra perde tutte le partite allo stesso modo. In questo secondo caso, c’è poco da cambiare giocatori o intimare loro di adottare il fair play: è lo schema ad essere totalmente sbagliato, chi deve andarsene è semmai l’allenatore.

Vulnerabilità relative ad una cattiva progettazione possono riguardare anche protocolli o formati di dati. In questo caso, qualsiasi implementazione software, dovendo rispettare le specifiche del protocollo o del formato di dati, può potenzialmente essere affetta dalla vulnerabilità.

Infine, è frequente in caso di attacchi rivolti a sistemi la cui configurazione in termini di sicurezza è debole o errata.  Il caso più comune è quello di assegnare permessi eccessivi a script o eseguibili binari, contravvenendo alla regola aurea dei “permessi minimi”.

Bisogna sottolineare che spesso gli attacchi vengono condotti con tecniche miste: ad esempio, sapendo che un browser ha una certa falla, si deve però indurre l’utente a visitare il sito appositamente creato per sfruttarla. Per farlo tornano quindi utili le tecniche di social engineering.

Nella prossima puntata vedremo cos’è concretamente una vulnerabilità, analizzando le più comuni tipologie.

I “costi” della “pirateria”

Mi chiamo Guybrush Threepwood e sono un temibile pirata!

In una e-mail che ho ricevuto poco fa, mi è stato segnalato un link interessante.

L’articolo parla di un comunicato della BSA, la “Business Software Alliance”, vale a dire la lobby di produttori di software proprietario, di cui Microsoft è magna pars. Tra le altre cose si legge:

La magia delle GTK+ 3

Non vi dico nulla, ma guardate bene questo video:

Qualcuno ha detto cloud computing?

 

EDIT.

Dai commenti mi sembra che molti non abbiano colto il potenziale di questa nuova tecnologia. La prova è stata effettuata sullo stesso computer ma la possibile applicazione è semplice da immaginare: mentre l’applicazione gira su un server, la sua interfaccia viene visualizzata nel browser dell’utente.

Una seconda possibilità è anche quella che l’applicazione venga in effetti scaricata in modo trasparente dal browser ed eseguita in locale, però tramite interfaccia web, cosa che comunque dà molte nuove potenzialità alle web application.

In entrambi i casi questo significa che qualsiasi applicazione GTK può diventare una applicazione web senza praticamente alcuno sforzo.

Unity contro GNOME Shell, prime impressioni

Sebbene abbia deciso di non usare nei prossimi 6 mesi né GNOME Shell, né Unity (salvo casi eccezionali) non rinuncio a provarle per farmi un’idea di questa che, volenti o nolenti, è l’evoluzione del desktop, in stile tablet: anche Mac OS X ha ora un suo launchpad, forse pure Windows andrà in una direzione simile.

GNOME Shell partiva svantaggiata, fino a qualche mese fa. Unity sembrava avere un progetto coerente, mentre GNOME Shell era preda di indecisioni su un po’ tutto. Oggi mi sembra che la situazione sia ribaltata. GNOME Shell è pressoché finita e chiara, mentre su Unity ancora imperversano vari mockup e soprattutto ad ogni aggiornamento vi sono cambiamenti sostanziali. Vediamo i pregi e i difetti:

GNOME Shell ha una maniera più intuitiva di lanciare le applicazioni (quelle senza icona sulla dock) rispetto a Unity. Basta spostarsi col mouse sull’angolo in alto a sinistra e compare una dashboard con le finestre attive (tipo expose). Cliccando su “applicazioni” compare l’elenco delle applicazioni che si possono lanciare, e a sinistra si può scegliere quale categoria (accessori, grafica, audio/video, ecc).

Il meccanismo di Unity è simile, ma per avere l’elenco delle applicazioni occorre clickare su una icona nella dock, che sta confusa in mezzo alle altre. Inoltre per restringere il campo ad una categoria, per ora c’è un menu a tendina che è molto meno pratico della soluzione di GNOME Shell. Su Unity, se si clicca in alto a sinistra, compare una dashboard con le attività presunte più comuni, di cui francamente non capisco l’utilità su un desktop dove di attività comuni ce ne sono a bizzeffe.

Nessuna delle due soluzioni, tuttavia, mi sembra pratica quando il vecchio menu di GNOME: più click, più spostamenti del mouse… però c’è da dire che avere le icone così grandi è comodo.

Unity invece vince sul lato dell’accesso ai file. Su GNOME Shell non c’è nulla che somigli al vecchio menu “risorse”: mi sono dovuto fare  un lanciatore di Nautilus nella dock per sopperire a questa incredibile carenza, con tutti gli svantaggi immaginabili. E’ una mancanza strana visto che invece c’era nella vecchia GNOME Shell prima del “refit”, insieme peraltro a file recenti.

Devo dire la verità: spero che qualche commento mi smentisca e che sia io a non aver visto dove si trova, perché in tutta onestà senza questo, l’uso del desktop diventa terribilmente stressante.

In effetti, a pensarci, né iOS, né Android hanno una gestione dei file, a meno di non installare un apposito filemanager. Ma questo modello app-centrico è totalmente anti ergonomico per un desktop, dove i file sono migliaia e vanno gestiti in quanto tali e non solo come creazioni delle app: anzi, al contrario, il desktop è file-centrico e le app sono solo uno degli strumenti che si usano sui file.

L’altro problema di GNOME Shell (e di Nautilus 3) è che non gestisce i file sul desktop e questo è un ulteriore problema.

Tuttavia va detto che anche su Unity non è che la gestione dell’accesso ai file sia così intuitiva: anche in questo caso solita icona grigia nella dock, in mezzo alle altre.

Altro vantaggio di Unity è la dock che interagirà con i programmi, come ora fa Docky, attraverso dbus. In tal modo sarà possibile controllar il programma dalla dock, cosa che GNOME Shell farà in parte solo con l’area notifiche in basso, ma in modo forse non altrettanto esteso.

GNOME Shell invece mi solletica riguardo la gestione delle finestre e dei work space, che è fatta davvero bene ed è facile da usare. E’ un piacere switchare da una applicazione all’altra e spostare le finestre tra i vari work space che vengono creati e distrutti a seconda delle esigenze, invece di essere fissi.

Certo, sarebbe meglio se la dock potesse essere sempre visibile, in modo da avere contezza delle applicazioni che girano in modo più immediato, tuttavia considerando che in genere con il desktop tradizionale si impazzisce dietro a mille finestre nella barra inferiore, minimizzandole e rimassimizzandole, forse questa soluzione che ti costringe ad usare i work space e permette una maggiore concentrazione sulle singole finestre, non è da scartare.

In quest’ottica, l’eliminazione del pulsante per minimizzare le finestre, ha senso (mentre per massimizzarle basta trascinarle vicino al pannello superiore o cliccare due volte sulla barra del titolo).

Fin qui le mie impressioni. Allora stato attuale, GNOME Shell sarebbe una alternativa da prendere in considerazione rispetto al desktop tradizionale, se non fosse per il problema dell’accesso macchinoso a cartelle e file che è un difetto di progetto che la rende pressoché inusabile.

Insomma, per ora non mi sento altro che dare una bocciatura ad entrambi i progetti, pur vedendone alcuni aspetti innovativi che potrebbero essere integrati in un desktop tradizionale, come par voglia fare Elementary Desktop.

Ultimo mese di supporto per i miei repository per Ubuntu Lucid

A partire da metà Aprile, i repository per Ubuntu Lucid non saranno più aggiornati e migrerò a Ubuntu Natty e/o Linux Mint 11.

Pertanto chi usa i miei repository (in particolare “lucid quasi rolling”) sappia che questo è l’ultimo mese di supporto.

Linux Mint sarà la mia prossima distro?

Sono molto, molto interessato a questa novità:

Lefebvre colpisce ancora, Linux Mint 11 userà un insolito Gnome 3

E voi che ne pensate?