* Re: [gentoo-docs-it] glsa coordinator_guide.xml
2007-06-06 19:25 ` Davide Cendron
@ 2007-06-06 22:09 ` Davide Cendron
0 siblings, 0 replies; 3+ messages in thread
From: Davide Cendron @ 2007-06-06 22:09 UTC (permalink / raw
To: gentoo-docs-it
[-- Attachment #1.1: Type: text/plain, Size: 1099 bytes --]
Il Wednesday 06 June 2007 21:25:49 Davide Cendron ha scritto:
> Il Wednesday 06 June 2007 13:51:51 Luigi 'Comio' Mantellini ha scritto:
> > Ho fatto l'aggiornamento del documento in oggetto (erano giusto due
> > cose).
> >
> > Il documento comunque necessita di una profonda revisione per correggere
> > stile e formattazione. Dato che questo processo sarà un po' più lungo (il
> > tempo che ho non è tantissimo), procederei nel seguente modo:
> >
> > - Bug report di QUESTA versione per allineare comunque il cvs italiano;
>
> Ok
>
> > - Revisione di sostanza per correggere il documento ed adattarlo nello
> > stile e nella forma;
>
> Ok n°2, io provo comunque a darci una sistemata veloce, e te lo rispedisco,
> e poi attendo l'eventuale buggozzo
>
> > - Secondo bug report con la versione REVISIONATA
> > appena possibile.
>
> Ok n°3 :)
>
> Ciao,
Ciapa qua una revisione "quick'n dirty" 8)
(Sì, c'è tanto lavoro da fare ancora... :( )
Ciao,
--
Davide Cendron
Gentoo Documentation Project
Italian Follow Up Translator
http://www.gentoo.org/doc/it/
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: coordinator_guide.xml --]
[-- Type: text/xml; charset="iso-8859-6"; name="coordinator_guide.xml", Size: 43763 bytes --]
<?xml version='1.0' encoding="UTF-8"?>
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
<!-- $Header:$ -->
<guide link="/security/it/coordinator_guide.xml" lang="it">
<title>Guida per il Coordinatori dei GLSA</title>
<author title="Autore">
<mail link="koon@gentoo.org">Thierry Carrez</mail>
</author>
<author title="Autore">
<mail link="jaervosz@gentoo.org">Sune Kloppenborg Jeppesen</mail>
</author>
<author title="Traduzione">
<mail link="dungeon01@gmail.com">Dungeon01</mail>
</author>
<abstract>
Questo documento contiene le procedure, i suggerimenti e soluzioni utili per il
coordinatore dei GLSA
</abstract>
<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
<license/>
<version>0.8.4</version>
<date>2007-01-24</date>
<chapter>
<title>Prerequisiti</title>
<section>
<title>Account</title>
<body>
<p>
Prima di poter lavorare come coordinatore GLSA è necessario definire un certo
numero di account. Per generare un GLSA dovete ottenere un account <uri
link="https://dev.gentoo.org/glsamaker/">GLSAMaker</uri>. Per gestire bug di
sicurezza dovete avere un account su <uri link="http://bugs.gentoo.org">
Bugzilla</uri>, aggiornato con privilegi di <c>editbugs</c>. Per inviare un GLSA
dovete avere un indirizzo vostronome@gentoo.org (in questo caso per essere uno
sviluppatore Gentoo). Questo indirizzo email dovrà poi essere autorizzato ad
inviare messaggi al mailing-group gentoo-announce. Per rendere definitivi degli
XML di un GLSA è necessario che al vostro developer account venga abilitata la
possibiltà di fare "commit access" verso la directory GLSA nel CVS repository di
<c>gentoo</c>. Infine avete bisogno di un nick IRC. Sarete tenuti a mostrare il
vostro nick nel canale #gentoo-security ogni volta che sarete on-line.
</p>
<note>
Tutti i nomi utilizzati dovrebbero essere costanti in modo tale da rendere più
semplice l'autenticazione.
</note>
</body>
</section>
<section>
<title>La chiave GPG</title>
<body>
<p>
Dovete ora creare una chiave GPG per il vostro account email
vostronome@gentoo.org. Potete generare una chiave specifica o aggiungere
l'indirizzo gentoo.org ad una chiave già esistente. Il key ID dovrebbe essere
inviato a devrelm e dovreste controllare che il vostro nome ed il vostro key ID
appaiano nella <uri
link="http://www.gentoo.org/proj/en/devrel/roll-call/userinfo.xml">developer
list</uri>. È molto importante che la chiave venga pubblicata almeno sul
keyserver <uri link="http://subkeys.pgp.net:11371">subkeys.pgp.net</uri>. Può
essere pubblicata anche su altri keyserver.
</p>
</body>
</section>
<section>
<title>Ambiente</title>
<body>
<p>
Dovete installare un ambiente CVS sulla vostra macchina locale in modo tale da
poter effettuare il commit dei vostri GLSA. Ciò viene reso possibile facendo
il checkout di una parte del CVS repository di <c>gentoo</c> verso una directory
data. (per esempio ~/gentoo_cvs):
</p>
<pre caption="Impostazioni ambiente CVS">
you@home you $ <i>mkdir gentoo_cvs</i>
you@home you $ <i>cd gentoo_cvs</i>
you@home gentoo_cvs $ <i>export CVS_RSH="ssh"</i>
you@home gentoo_cvs $ <i>export CVSROOT="yourname@cvs.gentoo.org:/var/cvsroot"</i>
you@home gentoo_cvs $ <i>cvs checkout gentoo/xml/htdocs/security</i>
</pre>
</body>
</section>
<section>
<title>Sottoscrizioni a Mailing-list</title>
<body>
<p>
Per poter postare verso le liste dove pubblicheremo i nostri GLSA, dovete
iscrivere il vostro account vostronome@gentoo.org ad esse:
</p>
<table>
<tr>
<th>Lista</th>
<th>Pagina d'iscrizione</th>
</tr>
<tr>
<ti>bugtraq@securityfocus.com</ti>
<ti><uri>http://www.securityfocus.com/subscribe</uri></ti>
</tr>
<tr>
<ti>full-disclosure@lists.grok.org.uk</ti>
<ti>
<uri>https://lists.grok.org.uk/mailman/listinfo/full-disclosure</uri>
</ti>
</tr>
</table>
<note>
Potete iscrivervi ad una versione di tipo digest(raccolta) della
Full-Disclosure.
</note>
<p>
Come sviluppatori di sicurezza verrete aggiunti alla lista gentoo-core e al
mailgroup security@gentoo.org. Dovreste anche iscrivervi a gentoo-announce,
gentoo-dev e gentoo-security.
</p>
</body>
</section>
</chapter>
<chapter>
<title>Tipi di bug di Sicurezza e componenti di Bugzilla</title>
<section>
<body>
<p>
Tutti bug di sicurezza sono reperibili nel Bugzilla di <c>Gentoo Security</c>.
Se trovate un bug di sicurezza che ha un nome prodotto errato, per favore
correggetelo immediatamente. Vi sono differenti tipologie di bug di sicurezza,
e ciascuno ha il proprio componente.
</p>
</body>
</section>
<section>
<title>Vulnerabilità</title>
<body>
<p>
Le vulnerabilità sono bug di sicurezza relativi alle versioni originali di un
software o bug introdotti nell'impacchettamento degli ebuild di Gentoo. Questi
bug risultano nei GLSA. I bug relativi al kernel hanno la loro propria categoria
e non dovrebbero essere archiviati come <c>Vulnerabilità</c>.
</p>
</body>
</section>
<section>
<title>Kernel</title>
<body>
<p>
Le vulnerabilità sono trattate utilizzando una procedura a parte. Per
distinguerle facilmente dagli altri bug, esse vengono archiviate sotto la
categoria <c>Kernel</c>. I bug relativi al Kernel non risultano nei GLSA ma
hanno il proprio meccanismo di pubblicazione (Gentoo KISS).
</p>
</body>
</section>
<section>
<title>Configurazione di base</title>
<body>
<p>
I pacchetti Gentoo dovrebbero essere di base i più sicuri possibile. I bug che
toccano la configurazione predefinita vengono inseriti quando la configurazione
di predefinita fornita con il pacchetto può essere migliorata in termini di
sicurezza. I bug relativi alla <c>Configurazione di base</c> non generano alcun
GLSA
</p>
</body>
</section>
<section>
<title>Auditing</title>
<body>
<p>
Le Vulnerabilità di Gentoo che vengono rilevate dovrebbero essere controllate
più volte prima essere rese pubbliche (verso le liste degli sviluppatori
originali o le liste inerenti la sicurezza). Esse vengono archiviate come bug
confidenziali (Confidential Bugs - si veda qui di seguito) e con il componente
<c>Auditing</c>. Quando l'individuazione del bug è stata verificata, questo
viene commutato a <c>Vulnerabilità</c>.
</p>
</body>
</section>
<section>
<title>Bug di tipo "Restricted"</title>
<body>
<p>
A volte un bug ci viene comunicato sotto promessa da parte nostra di mantenerlo
segreto fino ad un pubblico rilascio. I bug limitati hanno la checkbox "Gentoo
Security" selezionata, e quindi possono essere raggiunti solo da membri del
Gentoo Security Team. Gli attori esterni (maintainer del pacchetto, tester
dell'architettura) possono essere aggiunti in base nominale, gli alias non
dovrebbero mai essere utilizzati (questo perchè gli alias sono troppo larghi e
non permettono commenti ai bug).
</p>
<p>
Vi sono tre differenti tipi di bug "restricted". I primi (e i più segreti) sono
i bug <c>CLASSIFIED</c> (classificato). Un bug è definito CLASSIFIED quando
contiene informazioni che non dovrebbero mai venir rilasciate. Questo include
citazioni di email personali inviate a ristrette mailing-lists o patch
intermedie non rese pubbliche. I bug classificati vengono identificati dalla
keyword <c>CLASSIFIED</c>, nella loro Status Whiteboard. Una volta CLASSIFIED,
un bug non può tornare allo stato non classificato se almeno due responsabili
della sicurezza siano d'accordo nel declassare il suddetto bug. I bug
<c>CLASSIFIED</c> non dovrebbero mai essere aperti (resi cioè "UNRESTRICTED").
</p>
<p>
Il secondo tipo di bug è <c>CONFIDENTIAL</c>. questi sono bug contenti
informazioni che dovrebbero essere tenute segrete fino ad una data di emissione
coordinata precedentemente concordata. Nessun aspetto del bug (nome del
pacchetto colpito, descrizione, patch proposte e qualsiasi altra cosa) dovrebbe
mai uscire allo scoperto. Le patch NON dovrebbero essere committate nel portage
CVS.
</p>
<p>
Il terzo (e meno segreto) tipo di bug "Restricted" è dato dai bug
<c>SEMI-PUBLIC</c>. I bug semipubblici dovrebbero restare segreti, ma le patch
potrebbero venire inserite tramite commit in portage. Questo accade di solito
quando la vulnerabilità non è sconosciuta dalla maggioranza del pubblico ma è
accessibile da chiunque (per esempio una patch sul CVS del ramo di sviluppo
originale).
</p>
</body>
</section>
</chapter>
<chapter>
<title>Gestione pubblica della vulnerabilità del bug</title>
<section>
<title>Regole della "Status Whiteboard"</title>
<body>
<p>
Il pannello di stato in Bugzilla ci consente di tener traccia dei passi
effettuati verso la risoluzione del bug di sicurezza. Dovrebbe seguire il
seguente modello "RATING [status] coordinatore", dove:
</p>
<table>
<tr>
<th>Elemento</th>
<th>Contenuto</th>
<th>Esempio</th>
</tr>
<tr>
<ti>RATING</ti>
<ti>Il rating della vulnerabilità seguendo le correnti politiche</ti>
<ti>B3</ti>
</tr>
<tr>
<ti>[status]</ti>
<ti>Lo stato effettivo del bug, con informazioni aggiuntive (opzionali)</ti>
<ti>[ebuild+]</ti>
</tr>
<tr>
<ti>coordinatore</ti>
<ti>Il nickname del coordinatore assegnato al bug in questione</ti>
<ti>koon</ti>
</tr>
</table>
<p>
Sono considerati validi i seguenti tipi di status::
</p>
<table>
<tr>
<th>Status</th>
<th>Descrizione</th>
</tr>
<tr>
<ti>upstream</ti>
<ti>
In attesa che uno sviluppatore pubblichi nel ramo di sviluppo originale una
nuova versione o patch
</ti>
</tr>
<tr>
<ti>upstream+</ti>
<ti>Nessuna risposta dagli sviluppatori originali</ti>
</tr>
<tr>
<ti>ebuild</ti>
<ti>
In attesa che il mantenitore del pacchetto di Gentoo fornisca un ebuild
corretto
</ti>
</tr>
<tr>
<ti>ebuild+</ti>
<ti>
Nessuna risposta ricevuta dal mantenitore, riguardo una falla di sicurezza
</ti>
</tr>
<tr>
<ti>stable</ti>
<ti>
In attesa che le architetture contrassegnino il pacchetto con le keyword
appropriate
</ti>
</tr>
<tr>
<ti>stable+</ti>
<ti>
Alcuni staff di architettura stanno mettendo troppo tempo per contrassegnare
il pacchetto in manera appropriata
</ti>
</tr>
<tr>
<ti>glsa?</ti>
<ti>La sicurezza deve decidere se è necessario un GLSA</ti>
</tr>
<tr>
<ti>glsa</ti>
<ti>In attesa che il coordinatore invii il suo GLSA</ti>
</tr>
<tr>
<ti>glsa+</ti>
<ti>
Il GLSA è in ritardo, ogni coordinatore di GLSA può correggerlo ed inviarlo
</ti>
</tr>
</table>
<p>
Le seguenti informazioni addizionali sono ammesse:
</p>
<table>
<tr>
<th>Informazione addizionale</th>
<th>Descrizione</th>
<th>Stati Corrispondenti</th>
</tr>
<tr>
<ti>tomask</ti>
<ti>Quando un package.mask è stato richiesto verso il pacchetto</ti>
<ti>upstream+, ebuild+</ti>
</tr>
<tr>
<ti>masked</ti>
<ti>se il pacchetto era stato segnato "masked" come soluzione temporanea</ti>
<ti>upstream+, ebuild+</ti>
</tr>
<tr>
<ti>Arch names</ti>
<ti>Quando solo una o due architetture supportate stanno bloccando il bug</ti>
<ti>stable+</ti>
</tr>
<tr>
<ti>tempglsa</ti>
<ti>
Quando un GLSA temporaneo è stato pubblicato come soluzione temporanea
</ti>
<ti>upstream+, ebuild+</ti>
</tr>
<tr>
<ti>blocked</ti>
<ti>Quando il bug è bloccato da un altro bug</ti>
<ti>(any)</ti>
</tr>
</table>
<p>
Esempi:
</p>
<table>
<tr>
<ti>C0 [stable]</ti>
</tr>
<tr>
<ti>A3 [ebuild] jaervosz</ti>
</tr>
<tr>
<ti>B1 [stable+ amd64] koon</ti>
</tr>
</table>
</body>
</section>
<section>
<title>Determinare lo stato di partenza del bug</title>
<body>
<p>
Quando la correzione non è disponibile dallo sviluppatore originale e/o non non
è stata rilasciata una patch ufficiale per risolvere il problema, il bug si
trova in stato [upstream]. Se la soluzione deve essere trovata dagli
sviluppatori Gentoo, il bug è in stato [inhouse]. Se è disponibile una
correzione, il bug si trova nello stato [ebuild]. Se la correzione è stata
inserita nel portage, il bug assume lo stato [stable]. Quando una correzione è
presente nel portage con tutte le chiavi richieste correttamente configurate, il
bug entra in stato [glsa].
</p>
</body>
</section>
<section>
<title>Stato dei bug in [upstream]</title>
<body>
<p>
Nello stato [upstream], siamo in attesa della pubblicazione di una versione
della correzione o di una patch decente. Questo stato richiede controlli
regolari del ramo di sviluppo originale per informazioni: mailing list di
sviluppo e annunci, siti internet, bug database, CVS ove possibile, sono tutte
fonti importanti d'informazioni. Patch non ufficiali devono essere considerate
soltanto se lo sviluppatore originale non reagisce alla vulnerabilità, e devono
essere controllate più volte per assicurarsi che non siano maligne. Quando viene
annunciata una nuova versione di una correzione, o una nuova patch viene
rilasciata, il bug entra nello stato [ebuild].
</p>
<p>
Se da parte degli sviluppatori non c'è nessuna reazione né arriva alcuna patch,
entriamo nello stato [upstream+]. L'unica opzione consiste nell'applicare una
security-mask al pacchetto vulnerabile e pubblicare un glsa temporaneo se
necessario. Vedere la politica corrente per ulteriori dettagli inerenti alla
procedura d'approvazione del security-masking. Il pannello di stato dovrebbe
quindi essere flaggato con le keyworkd masked e/o tempglsa e la bug severity
impostata ad <c>enhancement</c>.
</p>
</body>
</section>
<section>
<title>bug in stato [ebuild]</title>
<body>
<p>
In stato [ebuild], dobbiamo identificare il maintainer del pacchetto, ed
imporgli di generare una correzione. Le fonti per identificare il gruppo o lo
sviluppatore responsabile della manutenzione del pacchetto sono il file
metadata.xml, presente nel portage nella directory inerente al pacchetto, ed il
file Changelog che mostra chi ha effettuato gli ultimi upgrade di versione.
Dovreste mettere in cc: il gruppo e/o il maintainer responsabile del pacchetto
inerente al bug e chiedere che venga fornita un ebuild per la versione della
correzione corrente. Dovreste controllare periodicamente che un ebuild non sia
stata inserito nel portage senza alcuna commento riguardo il bug (a volte
accade). Quando l'ebuild appare, il bug entra in stato [stable]
</p>
<p>
Se il maintainer non lo rivela, arriviamo allo stato [ebuild+]. In casi di
versione di correzione, dovreste testare se un semplice salto di versione
funziona (basta rinominare l'ebuild all'ultima versione e farne l'emerge). In
casi di patch, dovreste testare se si applica in maniera pulita. Allora dovreste
trovare un wrangler di bug di sicurezza con diritti x86 per eseguire il salto
di versione e segnare l'ebuild ~ per testarlo.
</p>
<p>
Se il salto di versione non è facile e/o si rileva un problema con l'ebuild in
questione, l'unica opzione consiste nell'applicare una security-mask al
pacchetto non mantenuto e pubblicare un glsa temporaneo se necessario. Si veda
la politica corrente per ulteriori dettagli inerenti alla procedura
d'approvazione del security-masking. Il pannello di stato dovrebbe quindi essere
flaggato con le keyworkd masked e/o tempglsa e la bug severity impostata a
<c>enhancement</c>.
</p>
</body>
</section>
<section>
<title>Bug in stato [stable]</title>
<body>
<p>
Nello stato [stable], dovete determinare di quali chiavi l'ebuild fornita
necessita prima che il glsa venga pubblicato. Ciò può essere ingannevole. Dovete
considerare ogni versione attualmente presente nel portage in modo che l'ebuild
abbia <e>le stesse o più parole "stable"</e> di qualsiasi ogni altro pacchetto
presente nel portage. Qui v'è un esempio:
</p>
<table>
<tr>
<th>Versioni</th>
<th>Keyword</th>
</tr>
<tr>
<ti>Affected</ti>
<ti>x86 ~ppc ~ia64</ti>
</tr>
<tr>
<ti>Affected</ti>
<ti>x86 ppc</ti>
</tr>
<tr>
<ti>Affected</ti>
<ti>~x86 ~ppc ~ia64</ti>
</tr>
<tr>
<ti>La correzione deve avere:</ti>
<th>x86 ppc ~ia64</th>
</tr>
</table>
<note>
Potete usare <uri>http://packages.gentoo.org</uri> per aiutarvi nel determinare
le keyword necessarie. Qualora i pacchetti interessati fossero stati rimossi
troppo presto dal mantenitore del pacchetto stesso, dovreste usare l'accesso
<uri link="http://www.gentoo.org/cgi-bin/viewcvs.cgi/">CVS</uri> per cercare
nell'archivio delle vecchie keyword.
</note>
<p>
Una volta determinate (ed inserite come riferimento nel bug) le keyword
necessarie, dovreste mettere in Cc: i team di sviluppo delle varie architetture
chiedendo loro di contrassegnare l'ebuild come "stable" o ~ di conseguenza. Gli
alias per le varie architetture sono architettura@gentoo.org (x86@gentoo.org,
ppc@gentoo.org...), Tutte le architetture (incluse quelle "non supportate")
devono essere contattate. Ma si tenga conto che solo le architetture
"supportate" (come definite dal regolamento) sono necessarie prima che il bug
possa avanzare allo stato [glsa]. Dovreste periodicamente controllare per
verificare se vi sono nuove keyword nell'ebuild, dato che talvota queste
vengono modificate senza lasciare nessun commento nel bug. Non appena le keyword
richieste sono state inserite nel bug per tutte le architetture supportate, il
bug entra nello stato [glsa].
</p>
<p>
Se i team di sviluppo per le relative architetture impiegano troppo tempo nel
testare o cambiare le proprie keyword, o rifiutano di contrassegnare come stable
un pacchetto per problemi non ancora risolti, il bug assume lo stato di
[stable+]. Dobbiamo rintracciare i mantenitori delle varie architetture affinché
contrassegnino come stable il pacchetto, e diano supporto nel testing dello
stesso. Dovreste anche convincere gli sviluppatori per le varie architetture che
se scoprono un bug in un'ebuild che era già presente nelle precedenti versioni
"stable", l'ebuild dovrebbe essere contrassegnata come "stable" anche se non è
attualmente stabile, come specificato nella policy. Se non possono essere
rintracciate le keyword, l'unica opzione rimanente è quella di applicare una
security-mask al pacchetto: non esiste alcuna versione accettabile non affetta
dal bug, quindi è come se nessuna correzione accettabile sia stata fornita da
parte degli sviluppatori originali.
</p>
</body>
</section>
<section>
<title>bug in stato [glsa]</title>
<body>
<p>
Nello stato [glsa], il bug di sicurezza è stato corretto. Dobbiamo pubblicare il
GLSA o semplicemente chiudere il bug senza GLSA. Il regolamento determina in
quali casi un GLSA è necessario e in quali casi non lo è. Vi sono anche
situazioni nelle quali è necessario un voto per definire se un GLSA è necessario
o meno. Se almeno due membri del Team di sicurezza votano per "no GLSA", allora
nessun GLSA dovrebbe essere pubblicato. Il bug rimane in stato [glsa] finchè non
viene pubblicato il GLSA.
</p>
<p>
Quando è necessario un GLSA, ma non è stato pubblicato nulla, il bug entra nello
stato [glsa+]. Questo è il caso in cui il coordinatore GLSA assegnato non ha
steso e/o rivisto e/o inviato il proprio GLSA. Gli altri membri del team di
sicurezza dovrebbero prendere il controllo della situazione a questo punto e
finalizzare il GLSA.
</p>
</body>
</section>
</chapter>
<chapter>
<title>Gestione delle vulnerabilità dei bug "confidential"</title>
<section>
<title>Regole del pannello di stato(Status Whiteboard)</title>
<body>
<p>
I bug confidenziali dovrebbero seguire questo modello: "RATING [status]
coordinatore / Data_di_Rilascio CLASSIFIED", dove:
</p>
<table>
<tr>
<th>Elemento</th>
<th>Contenuto</th>
<th>Esempio</th>
</tr>
<tr>
<ti>RATING</ti>
<ti>
Il rating della vulnerabilità, facendo riferimento alle correnti politiche
</ti>
<ti>B3</ti>
</tr>
<tr>
<ti>[status]</ti>
<ti>Lo stato effettivo del bug, con informazioni aggiuntive (opzionali)</ti>
<ti>[ebuild+]</ti>
</tr>
<tr>
<ti>coordinator</ti>
<ti>Il nickname del coordinatore assegnato al bug in questione</ti>
<ti>koon</ti>
</tr>
<tr>
<ti>Release_date</ti>
<ti>La data convenuta per la rilevazione coordinata </ti>
<ti>20050106</ti>
</tr>
<tr>
<ti>CLASSIFIED</ti>
<ti>Il flag opzionale CLASSIFIED per bug classificati</ti>
<ti>CLASSIFIED</ti>
</tr>
</table>
<p>
I seguenti stati supplementari sono accettati per i bug confidenziali:
</p>
<table>
<tr>
<th>Stato</th>
<th>Descrizione</th>
</tr>
<tr>
<ti>preebuild</ti>
<ti>
Il maintainer del pacchetto specifico è stato chiamato a preparare un'ebuild
che non dovrebbe essere inserita nel tree del CVS
</ti>
</tr>
<tr>
<ti>prestable</ti>
<ti>
Tester di una specifica architettura sono stati chiamati a testate un ebuild
non ancora pubblico
</ti>
</tr>
</table>
</body>
</section>
<section>
<title>Maneggiare bug confidenziali</title>
<body>
<p>
I bug semipubblici dovrebbero essere trattati come bug pubblici, a parte il
fatto che nessun gruppo di sviluppo o alias per le varie architetture dovrebbe
essere messo in CC tranne gli sviluppatori specifici per quel bug.
</p>
<p>
I bug confidenziali e classificati richiedono maggiore attenzione. L'ebuild ed
i file per correggere la vulnerabilità NON dovrebbero essere aggiunti al CVS
del portage, e nessun aspetto di quei bug dovrebbero essere discussi in
pubblico. Patch o tarball di sovrascrittura del portage possono comunque essere
allegati al bug. I tester dovranno installare la propria tarball di overlay per
testarla. L'idea con questi bug è di preparare l'ebuild e farlo testare entro la
data di rilascio concordata, in modo tale da poterla rilasciare con tutte le
keyword necessarie insieme al GLSA nello stesso istante in cui il rilascio
dell'ebuild diventa pubblico.
</p>
</body>
</section>
</chapter>
<chapter>
<title>Abozzare GLSA con GLSAMaker</title>
<section>
<title>Regole Generali</title>
<body>
<p>
Il GLSA dovrebbe utilizzare il nome del software colpito prestando attenzione a
maiuscole/minuscole, non utilizzando, quindi il nome del pacchetto di Gentoo.
Per esempio, dovreste utilizzare "MySQL" e non "mysql". I nomi in minuscolo
dovrebbero essere utilizzati solo se il software ha un nome tutto in minuscolo o
se il software è identificato dal nome del suo comando (ad esempio
"traceroute").
</p>
<p>
Non dovreste copiare nessuna parte di una descrizione già esistente, ma potete
utilizzarle come fonti d'informazione per il GLSA. Se copiate, per esempio una
descrizione di un software da un sito internet, per favore utilizzate una
citazione e le virgolette.
</p>
</body>
</section>
<section>
<title>Titolo, Sinossi, Keyword</title>
<body>
<p>
Il titolo deve essere corto (< 60 caratteri nella maggior parte dei casi) ed
indicare il nome dell'applicazione (non la categoria). Dovrebbe consentire
d'indentificare chiaramente la vulnerabilità senza entrare nei dettagli. La
versione dovrebbe essere omessa, tranne nei rari casi in cui è permesso
identificare un pacchetto più chiaramente. I pacchetti multipli colpiti
dovrebbero essere separati da una virgola. Gli esempi includono:
</p>
<table>
<tr>
<ti>MySQL: creazione insicura di un file temporaneo</ti>
</tr>
<tr>
<ti>Exim: verify=header_syntax buffer overflow</ti>
</tr>
<tr>
<ti>Apache 1.3: Heap overflow in mod_redirect</ti>
</tr>
<tr>
<ti>MPlayer, xine-lib: Vulnerabilities in RTSP stream handling</ti>
</tr>
</table>
<p>
La sinossi è una corta (< 160 caratteri) ma completa descrizione della
vulnerabilità di quale effetto abbia. Gli esempi includono:
</p>
<table>
<tr>
<ti>
Due utilità MySQL creano file temporanei con path hardcoded, consentendo
ad un attaccante di utilizzare un link simbolico per ingannare MySQL nel
sovrascrivere dati importanti.
</ti>
</tr>
<tr>
<ti>
Vulnerabilità multiple, inclusi buffer overflow eseguibili da remoto sono
stati rilevati nel codice comune tra Mplayer e la libreria xine
</ti>
</tr>
</table>
<p>
La categoria delle keywords GLSA è solitamente impostata a "Ebuild" e dovrebbe
contenere il nome del principale software vulnerabile (per esempio "MySQL").
Altri tipi di keyword includono "Portage" (per bug del portage) e
"Infrastructure" (compromissioni dei servers).
</p>
</body>
</section>
<section>
<title>Accesso, Severity</title>
<body>
<p>
L'accesso dovrebbe essere "Locale" o "Remoto". Le vulnerabilità locali possono
essere gestite solo da un utente locale del sistema in questione. Per esempio
implica esguire uno script per elevare i privilegi, oppure accedere ad una
directory temporanea per far partire un symlink attack. Le vulnerabilità remote
sono quelle che possono essere eseguite da un attaccante con o senza un account
sul sistema bersaglio. Le vulnerabilità remote possono essere sia attive
(sfruttando un server in ascolto per inviare codice maligno) o passive (attirare
un utente per collegare il software residente sul client ad un server "maligno"
o ad aprire file con codice analogo).
</p>
<p>
La severity è un'indicazione di quanto in profondità arrivi la vulnerabilità.
Viene definita nella Vulnerability Treatment Policy, nella tabella "Evaluate the
vulnerability type". Notare che dipende solo dal massimo rischio, non dal
fattore comune della configurazione delle opzioni al rischio. Un buffer overflow
che consenta l'esecuzione di codice arbitratio in un raro client software, solo
quando si utilizza una specifica opzione di configurazione, teoricamente rimane
una severità "Alta". Un DoS in tutte le configurazioni di Apache teoricamente
resta serverità "Normale". In rari casi la severity può essere corretta, quando
molti membri del team di sicurezza sono d'accordo, verso un livello più alto.
Per esempio, una vulnerabilità che consentisse il deface di un sito internet in
Apache ed in tutte le configurazioni dovrebbe probabilmente essere a severity
"Alta" piuttosto che "Normale".
</p>
</body>
</section>
<section>
<title>Pacchetti vulnerabili, inalterati</title>
<body>
<p>
Questa sezione fornisce informazioni sulle versioni dei pacchetti che sono
rimasti inalterati o vulnerabili alla vulnerabilità descritta nell'informativa
corrente. Dovreste prestare attenzione particolare a quei numeri, perchè
rappresentano una delle poche zone dove ogni errore implica un'errata
pubblicazione.
</p>
<p>
Ci sono diversi campi che compongono il valore di una versione. Il campo
contenente il nome del pacchetto deve elencare il nome del pacchetto e la
categoria ("net-mail/exim"). Riguardo il campo "Architetture", dovreste
inserirvi "*" quando la descizione della versione si applica a tutte le
architetture contrassegnate nell'ebuild. Dovreste utilizzare voci multiple
per architetture differenti se la descrizione della versione è differente di
architettura in architettura. Il campo "Auto" deve essere impostato a "true" se
il paccchetto è aggiornabile via emerge. Per i campi versione possono esservi
molteplici casistiche.
</p>
<impo>
In questa sezione (e soltanto in questa sezione), le architetture dovrebbero
essere scritte così come compaiono nelle keyword (cioè "x86", "amd64", "sparc",
...), e non in maiuscolo.
</impo>
<p>
Il caso più semplice si verifica quando la vulnerabilità è presente in tutte le
vecchie versioni ed è corretta in tutte le versioni più recenti rispetto alla
versione di una specifica correzione. In questo caso, dovreste usare ">=
prima versione corretta" come inalterata e "<= ultima versione colpita" come
vulnerabile. Dovreste controllare più volte che non esista un'ebuild fra
l'ultima versione colpita e la prima versione corretta. Qualora vi trovaste in
dubbio, dovreste usare ">= prima versione corretta" come inalterata e
"<= prima versione corretta" come vulnerabile.
</p>
<p>
Un caso più complesso si verifica quando la vulnerabilità si presenta soltanto
in alcune versioni recenti. Facciamo l'esempio di un pacchetto dove la versione
1.2.8-r2 non è stata colpita,le versioni 1.2.9, 1.2.9-r1 e 1.2.9-r2 sono state
colpite e la versione 1,2,10 è stata corretta. In questo caso ci sono due
possibilità.
</p>
<table>
<tr>
<th>Inalterata</th>
<th>Vulnerabile</th>
</tr>
<tr>
<ti>>=1.2.10</ti>
<ti>==1.2.9 ==1.2.9-r1 ==1.2.9-r2</ti>
</tr>
<tr>
<ti><=1.2.8-r2 >=1.2.10</ti>
<ti><1.2.10</ti>
</tr>
</table>
<p>
Per concludere, quando il pacchetto non ha una versione corretta, dovreste
omettere l'opzione "inalterato" (unaffected) per quel pacchetto ed impostare
"Auto" a "no".
</p>
<impo>
Quando le versioni delle correzione sono complesse, dovreste controllare più
volte che le versioni XML e TXT del GLSA elenchino correttamente le vostre
versioni.
</impo>
</body>
</section>
<section>
<title>Background, Descrizione, Impatto</title>
<body>
<p>
La sezione Background fornisce le informazioni sul pacchetto a rischio. Descrive
brevemente cos'è e fornisce tutte le informazioni utili a comprendere la parte
del pacchetto vulnerabile. La sezione Background dovrebbe essere più corta della
sezione di descrizione o della sezione impatto (Impact). Tra gli esempi da
seguire includiamo:
</p>
<table>
<tr>
<ti>
Il K Desktop Environement (KDE) è un potente ambiente grafico desktop della
Free Software foundation. KDE usa gli URI handlers per innescare vari
programmi quando vengono ricevute delle URL specifiche.
</ti>
</tr>
<tr>
<ti>
CVS (Concurrent Versions System) è un sistema open-source di controllo di
versione network-transparent. Contiene sia una client utility che un server.
</ti>
</tr>
<tr>
<ti>
Metamail è un programma che decodifica la posta codificata MIME. Viene
quindi spesso automaticamente invocato quando una email viene letta o
ricevuta.
</ti>
</tr>
</table>
<p>
La sezione "descrizione" descrive più in dettaglio qual è la vulnerabilità senza
dire a che cosa accade quando questa viene sfruttata. Dovrebbe essere
comprensibile da persone senza grandissime basi di sicurezza. A volte non si
trovano affatto le informazioni sulla vulnerabilità, in questi casi dovreste
lasciare la descrizione breve. Tra i buoni esempi includiamo:
</p>
<table>
<tr>
<ti>
Il Telnet URI handler in Opera non controlla l'esistenza di caratteri '- '
iniziali nell'hostname. Di conseguenza, un link maligno del tipo telnet://
potrebbe essere capace di passare opzioni al telnet stesso. Un esempio
sarebbe "telnet://-nMyFile". Se MyFile esiste nella home directory
dell'utente e l'utente che clicca sul link ha i permessi di scrittura su di
esso, i contenuti del file saranno sovrescritti con'output delle
informazioni del telnet trace. Se MyFile non esiste, il file verrà generato
nella home directory dell'utente.
</ti>
</tr>
<tr>
<ti>
L'utility di bug reporting di MySQL (mysqlbug) genera un file temporaneo per
loggarvi i bug report. Un utente locale "maligno" con diritti di scrittura
su /tmp potrebbe generare un link simbolico dal nome mysqlbug-N puntante ad
un file protetto, come /etc/passwd, in modo tale che qualora mysqlbug
generasse l'ennesimo file di log, finirebbe con il sovrascrivere l'obiettivo
(nel nostro esempio, /etc/passwd). Una vulnerabilità simile esiste con
l'utilità mysql_multi , che genera una file temporaneo denominato
mysql_multi.log.
</ti>
</tr>
<tr>
<ti>
Vulnerabilità multiple sono state scovate e riparate nell'RTSP che gestisce
il codice in comune alle versioni recenti di questi due pacchetti. Queste
vulnerabilità includono parecchi buffer overflow sfruttabili da remoto.
</ti>
</tr>
</table>
<p>
La sezione "Impact" descrive l'effetto globale delle vulnerabilità descritte
nella sezione "descrizione", una volta sfruttate. Dovrebbe focalizzarsi sul
massimo rischio possibile. Buoni esempi sono:
</p>
<table>
<tr>
<ti>
Un attaccante remoto, presentandosi come RTSP stream server, può eseguire
codice arbitrariamente con i diritti dell'utente del software che sta
eseguendo lo stream (MPlayer o qualsiasi altro player che utilizzi
xine/xine-lib). Un altro attaccante può attirare un utente per usare un URL
"maligna" o una playlist per ottenere lo stesso identico risultato
</ti>
</tr>
<tr>
<ti>
Questo exploit ha due possibili effetti. In primo luogo, può generare nuovi
file nella home directory dell'utente. In secondo luogo, e molto più
pericoloso, può sovrascrivere i file esistenti per i quali l'utente ha i
permessi di scrittura. Un attaccante con una certa conoscenza della home
directory dell'utente potrebbe essere in grado di distruggere file
importanti salvati in quella directory.
</ti>
</tr>
</table>
</body>
</section>
<section>
<title>Workaround, Soluzione</title>
<body>
<p>
Il workaround descrive se esiste una qualsiasi maniera semplice (tranne
l'aggiornamento alla versione di correzione) per evitare di essere vittime della
vulnerabilità. I buoni esempi includono:
</p>
<table>
<tr>
<ti>
Come workaround provvisorio, bypassando il supporto del Kerberos 4, potreste
spegnere il kadmin del Kerberos 4 facendo partire il kadmind con l'opzione
<c>--no-kerberos4</c>.</ti>
</tr>
<tr>
<ti>Ad oggi non esistono workaround conosciuti.</ti>
</tr>
</table>
<p>
La sezione "Risoluzione" spiega nei termini human-readable che cosa dovete fare
per completamente essere protetti dalla vulnerabilità. Questa sezione deve
assomigliare a questa:
</p>
<pre caption="Esempio di risoluzione">
Tutti gli utenti di Heimdal dovrebbero effettuare l'upgrade all'ultima versione stabile:
<code>
# emerge --sync
# emerge --ask --oneshot --verbose ">=app-crypt/heimdal-0.6.2"
</pre>
<p>
Qualora vi fossero più architetture, dovrebbe assomigliare a questa
</p>
<pre caption="Esempio multi-architettura">
Gli utenti di OpenOffice.org su SPARC dovrebbero:
<code>
# emerge --sync
# emerge --ask --oneshot --verbose ">=app-office/openoffice-1.1.0-r3"
</code>
</p>
<p>
Gli utenti di OpenOffice.org su PPC dovrebbero:
</p>
<code>
# emerge --sync
# emerge --ask --oneshot --verbose ">=app-office/openoffice-1.0.3-r1"
</pre>
<p>
Se il GLSA riguarda una libreria condivisa, dovreste includere il seguente
paragrafo all'estremità della sezione "risoluzione" per avvisare circa la
necessità di effettuare la rebuild degli eseguibili collegati.
</p>
<table>
<tr>
<ti>
I pacchetti che dipendono da questa libreria possono avere bisogno di essere
ricompilati. Strumenti come revdep-rebuild possono aiutare nell'identificare
alcuni dei questi pacchetti.
</ti>
</tr>
</table>
</body>
</section>
<section>
<title>Riferimenti</title>
<body>
<p>
La sezione "Riferimenti" dovrebbe fornire i collegamenti alle informazioni di
riferimento sulla vulnerabilità in questione. Quando un numero CVE
(CVE-xxxx-xxx) è disponibile, dovrebbe essere fornito (con il numero CAN
completo in "Title"). Potete anche collegare uno advisory di uno sviluppatore
upstream e/o un'email announce, quando disponibili. Dovreste evitare
collegamenti ad advisory di altre distribuzioni o advisory non ufficiali
provenienti da entità esterne.
</p>
</body>
</section>
</chapter>
<chapter>
<title>Pubblicazione GLSA </title>
<section>
<title>Peer reviewing</title>
<body>
<p>
Quando la bozza iniziale è pronta, deve essere sottoposta alla revisione degli
altri membri del team di sicurezza, effettuando una richiesta di revisione sul
canale #gentoo-security. La versione finale (dopo che tutte le correzioni sono
state applicate) deve essere approvata da due membri del team di sicurezza prima
di essere committata e spedita.
</p>
<p>
Nel rivedere la bozza di un GLSA, controllare con attenzione le seguenti cose:
</p>
<ul>
<li>
Versoni colpite/inalterate (Controllare nel Changelog che le versioni siano
corrette e assicurarsi che non vi siano versioni che non siano definite o
colpite o inalterate ).
</li>
<li>Correttezza del titolo.</li>
<li>
Severity ed accesso (Non fate solo riferimento al rating del bug e se è
necessario un account locale o remoto per un accesso "local o remote" ).
</li>
<li>
Alla fine viene effettuato un sanity check: si verifica che sia veramente
una vulnerabilità e non un semplice bug (come le non-vulnerabilities di
samba e shadow)
</li>
</ul>
<p>
Quando la bozza viene approvata, deve esserle assegnato un numero ufficiale
GLSA. Ciò viene fatto chiamando la funzione "Move" in GLSAMaker per spostare la
bozza dalla zona di sviluppo alla zona ufficiale.
</p>
</body>
</section>
<section>
<title>GLSA XML commit</title>
<body>
<p>
Dovete effettuare il commit del GLSA XML nel tree del CVS di Gentoo in modo che
compaia automaticamente nell'handling del feed RDF, nella lista dei GLSA e negli
aggiornamenti del portage. Dovreste in primo luogo aggiornare la vostra
directory GLSA nel tree del gentoo CVS repository:
</p>
<pre caption="Aggiornamento CVS">
you@home you $ <i>cd gentoo_cvs</i>
you@home gentoo_cvs $ <i>cvs update -dP gentoo/xml/htdocs/security</i>
</pre>
<p>
A questo punto dovreste cliccare<c>Fetch</c> nel GLSA per scaricare la versione
XML, e salvarla nella vostra
directory gentoo_cvs/gentoo/xml/htdocs/security/en/glsa/. A questo punto
dovreste effettuare il commit ed aggiungere il file XML:
</p>
<pre caption="Commit GLSA">
you@home gentoo_cvs $ <i>cd gentoo/xml/htdocs/security/en/glsa</i>
you@home glsa $ <i>cvs add glsa-YYYYMM-NN.xml</i>
you@home glsa $ <i>cvs commit -m "GLSA YYYYMM-NN" glsa-YYYYMM-NN.xml</i>
</pre>
</body>
</section>
<section>
<title>E-mail announcement</title>
<body>
<warn>
Ogni volta che usate un nuovo setup (software o macchina) per inviare un
annuncio GLSA, dovreste far sì che il vostro setup venga controllato, inviando
un'email di test ad un altro membro del team di sicurezza.
</warn>
<p>
Cliccare su Txt download per ottenere una versione di testo del GLSA.
Controllare che la sezione colpite/inalterate (affected/unaffected) sembri
corretta, quindi preparare una mail con le seguenti regole:
</p>
<ul>
<li>
<b>Da </b> e<b>Indirizzo di Ritorno</b> devono essere impostati a
vostronome@gentoo.org
</li>
<li><b>To</b> e<b>Cc</b> dovrebbero essere configurati secondo policy</li>
<li>
<b>Oggetto</b> deve essere "[ GLSA XXXXYY-ZZ ] la vostra vulnerabilità qui"
(dovreste copiare/incollare dal titolo nel file di testo)
</li>
<li>
Il corpo della mail dovrebbe corrispondere al contenuto del file di testo,
dalla header "Gentoo Linux Security Advisory" alla fine del file
</li>
<li>
L'email deve essere firmata dalla chiave GPG per l'indirizzo
vostronome@gentoo.org
</li>
</ul>
<note>
Riceverete un'email di ritorno da gentoo-announce dicendo che è richiesta
moderazione. Basta rispondere a questa mail e l'email announce precedentemente
detta arriverà a destinazione.
</note>
</body>
</section>
<section>
<title>Chiusura dei bug</title>
<body>
<p>
Dovreste controllare che la mail sia arrivata a gentoo-announce, poi potete
chiudere il bug(s) relativo, regolando la condizione a <b>RESOLVED/FIXED</b>,
con un commento indicante numero GLSA.
</p>
</body>
</section>
<section>
<title>Pubblicazione Errata/Aggiornamenti</title>
<body>
<p>
Un errata viene pubblicato quando viene commesso un errore, altrimenti stiamo
parlando di un aggiornamento. Quando la policy garantisce una ripubblicazione
dovrebbero essere seguite queste linee guida:
</p>
<ul>
<li>
Il campo revisione dovrebbe essere correttamente impostato in XML. Ciò
significa che la revisione potrebbe avere bisogno di di essere corretta
manualmente nella directory data di GLSAMaker, se fate cambiamenti multipli
usando GLSAMaker (es. <revised>September 10, 2004:
02</revised>)
</li>
<li>
Se non sussiste vulnerabilità nessun pacchetto colpito dovrebbe essere
elencato nell'XML
</li>
<li>
Il titolo può cambiare (es. GLSA 200409-14 per Samba e GLSA 200411-01 per
ppp)
</li>
<li>
Non tutti gli Errata richiedono ripubblicazione. La policy spiega
dettagliatamente quando la ripubblicazione è necessaria.
</li>
<li>
Per la versione di testo GLSAmaker può aggiungere le informazioni relative
agli aggiornamenti ed alle errata. Si seguano manualmente le istruzioni
fornite da GLSAmaker.
</li>
<li>
La versione testuale deve contenere la sezione degli aggiornamenti o delle
errata (si veda l'esempio indicato sotto) e soltanto DOPO QUESTO solo
sezioni vengono cambiate (la versione XML non ha sezioni aggiuntive)
</li>
</ul>
<table>
<tr>
<ti>
Questo advisory è stato descritto via ppp in maniera non corretta come
vulnerabile ad un DoS. Dopo ulteriori verifiche, sembra che un utente remoto
possa negare soltanto il servizio a sè stesso, quindi questo bug non induce
alcun problema di sicurezza. Le sezioni corrette compaiono qui sotto.
</ti>
</tr>
</table>
<p>
Ecco due esempi completi di errata email, si veda <uri
link="http://archives.gentoo.org/gentoo-announce/msg_02598.xml">ERRATA:
[ GLSA 200409-14 ] Samba: Remote printing non-vulnerability</uri> (dove non
c'era nessuna vulnerabilità) e <uri
link="http://archives.gentoo.org/gentoo-announce/msg_02502.xml">ERRATA: [ GLSA
200405-25 ] Tla: Multiple vulnerabilities in included libneon</uri> (dove il
problema non era stato corretto in maniera efficace nella versione iniziale).
Per un esempio di update, si veda <uri
link="http://archives.gentoo.org/gentoo-announce/msg_02663.xml">UPDATE: [ GLSA
200410-30 ] GPdf, KPDF, KOffice: Vulnerabilities in included xpdf</uri> (dove la
correzione ha introdotto un'altra vulnerabilità ).
</p>
<p>
Altrimenti dovrebbero essere seguite le linee guida standard GLSA.
</p>
</body>
</section>
</chapter>
<chapter>
<title>GLSA Coordinators Tools</title>
<section>
<title>Reperimento delle Informazioni</title>
<body>
<ul>
<li>
<uri link="http://dev.gentoo.org/~koon/packageview/">packageview</uri> è uno
strumento che aprirà packages.gentoo.org e Gentoo ViewCVS nel punto giusto
per una categoria e una nome pacchetto assegnati. Aiuta a determinare quali
keyword sono richieste per tracciare i cambiamenti di un pacchetto.
</li>
</ul>
</body>
</section>
<section>
<title>Guide GLSA per la pubblicazione</title>
<body>
<ul>
<li>
<uri link="http://dev.gentoo.org/~koon/glsacommit.txt">glsacommit</uri> è
una funzione bash che si occupa l'handling GLSA committing. Caratterizzato
dall'ssh-agent keyadding, glsa-check controlla più volte la conformità ed ha
delle funzioni del tipo "Sei sicuro...?". Modificatelo per soddisfare le
vostre necessità e le posizioni delle directory.
</li>
</ul>
</body>
</section>
</chapter>
</guide>
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread