Attenzione! Questa traduzione è ormai datata, perciò dai un'occhiata anche alla nuova pagina originale.

FAQ Debian sulla sicurezza

Riceviamo forse troppo spesso le seguenti domande, quindi abbiamo riassunto qui le relative risposte.

  1. La firma degli annunci non è correttamente verificata!
  2. Come è gestita la sicurezza in Debian?
  3. Perché perdete tempo con una vecchia versione di quel pacchetto?
  4. Qual è la procedura perché un nuovo pacchetto appaia in security.debian.org?
  5. Che significa local (remote)?
  6. La versione del pacchetto indica che io sto utilizzando una versione vulnerabile!
  7. Ho ricevuto un avviso, ma sembra mancare il pacchetto per una certa architettura.
  8. Come è gestita la sicurezza per unstable?
  9. Come è gestita la sicurezza per testing?
  10. Come è gestita la sicurezza per contrib e non-free?
  11. L'avviso dice che la soluzione in unstable è nella versione 1.2.3-1, ma unstable ha la 1.2.5-1, cosa succede?
  12. Perché non ci sono mirror ufficiali di security.debian.org?
  13. Ho visto DSA 100 e DSA 102. Dov'è il DSA 101?
  14. Come posso contattare il team sicurezza?
  15. Suppongo di aver trovato un problema di sicurezza, cosa dovrei fare?
  16. Cosa dovrei fare con un problema di sicurezza in uno dei miei pacchetti?
  17. Ho provato a scaricare un pacchetto elencato in uno dei "Security Advisor" ma ho avuto un errore "file not found".
  18. Ho trovato la soluzione ad un problema, posso caricarla su security.debian.org direttamente?
  19. Ho trovato la soluzione ad un problema, posso caricarlo invece su "proposed-updates"?
  20. Sono sicurissimo che il mio pacchetto va bene, posso caricarlo?
  21. Come posso aiutare?
  22. Qual è lo scopo di proposed-updates?
  23. Come è composto il team della sicurezza?
  24. Per quanto tempo sono assicurati gli aggiornamenti di sicurezza?
  25. Come si può controllare che i pacchetti siano integri?
  26. Cosa fare se un altro pacchetto non funziona dopo un aggiornamento di sicurezza?

D: La firma degli annunci non è correttamente verificata!

R: Molto probabilmente è un problema dal vostro lato. La lista debian-security-announce ha un filtro che accetta solo messaggi con una firma corretta proveniente da un iscritto al team della sicurezza.

È probabile che uno dei programmi utilizzati per la posta abbia cambiato leggermente il messaggio e quindi la firma. Verificate che il vostro programma non tocchi la codifica MIME del messaggio o cambi tab e spazi.

