Nota: L'originale è più recente di questa traduzione.
Riceviamo forse troppo spesso le seguenti domande, quindi abbiamo riassunto qui le relative risposte.
local (remote)?
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.
Molto probabilmente uno dei programmi che utilizzate per la posta ha 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 viene 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. Leggere anche dopo.
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. Se esse possono essere
sfruttate da file speciali che potrebbere essere forniti via rete
anche se il servizio vulnerabile non sia connesso in permanenza con la
rete, in tal caso lo descriveremo come local (remote)
.
Such vulnerabilities are somewhat between local and remote vulnerabilities and often cover archives that could be provided through the network, e.g. as mail attachment or from a download page.
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: 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 limitato 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 testing/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 e alcuni bachi potrebbero non essere pubblicamente conosciuti e perciò il Testing security team non ne saprebbe nulla. 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.
R: Cerchiamo di indicare la prima versione in unstable che risolve il problema. Qualchevolta il maintainer ha nel frattemp 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'inutle 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 possono 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.
Volendo l'e-mail può essere crittata con la chiave Debian Security Contact (key ID 0x68B64E0D). 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. Si può raggiungerlo 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.
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 lanciare
apt-get update prima di eseguire l'aggiornamento del 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 all'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, si. 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. Per favore 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 . Per favore inviare anche un avviso con tutti i dettagli
ad i link a team@security.debian.org .
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 (instruzioni).
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 a 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 l'MD5 checksums dei file Packages e Sources, che a loro volta contengono gli MD5 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.