L'aspetto sicurezza nella distribuzione stable è trattato da un gruppo di persone - il Security Team, composto da cinque membri e due segretari - che seguono i problemi di vulnerabilità dell'ambiente software, partecipando a forum come bugtraq o vuln-dev e stabiliscono se la distribuzione stable ne sia interessata.
Quando i problemi non sono specifici solo di Debian, il Security Team è anche
un punto di riferimento per quei problemi che potrebbero interessare più
distributori e la cui disamina sia coordinata da sviluppatori di versioni
ancora in fase progettuale o da organizzazioni come il CERT
. Potete contattare il Security Team
tramite:
team@security.debian.org
,
letta solo dai membri del team stesso;
security@debian.org
letta
da tutti gli sviluppatori di Debian, oltre che dai membri del team. Le lettere
spedite a questo indirizzo non sono pubblicate in Internet, non essendo questa
una mailing list pubblica.
Le informazioni sensibili vanno spedite al primo indirizzo e in alcuni casi, sottoposte a cifratura con la chiave Debian per il contatto sicuro (ID della chiave con ID 363CCD95).
Una volta che la segnalazione di un possibile problema arriva al Security Team,
questo cercherà di scoprire se la distribuzione stable ne sia
interessata e in tal caso, verrà elaborata una correzione per il codice
sorgente di base. Questa correzione, a volte, include la rielaborazione di
qualche adattamento progettuale (creato, di solito, per versioni successive a
quella attualmente in distribuzione). Dopo un controllo sulla correzione,
nuovi pacchetti vengono preparati e pubblicati sul sito security.debian.org
, in modo da essere
disponibili tramite apt
(vedete Eseguire un security update, Sezione
4.2). Allo stesso tempo, viene pubblicato sul sito e spedito alle mailing
list pubbliche (comprese bugtraq e debian-security-announce
)
un DSA (Debian Security Advisory - avviso sulla sicurezza in Debian).
Potete trovare altre "domande frequenti" nella Domande sul Security Team di Debian, Sezione 11.3.
Gli avvisi di sicurezza Debian (Debian Security Advisories) vengono emessi ogni volta che si scopre una vulnerabilità di sicurezza relativa ad un pacchetto Debian. Questi avvisi, firmati da un membro del Security Team, includono informazioni sulla versione colpita ed indicano dove scaricare gli aggiornamenti ed il loro MD5sums. Le informazioni sono:
Gli avvisi di sicurezza (DSA) sono pubblicati sia sulla pagina principale del sito Debian
che nelle
pagine dedicate alla sicurezza
in Debian
. Di solito questo non accade sinché il sito non viene
aggiornato (una volta al giorno), quindi potrebbero non essere presenti
immediatamente; il canale preferenziale è la mailing list
debian-security-announce.
Gli utenti interessati possono comunque (e questo viene fatto in alcuni portali
relativi a Debian) utilizzare il canale RDF per scaricare automaticamente gli
avvisi di sicurezza sul loro desktop. Alcune applicazioni, come
Evolution
(un client e-mail ed assistente per informazioni
personali) e Multiticker
(un'applet di GNOME), possono essere
usate per reperire gli avvisi automaticamente. Il canale RDF è disponibile su
http://www.debian.org/security/dsa.rdf
.
Gli avvisi di sicurezza pubblicati sul sito potrebbero essere aggiornati dopo
essere stati spediti alle mailing-list pubbliche. Un aggiornamento tipico è
aggiungere riferimenti incrociati ai database delle vulnerabilità di sicurezza
come CVE
, CERT/CC vulnerability notes
oppure
Bugtraq
. Questa
caratteristica è stata aggiunta al sito nel Giugno 2002.
Uno dei vantaggi dell'aggiungere riferimenti incrociati a questi database di vulnerabilità è che:
Poiché Debian supporta attualmente un grande numero di architetture, gli amministratori a volte si sorprendono se una determinata architettura impiega più tempo per ricevere gli aggiornamenti per la sicurezza rispetto ad un'altra. È un dato di fatto, tranne in rare circostanze, che gli aggiornamenti siano disponibili per tutte le architetture allo stesso tempo.
In precedenza il lavoro di costruzione degli aggiornamenti di sicurezza veniva
fatto a mano, oggi non più (come Anthony Towns descrive in una a
email
inviata alla mailing list debian-devel-announce datata 8
giugno 2002).
FIXME: aggiungere puntatore.
I pacchetti sono aggiornati dal Security Team (in security.debian.org:/org/security.debian.org/queue/unchecked
o in ftp://security.debian.org/pub/SecurityUploadQueue
,
con una patch appropriata viene verificata la firma entro quindici minuti
dall'aggiornamento, una volta fatto, vengono aggiunti alla lista degli
autobuilder (che non eseguono più di un archivio al giorno). Comunque, i
pacchetti vengono costruiti automaticamente per tutte le architetture
mezz'ora o un'ora circa dopo l'aggiornamento. In ogni caso, gli aggiornamenti
di sicurezza sono un po' differenti dai normali aggiornamenti inviati dai
manutentori dei pacchetti poiché, in alcuni casi, prima di essere pubblicati
devono aspettare di essere testati più a fondo, o deve essere scritto un
avviso, o hanno bisogno di una settimana o più per evitare di pubblicare i
problemi, finché tutti i distributori non hanno la concreta possibilità di
correggerlo.
L'archivio aggiornamenti di sicurezza funziona con la seguente procedura (chiamata "Autocostruzione-Accettata"):
dpkg-scanpackages
, dpkg-scansources
...).
Questa procedura, precedentemente fatta a mano, è stata testata ed immessa nello stadio di congelamento di Debian 3.0 woody (luglio 2002). Grazie a questa infrastruttura, il Security Team è stato in grado di avere pacchetti aggiornati pronti per le uscite di Apache ed OpenSSH per tutte le architetture supportate (quasi venti), in meno di un giorno.
Questa mail è stata inviata da Wichert Akkerman alla mailing
list Debian-devel-announce
per descrivere il comportamento degli
sviluppatori Debian in relazione ai problemi di sicurezza nei loro pacchetti.
È stata pubblicata qui, sia a beneficio degli sviluppatori, che per gli
utenti, al fine di comprendere meglio come la sicurezza è gestita in Debian.
Notate che il riferimento aggiornato per queste informazioni è la Guida
per gli sviluppatori Debian
, questa sezione sarà rimossa nelle
prossime uscite.
Se uno sviluppatore viene a conoscenza di un problema di sicurezza, in un suo pacchetto o in quello di qualcun altro, dovrebbe sempre contattare il Security Team (presso team@security.debian.org). È loro compito tenere traccia dei nuovi problemi di sicurezza, possono aiutare i manutentori con i problemi di sicurezza o risolverli, sono responsabili dell'invio degli avvisi di sicurezza e della manutenzione di security.debian.org.
Notate che gli avvisi di sicurezza sono effettuati solo per le distribuzioni realise, non per quelle testing, unstable (vedete Come viene gestita la sicurezza in testing ed unstable?, Sezione 11.3.7) o per le distribuzioni più datate (vedete Utilizzo una vecchia versione di Debian, è supportata dal Security Team di Debian?, Sezione 11.3.8).
Ci sono vari modi in cui uno sviluppatore può venire a conoscenza di un problema di sicurezza:
Nei primi due casi l'informazione è pubblica ed è importante rimediare il più presto possibile. Nell'ultimo caso l'informazione potrebbe non essere pubblica e in quel caso ci sono varie possibilità per trattare il problema:
In ogni caso, se la persona che riporta il problema chiede di non rilasciare l'informazione deve essere rispettata la sua decisione, con l'ovvia eccezione di informare il Security Team (lo sviluppatore dovrebbe avvertire il Security Team che l'informazione non può essere resa nota).
Notate che se è necessaria la segretezza, lo sviluppatore può anche non fornire un rimedio per unstabel (o altro), poiché il log di informazione delle modifiche per la unstable è di dominio pubblico.
Ci sono due ragioni per rilasciare informazioni anche se la segretezza è richiesta/necessaria: il problema è noto da troppo tempo, o l'informazione diventa pubblica.
Il codice di comportamento più importante quando si crea un nuovo pacchetto che corregge un problema di sicurezza è di apportare il minor numero di modifiche possibili. La gente fa affidamento su un determinato comportamento di un programma, una volta rilasciato, quindi ogni modifica fatta può compromettere un sistema. Questo è vero soprattutto per le librerie: lo sviluppatore deve accertarsi di non aver cambiato l'API o l'ABI con qualunque modifica, per quanto minima, possa aver apportato.
Questo significa che passare ad una versione più recente non è una buona soluzione; invece sarebbe bene introdurre le modifiche nella vecchia. Di solito i manutentori della versione recente sono disponibili se serve aiuto, altrimenti il Security Team di Debian potrebbe dare una mano.
Talvolta non è possibile introdurre aggiornamenti per la sicurezza in versioni precedenti, per esempio quando sarebbe necessario modificare o riscrivere gran parte del codice. In questo caso sarebbe necessario passare ad una nuova versione, ma questo passaggio va coordinato prima con il Security Team.
In relazione a questo c'è un altro aspetto da considerare: gli sviluppatori devono testare le vostre modifiche. Se esiste un exploit, lo sviluppatore deve provare se effettivamente la versione originale è vulnerabile e se quella modificata non lo è. Lo sviluppatore deve anche testare il pacchetto nell'uso normale, visto che a volte una correzione per la sicurezza può portare a malfunzionamenti nell'uso ordinario.
Per finire, gli sviluppatori devono ricordare alcuni dettagli tecnici:
pbuilder
e debootstrap
possono essere utili in questo
caso).
Dopo che uno sviluppatore ha creato e testato il nuovo pacchetto, questo deve essere caricato in modo da poter essere disponibile negli archivi. Gli aggiornamenti di sicurezza vanno caricati in ftp://security.debian.org/pub/SecurityUploadQueue/.
Una volta che l'aggiornamento di sicurezza è stato accettato, il pacchetto viene automaticamente costruito per tutte le architetture e conservato in modo che possa essere verificato dal Security Team.
Solo il Security Team può accedere agli aggiornamenti in attesa di essere accettati o verificati. Questa procedura è necessaria perché ci potrebbero essere delle correzioni a problemi di sicurezza che non possono ancora essere rese note.
Se un membro del Security Team accetta un pacchetto, questo viene reso disponibile in security.debian.org, così come in <codename>-proposed-updates, in ftp-master o nell'archivio non-US.
Gli annunci sulla sicurezza sono scritti e pubblicati dal Security Team. Tuttavia i manutentori possono contribuire fornendo il testo da pubblicare (o una sua parte). Le informazioni che devono essere contenute in un annuncio sulla sicurezza sono descritte in Avvisi di sicurezza Debian, Sezione 7.2.
Questa sezione poteva anche essere intitolata "come aggiornare in sicurezza il proprio sistema Debian GNU/Linux" e fondamentalmente merita una propria sezione perché è una parte importante della "infrastruttura di sicurezza". La firma dei pacchetti è una cosa da tenere in considerazione, dal momento che impedisce la manomissione dei pacchetti distribuiti sui mirror e gli attacchi di tipo man-in-the-middle sui download. L'aggiornamento automatico del software è una caratteristica importante ma è altrettanto importante anche eliminare i rischi che quest'operazione possa permettere la distribuzione di trojan e la compromissione del sistema durante gli aggiornamenti. [27].
Ad oggi (dicembre 2001) Debian non fornisce pacchetti firmati per la propria distribuzione e il rilascio di woody (3.0) non integra questa caratteristica. Esiste una soluzione per la firma dei pacchetti che sarà implementata, se possibile, nel prossimo rilascio (sarge).
Questo problema è discusso più approfonditamente nello Strong
Distribution HOWTO
di V. Alex Brennen.
L'attuale (non implementato) schema di controllo della firma dei pacchetti
usando apt
è il seguente:
Seguendo la catena delle firme MD5 apt
è in grado di verificare se
un pacchetto proviene da una determinata versione. Questo è meno flessibile
che firmare ogni singolo pacchetto, uno ad uno, ma può essere combinato anche
con questo schema (vedete più sotto).
La firma dei pacchetti è stata discussa in debian per molto tempo, per altre
informazioni leggete: http://www.debian.org/News/weekly/2001/8/
e http://www.debian.org/News/weekly/2000/11/
.
Lo schema addizionale di firmare ogni pacchetto permette di controllarli quando questi non hanno più referenze in un file Packages già esistente e anche pacchetti di terze parti, dove nessun Packages è mai esistito per loro, possono comunque essere usati in Debian, ma non con lo schema predefinito.
Questo schema di firma dei pacchetti può essere implementato usando
debsig-verify
e debsigs
. Questi due pacchetti
possono firmare e verificare firme all'interno dello stesso pacchetto. Debian
ha già la capacità di farlo ma l'implementazione delle politiche e gli
strumenti, non saranno usati fino a dopo l'uscita della versione woody.
Le ultime versioni di dpkg (dalla 1.9.21) incorporano una patch
che fornisce questa funzionalità non appena debsig-verify
viene
installato.
NOTE: Attualmente /etc/dpkg/dpkg.cfg
nasce con
"no-debsig" come valore predefinito.
NOTE2: Le firme dagli sviluppatori sono attualmente eliminate quando depositano il pacchetto nell'archivio poiché lo stile attualmente in voga consiste nel controllare la release come descritto sopra.
Nel caso vogliate aggiungere il controllo aggiuntivo di sicurezza, potete usare il seguente script, fornito da Anthony Towns. Lo script può fare automaticamente dei nuovi controlli di sicurezza permettendo all'utente di avere la certezza che il software che sta scaricando corrisponda a quello distribuito da Debian. Questo evita agli sviluppatori Debian di entrare nel sistema di qualcuno senza i permessi concessi dall'uploading dell'archivio principale, o ai mirror di copiare qualcosa che non ha a che fare con Debian, o ai mirror di fornire copie datate di versioni instabili con noti problemi di sicurezza.
Questo semplice codice, rinominato come apt-check-sigs
, dovrebbe
essere usato nel modo seguente:
# apt-get update # apt-check-sigs (...results...) # apt-get dist-upgrade
Per prima cosa avete bisogno di:
http://ftp-master.debian.org/ziyi_key_2003.asc
e aggiungerli a ~/.gnupg/trustedkeys.gpg
(che è quello che
gpg
usa in maniera predefinita).
gpg --no-default-keyring --keyring trustedkeys.gpg --import ziyi_key_2003.asc
/etc/apt/sources.list
che non usano la
normale struttura "dists" o modificare lo script in modo che funzioni
con esse.
Questo è il codice di esempio per apt-check-sigs
, la versione più
recente è reperibile presso http://people.debian.org/~ajt/apt-check-sigs
.
Questo codice è attualmente in beta, per maggiori informazioni leggete http://lists.debian.org/debian-devel/2002/debian-devel-200207/msg00421.html
.
#!/bin/bash # This script is copyright (c) 2001, Anthony Towns # # This program is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation; either version 2 of the License, or # (at your option) any later version. # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. rm -rf /tmp/apt-release-check mkdir /tmp/apt-release-check || exit 1 cd /tmp/apt-release-check >OK >MISSING >NOCHECK >BAD arch=`dpkg --print-installation-architecture` am_root () { [ `id -u` -eq 0 ] } get_md5sumsize () { cat "$1" | awk '/^MD5Sum:/,/^SHA1:/' | MYARG="$2" perl -ne '@f = split /\s+/; if ($f[3] eq $ENV{"MYARG"}) { print "$f[1] $f[2]\n"; exit(0); }' } checkit () { local FILE="$1" local LOOKUP="$2" Y="`get_md5sumsize Release "$LOOKUP"`" Y="`echo "$Y" | sed 's/^ *//;s/ */ /g'`" if [ ! -e "/var/lib/apt/lists/$FILE" ]; then if [ "$Y" = "" ]; then # No file, but not needed anyway echo "OK" return fi echo "$FILE" >>MISSING echo "MISSING $Y" return fi if [ "$Y" = "" ]; then echo "$FILE" >>NOCHECK echo "NOCHECK" return fi X="`md5sum < /var/lib/apt/lists/$FILE` `wc -c < /var/lib/apt/lists/$FILE`" X="`echo "$X" | sed 's/^ *//;s/ */ /g'`" if [ "$X" != "$Y" ]; then echo "$FILE" >>BAD echo "BAD" return fi echo "$FILE" >>OK echo "OK" } echo echo "Checking sources in /etc/apt/sources.list:" echo "~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~" echo (echo "You should take care to ensure that the distributions you're downloading" echo "are the ones you think you are downloading, and that they are as up to" echo "date as you would expect (testing and unstable should be no more than" echo "two or three days out of date, stable-updates no more than a few weeks" echo "or a month)." ) | fmt echo cat /etc/apt/sources.list | sed 's/^ *//' | grep '^[^#]' | while read ty url dist comps; do if [ "${url%%:*}" = "http" -o "${url%%:*}" = "ftp" ]; then baseurl="${url#*://}" else continue fi echo "Source: ${ty} ${url} ${dist} ${comps}" rm -f Release Release.gpg wget -q -O Release "${url}/dists/${dist}/Release" if ! grep -q '^' Release; then echo " * NO TOP-LEVEL Release FILE" else origline=`sed -n 's/^Origin: *//p' Release | head -1` lablline=`sed -n 's/^Label: *//p' Release | head -1` suitline=`sed -n 's/^Suite: *//p' Release | head -1` codeline=`sed -n 's/^Codename: *//p' Release | head -1` dateline=`grep "^Date:" Release | head -1` dscrline=`grep "^Description:" Release | head -1` echo " o Origin: $origline/$lablline" echo " o Suite: $suitline/$codeline" echo " o $dateline" echo " o $dscrline" if [ "${dist%%/*}" != "$suitline" -a "${dist%%/*}" != "$codeline" ]; then echo " * WARNING: asked for $dist, got $suitline/$codeline" fi wget -q -O Release.gpg "${url}/dists/${dist}/Release.gpg" sigline="`gpgv --status-fd 3 Release.gpg Release 3>&1 >/dev/null 2>&1 | sed -n "s/^\[GNUPG:\] GOODSIG [0-9A-Fa-f]* //p"`" if [ "$sigline" ]; then echo " o Signed by: $sigline" else echo " * NO VALID SIGNATURE" >Release fi fi okaycomps="" for comp in $comps; do if [ "$ty" = "deb" ]; then X=$(checkit "`echo "${baseurl}/dists/${dist}/${comp}/binary-${arch}/Release" | sed 's,//*,_,g'`" "${comp}/binary-${arch}/Release") Y=$(checkit "`echo "${baseurl}/dists/${dist}/${comp}/binary-${arch}/Packages" | sed 's,//*,_,g'`" "${comp}/binary-${arch}/Packages") if [ "$X $Y" = "OK OK" ]; then okaycomps="$okaycomps $comp" else echo " * PROBLEMS WITH $comp ($X, $Y)" fi elif [ "$ty" = "deb-src" ]; then X=$(checkit "`echo "${baseurl}/dists/${dist}/${comp}/source/Release" | sed 's,//*,_,g'`" "${comp}/source/Release") Y=$(checkit "`echo "${baseurl}/dists/${dist}/${comp}/source/Sources" | sed 's,//*,_,g'`" "${comp}/source/Sources") if [ "$X $Y" = "OK OK" ]; then okaycomps="$okaycomps $comp" else echo " * PROBLEMS WITH component $comp ($X, $Y)" fi fi done [ "$okaycomps" = "" ] || echo " o Okay:$okaycomps" echo done echo "Results" echo "~~~~~~~" echo allokay=true cd /tmp/apt-release-check diff <(cat BAD MISSING NOCHECK OK | sort) <(cd /var/lib/apt/lists && find . -type f -maxdepth 1 | sed 's,^\./,,g' | grep '_' | sort) | sed -n 's/^> //p' >UNVALIDATED cd /tmp/apt-release-check if grep -q ^ UNVALIDATED; then allokay=false (echo "The following files in /var/lib/apt/lists have not been validated." echo "This could turn out to be a harmless indication that this script" echo "is buggy or out of date, or it could let trojaned packages get onto" echo "your system." ) | fmt echo sed 's/^/ /' < UNVALIDATED echo fi if grep -q ^ BAD; then allokay=false (echo "The contents of the following files in /var/lib/apt/lists does not" echo "match what was expected. This may mean these sources are out of date," echo "that the archive is having problems, or that someone is actively" echo "using your mirror to distribute trojans." if am_root; then echo "The files have been renamed to have the extension .FAILED and" echo "will be ignored by apt." cat BAD | while read a; do mv /var/lib/apt/lists/$a /var/lib/apt/lists/${a}.FAILED done fi) | fmt echo sed 's/^/ /' < BAD echo fi if grep -q ^ MISSING; then allokay=false (echo "The following files from /var/lib/apt/lists were missing. This" echo "may cause you to miss out on updates to some vulnerable packages." ) | fmt echo sed 's/^/ /' < MISSING echo fi if grep -q ^ NOCHECK; then allokay=false (echo "The contents of the following files in /var/lib/apt/lists could not" echo "be validated due to the lack of a signed Release file, or the lack" echo "of an appropriate entry in a signed Release file. This probably" echo "means that the maintainers of these sources are slack, but may mean" echo "these sources are being actively used to distribute trojans." if am_root; then echo "The files have been renamed to have the extension .FAILED and" echo "will be ignored by apt." cat NOCHECK | while read a; do mv /var/lib/apt/lists/$a /var/lib/apt/lists/${a}.FAILED done fi) | fmt echo sed 's/^/ /' < NOCHECK echo fi if $allokay; then echo 'Everything seems okay!' echo fi rm -rf /tmp/apt-release-check
Potrebbe essere necessario applicare questa patch per sid perché
md5sum
aggiunge un "-" quando l'input è stdin:
@@ -37,7 +37,7 @@ local LOOKUP="$2" Y="`get_md5sumsize Release "$LOOKUP"`" - Y="`echo "$Y" | sed 's/^ *//;s/ */ /g'`" + Y="`echo "$Y" | sed 's/-//;s/^ *//;s/ */ /g'`" if [ ! -e "/var/lib/apt/lists/$FILE" ]; then if [ "$Y" = "" ]; then @@ -55,7 +55,7 @@ return fi X="`md5sum < /var/lib/apt/lists/$FILE` `wc -c < /var/lib/apt/lists/$FILE`" - X="`echo "$X" | sed 's/^ *//;s/ */ /g'`" + X="`echo "$X" | sed 's/-//;s/^ *//;s/ */ /g'`" if [ "$X" != "$Y" ]; then echo "$FILE" >>BAD echo "BAD"
Securing Debian Manual
Version: 2.97, Mon, 16 May 2005 21:28:06 +0200jfs@debian.org