Problemi si sono verificati con fetchmail (con l'opzione mimedecode abilitata), formail (solo la versione di procmail 3.14.) ed evolution.

D: Come è gestita la sicurezza in Debian?

R: Una volta che il team riceve una notifica di un incidente, uno o più membri prendono in carico la segnalazione e valutano l'impatto sulla distribuzione "stable" di Debian (vale a dire cercano di capire se Debian sia o meno vulnerabile). Se il nostro sistema è vulnerabile allora lavoriamo ad una soluzione che lo risolva. Se non si è attivato da solo allora il manutentore del pacchetto viene contattato. Alla fine la soluzione viene verificata e creato un nuovo pacchetto che viene poi compilato su tutte le architetture stabili e poi caricato sul server. Dopo che tutto ciò è stato fatto, viene pubblicato l'annuncio.

D: Perché perdete tempo con una vecchia versione di quel pacchetto?

La più importante regola quando viene preparato un nuovo pacchetto che risolve un problema di sicurezza è di fare il minimo possibile di cambiamenti. I nostri utenti e gli sviluppatori fanno affidamento su un corretto funzionamento di una versione appena essa viene rilasciata, ed ogni eventuale cambiamento potrebbe creare problemi al sistema di qualcuno. Ciò è vero in particolar modo nel caso di librerie: siate sicuri che non cambieremo mai le Application Program Interface (API) o le Application Binary Interface (ABI), neanche con piccole variazioni.

Questo significa che adottare una nuova versione a monte [NdT: in inglese upstream version: la versione originale (generalmente mantenuta dagli autori) usata per la creazione del pacchetto Debian] non è una buona soluzione, invece andrebbero riportati verso la vecchia i cambiamenti significativi. Di solito i manutentori della versione a monte sono ben disposti ad aiutare, altrimenti il team sicurezza Debian potrebbe farlo al loro posto.

In alcuni casi non è possibile creare una soluzione, per esempio quando grandi quantità di codice sorgente dovrebbero essere modificate o riscritte. In tal caso potrebbe essere necessario migrare verso una nuova versione, ma ciò deve essere preventivamente concordato con il team della sicurezza.

D: Qual è la procedura perché un nuovo pacchetto appaia in security.debian.org?

R: Tutti i problemi di sicurezza della distribuzione "stable" fanno allertare security.debian.org. Qualsiasi altro problema non ha lo stesso effetto. La dimensione del problema non è realmente importante qui. Normalmente il team della sicurezza preparerà i pacchetti assieme al manutentore originale. Trovato qualcuno (affidabile) che segua il problema, lo comprenda, ricompili tutti i pacchetti necessari e li spedisca al team della sicurezza, allora anche le più banali soluzioni a problemi di sicurezza saranno pubblicate su security.debian.org. Vedere più avanti.

Gli aggiornamenti per la sicurezza hanno un unico scopo: fornire una soluzione per una vulnerabilità nella sicurezza. Non sono un metodo per insinuare cambiamenti nella versione "stable" senza passare attraverso le normali procedure.

D: Che significa local (remote)?

R: Alcuni avvisi riguardano vulnerabilità che non possono essere identificate con il classico schema di exploit locale e remoto. Alcune vulnerabilità non possono essere sfruttate da remoto, in altre parole non corrispondono ad un demone in ascolto su una porta di rete. Nel caso possano essere sfruttate da file speciali forniti eventualmente via rete anche se il servizio vulnerabile non è connesso permanentemente in rete, lo descriveremo come local (remote).

Tali vulnerabilità sono a metà strada tra le locali e le remote e spesso coprono archivi che possono essere forniti attraverso la rete, come allegati di posta o da una pagina di download.

D: La versione del pacchetto indica che io sto utilizzando una versione vulnerabile!

R: Invece di aggiornare il programma all'ultima versione preferiamo riportare solo le modifiche legate al problema sulla vecchia versione. La ragione per la quale facciamo ciò è che vogliamo fare in modo che la soluzione abbia il minore impatto possibile sul resto della distribuzione. Si può verificare se si sta utilizzando una versione sicura controllando il changelog del pacchetto o confrontando il numero completo di versione con quello indicato nel Debian Security Advisory.

D: Ho ricevuto un avviso, ma sembra mancare il pacchetto per una certa architettura.

R: In genere il team sicurezza rilascia un avviso con i pacchetti aggiornati per tutte le architetture supportate da Debian. Tuttavia, alcune di esse sono più lente di altre e può accadere che le compilazioni siano per la maggior parte pronte mentre manchino per altre; tali architetture rappresentano una piccola parte della nostra utenza. A seconda dell'urgenza del problema, si può decidere di pubblicare l'annuncio immediatamente. I pacchetti mancanti saranno aggiunti all'archivio non appena disponibili, ma non verrà pubblicato alcun ulteriore avviso in proposito. Naturalmente non rilasceremo mai un avviso dove non siano presenti i pacchetti per i386 o amd64.

D: Come è gestita la sicurezza per unstable?

R: La risposta breve è: non lo è. Unstable cambia troppo velocemente e il team della sicurezza non ha risorse sufficienti per gestire correttamente la cosa. Se si vuole un server sicuro (e stabile) invitiamo caldamente ad utilizzare la versione stable.

D: Come è gestita la sicurezza per testing?

R: Se si desidera avere un server sicuro (e stabile) invitiamo caldamente ad utilizzare la versione stable. Comunque c'è un supporto di sicurezza per testing: il Debian testing security team gestisce i problemi per testing. Essi si assicurano che i pacchetti che risolvono problemi di sicurezza passino in testing per la via ordinaria della migrazione da unstable (con una quarantena ridotta) oppure, se la via ordinaria richiedesse troppo tempo, li rendono disponibili mediante l'infrastruttura http://security.debian.org. Per utilizzarli si aggiunga la seguente riga in /etc/apt/sources.list:

deb http://security.debian.org <codename>/updates main

e si esegua apt-get update && apt-get upgrade come al solito.

Si noti che non vi è garanzia che tutti i bachi di sicurezza conosciuti siano risolti in testing! Qualche pacchetto aggiornato potrebbe essere in attesa per la transizione a testing. Ulteriori informazioni sull'infrastruttura di sicurezza per testing possono essere trovate a http://secure-testing-master.debian.net/.

D: Come è gestita la sicurezza per contrib e non-free?

R: La risposta breve è: non lo è. Contrib e non-free non sono parti ufficiali della distribuzione Debian e per questo non sono supportate dal team sicurezza. Alcuni pacchetti non-free sono distribuiti senza sorgenti o senza una licenza che permetta la distribuzione di versioni modificate. E in quei casi sono completamente impossibili i fix di sicurezza. Se c'è la possibilità di risolvere il problema e il manutentore del pacchetto o qualcun altro fornisce un pacchetto correttamente aggiornato, allora di solito il team sicurezza lo processa e rilascia un advisory.

D: L'avviso dice che la soluzione in unstable è nella versione 1.2.3-1, ma unstable ha la 1.2.5-1, cosa succede?

R: Cerchiamo di indicare la prima versione in unstable che risolve il problema. Qualche volta il maintainer ha nel frattempo caricato nuove versioni. Si confronti la versione in unstable con quella da noi indicata. Se è la stessa o superiore si dovrebbe essere al sicuro dalla vulnerabilità.

D: Perché non ci sono mirror ufficiali di security.debian.org?

R: Ci sono. Esistono alcuni mirror ufficiali, realizzati mediante alias DNS. Lo scopo di security.debian.org è di rendere disponibili gli aggiornamenti nella maniera più semplice e rapida possibile.

Incoraggiare l'uso di mirror non ufficiali potrebbe aggiungere un'inutile maggiore complessità che potrebbe causare frustrazione se i mirror non fossero tenuti aggiornati.

D: Ho visto DSA 100 e DSA 102. Dov'è il DSA 101?

R: Alcuni venditori (la maggior parte di GNU/Linux, ma anche di derivati BSD) coordinano a volte i "Security Advisor" stabilendo delle date affinché tutti i venditori possano rilasciare l'annuncio contemporaneamente. Questo è stato fatto per non discriminare i venditori che richiedono più tempo (in altre parole quando il venditore necessita di far passare il pacchetto attraverso lunghi test di QA o deve supportare diverse architetture o distribuzioni binarie). Anche il nostro team prepara gli annunci in anticipo. Ogni tanto altri problemi legati alla sicurezza sono stati gestiti prima che uscisse l'annuncio ufficiale (e quindi, che fosse assegnato il numero), per questo motivo capita che i numeri non siano tutti consecutivi.

D: Come posso contattare il team sicurezza?

R: Informazioni inerenti alla sicurezza possono essere inviate a security@debian.org o a team@security.debian.org, lette ambedue dai membri del team sicurezza.

Se si è il manutentore di un pacchetto e si desidera contattarci riguardo un problema, si prega di inviare un ticket al nostro Request Tracker. Se però si preferisce utilizzare la crittografia PGP è meglio la consueta posta elettronica.

Volendo l'e-mail può essere crittata con la chiave Debian Security Contact (key ID 0x90F8EEC5). Per le chiavi PGP/GPG personali di membri del team members, si usi il keyserver keyring.debian.org .

D: Suppongo di aver trovato un problema di sicurezza, cosa dovrei fare?

R: Se si scopre qualche problema di sicurezza, sia in un proprio pacchetto che in quello di altre persone, contattare il team sicurezza. Se il team sicurezza Debian conferma la vulnerabilità e se esiste la possibilità che anche altri venditori siano vulnerabili, il team di solito contatta anche gli altri venditori. Se la vulnerabilità non è ancora pubblica il team cerca di coordinare i "security advisory" con gli altri venditori, per mantenere le maggiori distribuzioni sincronizzate.

Se la vulnerabilità è già pubblicamente nota, assicurarsi di aprire un bug report nel Debian BTS, con il tag security.

Se si è un manutentore Debian, leggere sotto.

D: Cosa dovrei fare con un problema di sicurezza in uno dei miei pacchetti?

R: Se si scopre un problema di sicurezza in un pacchetto, sia proprio che di altre persone, contattare il team sicurezza, preferibilmente aprendo un ticket sul Request Tracker, o tramite posta elettronica all'indirizzo team@security.debian.org. I membri del team tengono traccia dei problemi di sicurezza irrisolti, possono aiutare i manutentori con problemi di sicurezza o risolverli essi stessi, sono responsabili dell'emissione dei "security advisory" e curano security.debian.org.

La Developer's Reference contiene le istruzioni complete su cosa fare.

È particolarmente importante che non si carichi verso qualsiasi distribuzione che non sia "unstable" senza un accordo preventivo con il team sicurezza, perché bypassarlo causerebbe confusione e maggior lavoro.

D: Ho provato a scaricare un pacchetto elencato in uno dei "Security Advisor" ma ho avuto un errore "file not found".

R: Tutte le volte che un "bugfix" più nuovo sostituisce un pacchetto più vecchio su security.debian.org, ci sono alte probabilità che il vecchio pacchetto sia stato rimosso quando quello nuovo è stato installato. Da quel momento si avrà l'errore "file not found". Non vogliamo distribuire pacchetti con bug di sicurezza conosciuti più a lungo di quanto sia assolutamente necessario.

Bisogna usare i pacchetti elencati negli ultimi "security advisor", che sono distribuiti tramite la mailing list debian-security-announce. La cosa migliore è semplicemente eseguire apt-get update prima aggiornare il pacchetto.

D: Ho trovato la soluzione ad un problema, posso caricarla su security.debian.org direttamente?

R: No, non è possibile. L'archivio a security.debian.org è mantenuto dal team sicurezza, che deve approvare tutti i pacchetti. È necessario inviare le "patch" o il codice sorgente modificato al team sicurezza, tramite il Request Tracker o l'indirizzo team@security.debian.org. Saranno controllati dal team sicurezza ed eventualmente caricati, con o senza modifiche.

Se non si è pratici di aggiornamenti per la sicurezza e non si è sicuri al 100% che il pacchetto sia integro, usare questo metodo e non caricare nella directory incoming. Il team sicurezza ha poche possibilità di gestire pacchetti difettosi, specialmente se non hanno un numero di versione corretto. Attualmente i pacchetti non possono essere rifiutati ed il funzionamento di buildd diventerebbe problematico. Per favore si usi la posta elettronica e si aiuti non aggiungendo complicazioni al lavoro del team sicurezza.

La Developer's Reference contiene le istruzioni complete su cosa fare.

D: Ho trovato la soluzione ad un problema, posso caricarlo invece su "proposed-updates"?

R: Dal punto di vista tecnico, sì. Comunque, non si dovrebbe farlo, visto che ciò interferisce pesantemente con il lavoro del team sicurezza. I pacchetti sono copiati da security.debian.org nella directory "proposed-updates" automaticamente. Se un pacchetto con un numero di versione uguale o superiore è già installato nell'archivio, l'aggiornamento di sicurezza sarà rifiutato dal sistema di archiviazione. In tal caso, la distribuzione "stable" sarà preparata senza l'aggiornamento di sicurezza di quel pacchetto, a meno che i pacchetti sbagliati nella directory proposed-updates non siano stati rifiutati. Si contatti invece il team sicurezza includendo tutti i dettagli sulla vulnerabilità ed allegando i file sorgente (cioè i file diff.gz e dsc) all'e-mail.

La Developer's Reference contiene le istruzioni complete su cosa fare.

D: Sono sicurissimo che il mio pacchetto va bene, posso caricarlo?

R: Se si è veramente sicuri che il pacchetto non danneggi nulla, che sia la versione sia giusta (cioè maggiore della versione in "stable" e minore della versione in "testing"/"unstable"), che non sia cambiato il funzionamento del pacchetto nonostante sia stato corretto il problema di sicurezza, che sia stato compilato per la corretta distribuzione (che è oldstable-security o stable-security), che il pacchetto contenga il sorgente originale se è nuovo in security.debian.org, che la "patch" sia valida per la versione più recente e che essa riguardi solo il relativo problema di sicurezza (controllare con interdiff -z i file .diff.gz), che la "patch" sia stata controllata almeno tre volte e che debdiff non mostri alcun cambiamento, allora è possibile caricare i file nella directory incoming ftp://security-master.debian.org/pub/SecurityUploadQueue direttamente a security.debian.org. Si prega di inviare anche un avviso con tutti i dettagli e i link a team@security.debian.org.

D: Come posso aiutare?

R: Controllando bene ogni problema prima di inviarlo a security@debian.org. Se si è capaci di fornire delle "patch" allora questo accelererebbe il processo. Non limitarsi ad inoltrare messaggi su come verificare la presenza del problema perché noi li riceviamo già; cercare invece di aggiungere tutte le informazioni possibili.

Un buon modo per iniziare con il security work è di aiutare con il Debian Security Tracker (istruzioni).

D: Qual è lo scopo di proposed-updates?

R: Questa directory contiene i pacchetti che sono candidati ad entrare nella prossima distribuzione "stable" di Debian. Ogni volta che un manutentore carica un pacchetto per la distribuzione "stable" allora il pacchetto viene memorizzato nella stessa directory. Poiché "stable" è una versione che è ritenuta stabile allora non viene aggiornata automaticamente. Il team della sicurezza invia alla versione "stable" gli aggiornamenti dei pacchetti menzionati negli annunci, ma questi vengono inseriti nella directory proposed-updates. Ogni tanto il manager della distribuzione stabile controlla la lista dei pacchetti in proposed-updates e vaglia se un pacchetto sia pronto o meno per "stable". Il tutto viene poi inserito nella revisione successiva di "stable", come 2.2r3 o 2.2r4. I pacchetti non adatti saranno probabilmente rifiutati e cancellati da proposed-updates.

Si noti che i pacchetti caricati dai manutentori (e non dal team sicurezza) nella directory proposed-updates/ non sono supportati dal team sicurezza.

D: Come è composto il team della sicurezza?

R: Il team sicurezza Debian è composto da diversi membri e segretari. È lo stesso team sicurezza che invita le persone ad unirsi ad esso.

D: Per quanto tempo sono assicurati gli aggiornamenti di sicurezza?

R: Il team sicurezza cerca di supportare una distribuzione stable per circa un anno dal rilascio della successiva distribuzione stable, a meno che un'ulteriore distribuzione stable sia rilasciata nell'anno stesso. Non è possibile supportare tre distribuzioni; supportarne due contemporaneamente è già abbastanza difficile.

D: Come si può controllare che i pacchetti siano integri?

R: Controllando la firma del file Release mediante la chiave pubblica usata per l'archivio. Il file Release contiene le checksums dei file Packages e Sources, che a loro volta contengono le checksums dei pacchetti binari e sorgenti. Istruzioni dettagliate su come controllare l'integrità dei pacchetti possono essere trovate nel Debian Securing Manual.

D: Cosa fare se un altro pacchetto non funziona dopo un aggiornamento di sicurezza?

R: Prima di tutto si dovrebbe capire perché il pacchetto non funziona e come il malfunzionamento è correlato con l'aggiornamento di sicurezza, poi si contatti il team sicurezza se il malfunzionamento è serio o lo stable release manager se non lo è. Stiamo discutendo circa i pacchetti che non funzionano dopo l'aggiornamento di sicurezza di un altro pacchetto. Se non si può capire cosa non va ma si ha una correzione, si contatti il team sicurezza anche se si potrebbe essere ridiretti allo stable release manager.