glug: Debian

[Giovanni Chiola]

Marco d'Itri wrote:
> 
> ...
> L'articolo è molto approssimativo, traspare evidente l'impressione che
> l'autore riferisca notizie di terza mano (e/o non sappia l'inglese e il
> significato della parola "compromise" in questo contesto).

Concordo. Pero' sono rose e fiori rispetto ad altri ...
Se non altro le notizie di terza mano le hanno cercate
invece di inventarsele di sana pianta :)

> Il parlare di "cospirazioni" poi è semplicemente stupido, nemmeno
> ridicolo.

Non sarei cosi' drastico.
Di sicuro qualcuno ha lavorato un bel po'
per produrre l'exploit, dopo che il baco era stato identificato 
(che poi l'abbia fatto da solo o in compagnia, e
per quale fine, io non lo so ...)

>  >Il "buco" nel kernel 4.2.22 era stato individuato e patchato
>  >dagli sviluppatori del kernel prima che venisse fuori questo
>  >exploit, ma il problema e' che nessuno aveva avvertito gli
>  >utenti che lo stavano usando per applicazioni critiche.
> No! Il bug di questi kernel era stato individuato un mese fa ma nessuno
> ha ritenuto che fosse un possibile buco di sicurezza.

Appunto! Io ho detto la stessa cosa:
il buco nel kernel era stato individuato e corretto nel kernel 4.2.23
*prima* che venisse fuori questo exploit, che ha evidenziato
il fatto che potesse essere una falla di sicurezza.
Questo secondo me dimostra che non ci sono deficienze
nelle metodologie usate dagli sviluppatori del kernel.
L'unica cosa che non ha funzionato in modo perfetto, in questo
caso, e' stata la sottovalutazione del rischio di usare un
kernel nuovo per fornire dei servizi critici in rete.

> 
>  >Torniamo al solito discorso del giusto compromesso tra la necessita'
>  >di innovare e la necessita' di utilizzare software sufficientemente
>  >vecchio per essere sicuri che sia sufficientemente bug-free.
> Usare una versione vecchia non avrebbe aiutato, visto che questo bug
> esiste da anni.

In questo caso hai ragione. La soluzione sarebbe stata
l'upgrade immediato alla versione 4.2.23.

Pero' il mio commento era di tipo generale.
Cosa possiamo imparare da questa lezione?
Secondo me possiamo imparare che la sicurezza non va
sottovalutata nemmeno per il free software.
Indubbiamente i requisiti di sicurezza sono in contraddizione
con quelli di innovazione, estensione di funzionalita', ecc.
Tutte gli altri requisiti ti portano ad aggiungere codice
e complessita', mentre la sicurezza richiederebbe di
ridurre la quantita' di codice e la complessita'.
Puo' essere difficile conciliare le diverse esigenze in un unico
kernel, e puo' essere sensato prendere in considerazione
l'ipotesi di una versione "sicura" in cui le patch di
sicurezza arrivano subito mentre quelle di estensione
di funzionalita' arrivano dopo che sonon state adeguatamente
testate nella vanilla.

> 
>  >Forse dopo questa esperienza potrebbe aver senso mettere in piedi
>  >una distribuzione piu' stabile della vanilla da suggerire
>  >per l'utilizzazione nei server di rete.
> C'è già debian. :-)

Questo episodio sembrerebbe suggerire che non basta. :)

E il fatto che siano stati accomunati sistemi debian,
gentoo e il server di FSF suggerisce di prendere un approccio
piu' generico a livello di kernel.

Giovanni
--