diff options
Diffstat (limited to 'xml/htdocs/security/it')
| -rw-r--r-- | xml/htdocs/security/it/bug-searching.xml | 184 | ||||
| -rw-r--r-- | xml/htdocs/security/it/coordinator_guide.xml | 1377 | ||||
| -rw-r--r-- | xml/htdocs/security/it/index.xml | 277 | ||||
| -rw-r--r-- | xml/htdocs/security/it/padawans.xml | 345 | ||||
| -rw-r--r-- | xml/htdocs/security/it/vulnerability-policy.xml | 831 |
5 files changed, 3014 insertions, 0 deletions
diff --git a/xml/htdocs/security/it/bug-searching.xml b/xml/htdocs/security/it/bug-searching.xml new file mode 100644 index 00000000..3ec3b1a1 --- /dev/null +++ b/xml/htdocs/security/it/bug-searching.xml @@ -0,0 +1,184 @@ +<?xml version='1.0' encoding="UTF-8"?> +<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/security/it/bug-searching.xml,v 1.3 2009/10/19 20:47:23 scen Exp $ --> +<!DOCTYPE guide SYSTEM "/dtd/guide.dtd"> + +<guide link="/security/it/bug-searching.xml" lang="it"> +<title>Suggerimenti per la ricerca e l'identificazione di bug di +sicurezza</title> + +<author title="Autore"> + <mail link="klieber@gentoo.org">Kurt Lieber</mail> +</author> +<author title="Autore"> + <mail link="rbu@gentoo.org">Robert Buchholz</mail> +</author> +<author title="Traduzione"> + <mail link="dungeon01@gmail.com">Dungeon01</mail> +</author> +<author title="Traduzione"> + <mail link="scen"/> +</author> + +<abstract> +Questo documento fornisce le linee guida ed i suggerimenti per migliorare +l'identificazione dei bug inerenti alla sicurezza in bugzilla +</abstract> + +<license/> + +<version>1.2</version> +<date>2009-04-14</date> + +<chapter> +<title>Ricerca dei Bug</title> +<section> +<title>Tutti i bug di Sicurezza</title> +<body> + +<p> +Per identificare tutti i bug inerenti alla sicurezza, utilizzare la <uri +link="https://bugs.gentoo.org/query.cgi">pagina</uri> di ricerca di bugzilla, ed +impostare i seguenti campi: +</p> + +<ul> + <li><b>Product:</b> selezionare "Vulnerabilities"</li> + <li> + <b>Status:</b> impostare questo campo con il tipo di bug che si sta cercando + (es.: bug chiusi, bug aperti, etc.) + </li> +</ul> + +<p> +Questo vi darà una lista di tutti i bug aperti nel nostro sistema (o almeno +quelli correttamente assegnati). È possibile impostare la query in modo da +visualizzare solamente le Vulnerabilità ("Vulnerabilities"), problemi del +Kernel ("Kernel issues"), o altri sottoinsiemi dei bug di Sicurezza, impostando +la voce <b>Component</b>. +</p> + +</body> +</section> +<section> +<title>Contrassegnare come "stable" i bug per una determinata architettura +</title> +<body> + +<p> +Quando ad un pacchetto è stata applicata una patch, solitamente questi deve +essere testato prima di venir contrassegnato come stabile per le architetture +interessate. Per identificare tutti i bug dove una architettura necessita di +contrassegnare un pacchetto come stable, utilizzare la pagina di <uri +link="https://bugs.gentoo.org/query.cgi">ricerca</uri> e compilare i seguenti +campi: +</p> + +<ul> + <li><b>Product:</b> selezionare "Gentoo Security"</li> + <li> + <b>Status:</b> impostarlo a "New", "Assigned" o "Reopened" (in pratica: non + cercare i bug che sono già stati chiusi) + </li> + <li> + <b>Email and Numbering:</b> Uno qualunque dei campi "CC list member" + dovrebbe essere impostato a: "contains <arch>@gentoo.org" + </li> +</ul> + +<p> +Quando un pacchetto viene patchato e richiede di essere testato, il Security +Team metterà in CC gli staff di tutte le principali architetture relative a quel +particolare bug e richiederà loro che testino e contrassegnino il pacchetto come +stabile per l'architettura di loro competenza. Quindi, usando il metodo di +ricerca descritto precedentemente, sarà possibile vedere facilmente quali bug +richiedono attenzione per una particolare architettura. +</p> + +<impo> +Per rendere questo rapporto efficace, è molto importante che i team delle varie +architetture si ricordino di rimuoversi dalla lista di cc una volta che il +pacchetto è stato resto stabile. +</impo> + +<note> +Per architetture non supportate, i bug possono essere chiusi senza che il +pacchetto venga segnato come stabile per quella particolare architettura. +Quindi, gli sviluppatori per queste architetture possono voler includere i bug +chiusi nelle loro interrogazioni (per meglio comprendere la differenza fra +"supportato" e "non supportato", si rimanda alla <uri +link="/security/it/vulnerability-policy.xml"> Politica sul trattamento delle +Vulnerabilità</uri>, +</note> + +<p> +I Referenti per la Sicurezza dell'Architettura avranno bisogno di ulteriori +interrogazioni per individuare i bug che richiedono la loro partecipazione. Tali +bug potrebbero essere per esempio classificati come <c>SEMI-PUBLIC</c> i quali +richiedono di essere marcati come stabili nell'albero di Portage, oppure +classificati come <c>CONFIDENTIAL</c>, i quali hanno una fase di test precedente +alla stabilizzazione solamente in Bugzilla. Per ottenere una lista di questi +bug, usare la pagina di <uri +link="https://bugs.gentoo.org/query.cgi">ricerca</uri> ed impostare i campi +seguenti: +</p> + +<ul> + <li><b>Product:</b> selezionare "Gentoo Security"</li> + <li> + <b>Status:</b> impostarlo a "New", "Assigned" e "Reopened" (in pratica: non + cercare i bug che sono già stati chiusi) + </li> + <li> + <b>Email and Numbering:</b> Uno qualunque dei campi "CC list member" + dovrebbe essere impostato a "contains <login>@gentoo.org" dove + <login> è il nome utente Gentoo del Referente. + </li> + <li> + <b>Advanced Searching Using Boolean Charts:</b> "Group" dovrebbe essere + impostato a "is equal to" e il campo di input dovrebbe essere valorizzato a + "Security" + </li> +</ul> + +</body> +</section> +<section> +<title>Interrogazioni su Bugzilla che potrebbero tornare utili</title> +<body> + +<p> +I membri del Team di Sicurezza di Gentoo e i Padawan troveranno molto utili le +seguenti query. Escludendo i falsi positivi, i bug elencati in queste +interrogazioni richiedono l'attenzione del Team di Sicurezza. +</p> + +<ul> + <li> + <uri + link="https://bugs.gentoo.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=Gentoo+Security&component=Auditing&component=Default+Configs&component=GLSA+Errors&component=Kernel&component=Runpath+Issues&component=Vulnerabilities&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=stable&keywords_type=allwords&keywords=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailtype1=regexp&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&query_based_on=stale+stable&negate0=1&field0-0-0=cc&type0-0-0=substring&value0-0-0=amd64%40gentoo.org&negate1=1&field1-0-0=cc&type1-0-0=substring&value1-0-0=x86%40gentoo.org&negate2=1&field2-0-0=cc&type2-0-0=substring&value2-0-0=ppc%40gentoo.org&negate3=1&field3-0-0=cc&type3-0-0=substring&value3-0-0=sparc%40gentoo.org&negate4=1&field4-0-0=cc&type4-0-0=substring&value4-0-0=alpha%40gentoo.org&negate5=1&field5-0-0=cc&type5-0-0=substring&value5-0-0=hppa%40gentoo.org&negate6=1&field6-0-0=cc&type6-0-0=substring&value6-0-0=ppc64%40gentoo.org"> + Stabilizzazione caduta in prescrizione</uri>, visualizza tutti i bug aperti + che hanno "[stable]" nel campo Whiteboard, ma nessuna architettura in CC. + </li> + <li> + <uri + link="https://bugs.gentoo.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=Gentoo+Security&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=glsa%3F&keywords_type=allwords&keywords=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&query_based_on=glsa%3F&field0-0-0=noop&type0-0-0=noop&value0-0-0="> + Voto GLSA</uri>, elenco di bug che sono stati corretti nell'albero di + Portage, ma non hanno ancora una decisione GLSA. + </li> + <li> + <uri + link="https://bugs.gentoo.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=Gentoo+Security&component=Auditing&component=Vulnerabilities&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=notregexp&status_whiteboard=ebuild|upstream|glsa|masked|stable&keywords_type=nowords&keywords=tracker&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&query_based_on=unhandled&field0-0-0=noop&type0-0-0=noop&value0-0-0="> + Bug non gestiti</uri>, bug che sono in uno stato Whiteboard non conosciuto. + </li> + <li> + <uri + link="https://bugs.gentoo.org/buglist.cgi?query_format=advanced&short_desc_type=notregexp&short_desc=CVE&product=Gentoo+Security&component=Auditing&component=Default+Configs&component=GLSA+Errors&component=Kernel&component=Runpath+Issues&component=Vulnerabilities&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=nowords&keywords=Tracker&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&query_based_on=no-cve&field0-0-0=noop&type0-0-0=noop&value0-0-0="> + Nessun CVE</uri>, bug che non includono nessun identificatore CVE nel + proprio titolo. + </li> +</ul> + +</body> +</section> +</chapter> +</guide> diff --git a/xml/htdocs/security/it/coordinator_guide.xml b/xml/htdocs/security/it/coordinator_guide.xml new file mode 100644 index 00000000..a4a06bc6 --- /dev/null +++ b/xml/htdocs/security/it/coordinator_guide.xml @@ -0,0 +1,1377 @@ +<?xml version='1.0' encoding="UTF-8"?> +<!DOCTYPE guide SYSTEM "/dtd/guide.dtd"> +<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/security/it/coordinator_guide.xml,v 1.9 2009/11/08 17:01:24 scen Exp $ --> + +<guide link="/security/it/coordinator_guide.xml" lang="it"> +<title>Guida per il Coordinatore 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="Autore"> + <mail link="vorlon@gentoo.org">Matthias Geerdsen</mail> +</author> +<author title="Autore"> + <mail link="rbu@gentoo.org">Robert Buchholz</mail> +</author> +<author title="Traduzione"> + <mail link="dungeon01@gmail.com">Dungeon01</mail> +</author> +<author title="Traduzione"> + <mail link="luigi.mantellini@gmail.com">Luigi Mantellini</mail> +</author> + +<abstract> +Questo documento contiene le procedure, i suggerimenti e soluzioni utili per il +coordinatore dei GLSA +</abstract> + +<!-- Il contenuto di questo documento è distribuito sotto licenza CC-BY-SA --> +<!--Consultare http://creativecommons.org/licenses/by-sa/1.0 --> +<license/> + +<version>0.8.8</version> +<date>2009-05-09</date> + +<chapter> +<title>Prerequisiti</title> +<section> +<title>Account</title> +<body> + +<p> +Deve essere definito un determinato numero di account prima di lavorare come +coordinatore di GLSA. Per generare un GLSA è necessario ottenere un account <uri +link="https://glsamaker.gentoo.org:4433/">GLSAMaker</uri>. Per gestire bug di +sicurezza bisogna avere un account su <uri +link="https://bugs.gentoo.org">Bugzilla</uri>, aggiornato con privilegi di +<c>editbugs</c>. Per poter inviare un GLSA bisogna avere un indirizzo del tipo +tuonome@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 proprio account di sviluppatore sia abilitata la possibilità +di poter eseguire "commit access" verso la directory GLSA nel CVS repository di +<c>Gentoo</c>. Infine è necessario un nick IRC. Gli sviluppatori Gentoo sono +tenuti a mostrare il proprio nick nel canale #gentoo-security ogni qual volta +siano 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> +A questo punto bisogna creare una chiave GPG per il proprio account email +tuonome@gentoo.org. È possibile generare una chiave specifica o aggiungere +l'indirizzo @gentoo.org ad una chiave già esistente. Successivamente il proprio +key ID dovrebbe <uri link="/proj/en/infrastructure/ldap.xml">impostato in +LDAP</uri>, controllando inoltre che il proprio nome e lo key ID appaiano +nell'<uri link="/proj/en/devrel/roll-call/userinfo.xml">elenco degli +sviluppatori</uri>. È molto importante che la chiave venga pubblicata almeno sul +server delle chiavi <uri +link="http://subkeys.pgp.net:11371">subkeys.pgp.net</uri>, tuttavia la si può +pubblicare anche su altri. +</p> + +</body> +</section> +<section> +<title>Ambiente</title> +<body> + +<p> +Bisogna installare un ambiente CVS sulla propria macchina locale in modo tale da +poter effettuare i commit dei propri GLSA. Ciò viene reso possibile eseguendo il +checkout di una parte del CVS repository di <c>Gentoo</c> verso una directory +data. (per esempio ~/gentoo_cvs): +</p> + +<pre caption="Configurazione 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 inviare messaggi verso le liste dove saranno pubblicate le GLSA, +bisogna iscrivere il proprio account tuonome@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/archive</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> +Ci si può iscrivere ad una versione di tipo digest (raccolta) della +Full-Disclosure. +</note> + +<p> +Come sviluppatori di sicurezza si verrà aggiunti alla lista gentoo-core e al +mailgroup security@gentoo.org. È consigliabile iscriversi anche 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 nella categoria <c>Gentoo Security</c> di +Bugzilla. Se si individua un bug di sicurezza che ha un nome di categoria +errato, si prega di correggerlo 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 alla versione originaria di un +software o bug introdotti nell'impacchettamento degli ebuild di Gentoo. Questi +bug sono riportati nei GLSA. I bug relativi al kernel hanno la loro propria +categoria e non dovrebbero essere archiviati come <c>Vulnerabilità</c> +(vulnerability). +</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 Predefinita</title> +<body> + +<p> +I pacchetti Gentoo dovrebbero avere le impostazioni predefinite più sicure +possibile. I bug che toccano le configurazioni predefinite sono inseriti +quando tali configurazioni, fornita con il pacchetto, possono essere migliorate +in termini di sicurezza. I bug relativi alla <c>Configurazione Predefinita</c> +non generano alcun GLSA. +</p> + +</body> +</section> +<section> +<title>Auditing</title> +<body> + +<p> +Le Vulnerabilità rilevate dagli sviluppatori di Gentoo dovrebbero essere +controllate più volte prima di essere rese note (verso le liste degli +sviluppatori originali del software 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 limitato ("Restricted")</title> +<body> + +<p> +A volte un bug viene comunicato al Team di Sicurezza di Gentoo sotto promessa +di quest'ultimo di mantenerlo segreto fino ad un pubblico rilascio, tipicamente +conosciuta come data d'embargo odata di rilascio coordinato. I bug limitati +hanno la checkbox "Gentoo Security" selezionata, e quindi possono essere +raggiunti solo da membri del Team di Sicurezza di Gentoo. Gli attori esterni (il +manutentore del pacchetto, il tester dell'architettura, Release Engineering) +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" (con limitazioni. ndt). I primi +(e i più segreti) sono i bug <c>CLASSIFIED</c> (classificato, ndt). Un bug è +definito classified quando contiene informazioni che non dovrebbero mai venir +rilasciate. Questo include citazioni di email personali inviate a mailing-list +ristrette 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 a meno che +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 contenenti +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 devono essere inserite nel CVS di +portage. +</p> + +<p> +Il terzo (e meno segreto) tipo di bug "Restricted" è dato dai bug +<c>SEMI-PUBLIC</c> (semipubblico, ndt). I bug semipubblici dovrebbero restare +segreti, ma le patch potrebbero essere inserite 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 originale +del software). +</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 consente al team di Sicurezza 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à, in base alle regole di politica correnti + </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, opzionalmente + </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 in "upstream" (provenienza + originale del software, ndt) una nuova versione o patch + </ti> +</tr> +<tr> + <ti>upstream+</ti> + <ti> + Nessuna risposta dagli sviluppatori originali del software ("upstream") + </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, si prende in considerazione un + aggiornamento 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 team di architettura stanno impiegando troppo tempo per + contrassegnare il pacchetto in manera appropriata + </ti> +</tr> +<tr> + <ti>glsa?</ti> + <ti>Il team di 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> +Sono ammesse le seguenti informazioni aggiuntive: +</p> + +<table> +<tr> + <th>Informazione aggiuntiva</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>(qualsiasi)</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 è +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 in portage, il +bug assume lo stato [stable]. Quando una correzione è presente in 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], si è in attesa della pubblicazione di una versione della +correzione o di una patch decente. Questo stato richiede controlli regolari +degli sviluppatori originali per informazioni: mailing list di sviluppo e +annunci, siti internet, database di 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 viene rilasciata una nuova +patch, il bug entra nello stato [ebuild]. +</p> + +<p> +Se dal ramo di sviluppo originale non v'è reazione né patch alcuna, si entra +nello stato [upstream+]. L'unica opzione consiste nell'applicare una +security-mask al pacchetto vulnerabile 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 keyword masked e/o tempglsa e la severità del bug +impostata ad <c>enhancement</c>. +</p> + +</body> +</section> +<section> +<title>Bug in stato [ebuild]</title> +<body> + +<p> +In stato [ebuild], bisogna identificare il manutentore 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 in portage nella directory relativa del pacchetto, ed il +file Changelog che mostra chi ha effettuato gli ultimi aggiornamenti di +versione. Mettere in cc: il gruppo e/o il mantenitore responsabile del pacchetto +inerente al bug e chiedere che venga fornita un ebuild per la versione della +correzione corrente. Controllare periodicamente che un ebuild non sia stato +inserito in portage senza alcun commento riguardo il bug (a volte accade). +Quando l'ebuild appare, il bug entra in stato [stable] +</p> + +<p> +Se il manutentore non lo rivela, si arriva allo stato [ebuild+]. In casi di +una versione correttiva disponibile, testare se un semplice incremento di +versione funziona (basta rinominare l'ebuild all'ultima versione e farne +l'emerge). Se è disponibile solamente una patch, testare se quest'ultima viene +applicata correttamente. A questo punto trovare un wrangler di bug di sicurezza +con diritti x86 per eseguire l'incremento di versione e segnare l'ebuild ~ per +testarlo. +</p> + +<p> +Se l'incremento 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 la procedura +d'approvazione del security-masking. Il pannello di stato dovrebbe quindi essere +flaggato con le keyword "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], bisogna determinare di quali chiavi l'ebuild fornito +necessita prima che il GLSA venga pubblicato. Ciò può essere ingannevole. +Bisogna considerare ogni versione attualmente presente in portage in modo +che l'ebuild abbia <e>le stesse o più keyword "stable"</e> di qualsiasi altro +pacchetto presente nel portage. Ecco un esempio: +</p> + +<table> +<tr> + <th>Versioni</th> + <th>Keyword</th> +</tr> +<tr> + <ti>Influenzate</ti> + <ti>x86 ~ppc ~ia64</ti> +</tr> +<tr> + <ti>Influenzate</ti> + <ti>x86 ppc</ti> +</tr> +<tr> + <ti>Influenzate</ti> + <ti>~x86 ~ppc ~ia64</ti> +</tr> +<tr> + <ti>La correzione deve avere:</ti> + <th>x86 ppc ~ia64</th> +</tr> +</table> + +<note> +È possibile usare <uri>http://packages.gentoo.org</uri> per aiutarsi nel +determinare le keyword necessarie. Qualora i pacchetti interessati fossero stati +rimossi troppo presto dal manutentore del pacchetto stesso, 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, mettere in CC i team di sviluppo delle varie architetture, chiedendo +loro di contrassegnare l'ebuild come "stable" o ~ di conseguenza. Per +assicurarsi che i team delle architetture prendano in carico il bug, non +dimenticarsi di aggiungere "STABLEREQ" al campo "Keywords" del bug. Gli alias +per le varie architetture sono del tipo 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 da regolamento) sono necessarie prima che il bug +possa avanzare allo stato [glsa]. Controllare periodicamente per verificare se +vi sono nuove keyword nell'ebuild, dato che talvolta 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> +Durante il periodo di preparazione al rilascio si dovrebbe inoltre inserire in +CC Release Engineering (release@gentoo.org) su tutti i bug aventi stato +[stable], +</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 +stabile un pacchetto per problemi non ancora risolti, il bug assume lo stato di +[stable+]. Bisogna rintracciare i mantenitori delle varie architetture affinché +contrassegnino come stabile il pacchetto, e diano supporto nel testing dello +stesso. Bisognerebbe inoltre 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 nel regolamento. +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 nel ramo di sviluppo originale. +</p> + +</body> +</section> +<section> +<title>Bug in stato [glsa]</title> +<body> + +<p> +Nello stato [glsa], il bug di sicurezza è stato corretto. Bisogna pubblicare il +GLSA o semplicemente chiudere il bug senza GLSA. Il regolamento determina in +quali casi un GLSA sia 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 / KEYWORD CRD", 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 politiche correnti + </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, opzionale</ti> + <ti>koon</ti> +</tr> +<tr> + <ti>KEYWORD</ti> + <ti> + Il livello confidenziale del bug, può essere CLASSIFIED, CONFIDENTIAL, + SEMI-PUBLIC + </ti> + <ti>CLASSIFIED</ti> +</tr> +<tr> + <ti>CRD</ti> + <ti> + La data di rilascio coordinato per la rivelazione dei bug. Se non viene + fornito un'orario, prendere come riferimento 14.00 UTC + </ti> + <ti>2009-01-06 18:00 UTC</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 mantenitore del pacchetto specifico è stato chiamato a preparare + un'ebuild che non deve essere inserita nel tree del CVS, ma allegata al bug + </ti> +</tr> +<tr> + <ti>prestable</ti> + <ti> + I collaudatori di una specifica architettura sono stati chiamati a testare + 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 e i +file per correggere la vulnerabilità NON dovrebbero essere aggiunti al CVS del +portage, e nessun aspetto di quei bug dovrebbe essere discusso in pubblico. +Patch o archivi tarball provenienti da overlay di portage possono comunque +essere allegati al bug. I collaudatori dovranno installare il proprio overlay +per testarlo. L'idea con questi bug è di preparare l'ebuild e farlo testare +entro la data di rilascio concordata, in modo tale da poterlo 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>Preparare bozze di 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 di pacchetto 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 copiare nessuna parte di una descrizione già esistente, ma utilizzarle come +fonti d'informazione per il GLSA. Se viene copiato, per esempio, una descrizione +di un software da un sito internet, si prega di utilizzare 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'identificare chiaramente la vulnerabilità senza entrare nei dettagli. La +versione dovrebbe essere omessa, tranne nei rari casi in cui sia 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à. Gli esempi includono: +</p> + +<table> +<tr> + <ti> + Due utilità MySQL creano file temporanei con percorsi fissi, consentendo + ad un attaccante di utilizzare un collegamento simbolico per ingannare MySQL + nel sovrascrivere dati importanti. + </ti> +</tr> +<tr> + <ti> + Sono stati rilevati vulnerabilità multiple, inclusi buffer overflow + eseguibili da remoto, nel codice comune tra Mplayer e la libreria xine + </ti> +</tr> +</table> + +<p> +La categoria delle keyword 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 eseguire uno script per elevare i privilegi, oppure accedere ad una +directory temporanea per far partire un attacco tramite collegamento simbolico. +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 severità è un'indicazione di quanto in profondità arrivi la vulnerabilità. +Viene definita nella Vulnerability Treatment Policy, nella tabella "Evaluate the +vulnerability type". Si noti che dipende solo dal massimo rischio, non al +fattore comune della configurazione delle opzioni al rischio. Un buffer overflow +che consenta l'esecuzione di codice arbitrario 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 severità "Normale". In rari casi la severità 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 severità +"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. 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", inserire "*" +quando la descrizione della versione si applica a tutte le architetture +contrassegnate nell'ebuild. 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 pacchetto è 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, usare ">= prima +versione corretta" come inalterata e "<= ultima versione colpita" come +vulnerabile. Controllare più volte che non esista un'ebuild fra l'ultima +versione colpita e la prima versione corretta. Qualora ci si trovasse in dubbio, +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. Si propone 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, omettere +l'opzione "inalterato" (unaffected) per quel pacchetto ed impostare "Auto" a +"no". +</p> + +<impo> +Quando le versioni delle correzioni sono complesse, controllare più volte che le +versioni XML e TXT del GLSA elenchino correttamente le proprie 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 si include: +</p> + +<table> +<tr> + <ti> + Il K Desktop Environment (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 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 lasciare la descrizione +breve. Tra i buoni esempi si include: +</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 sovrascritti 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 reports. 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 + (in questo esempio, /etc/passwd). Una vulnerabilità simile esiste con la + mysql_multi utility, 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 in modo arbitrario 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> + Questa vulnerabilità ha due possibili effetti. In primo luogo, può generare + nuovi file nella home directory dell'utente. In secondo luogo, e molto più + pericolosao, 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 un qualsiasi maniera semplice (tranne +l'aggiornamento alla versione correttiva) 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 + -- no-kerberos4. + </ti> +</tr> +<tr> + <ti>Ad oggi non esistono workaround conosciuti.</ti> +</tr> +</table> + +<p> +La sezione "Risoluzione" spiega in termini umanamente comprensibili che cosa +bisogna fare per essere completamente protetti dalla vulnerabilità. Questa +sezione deve assomigliare a quanto segue: +</p> + +<pre caption="Esempio di risoluzione"> +Tutti gli utenti di Heimdal dovrebbero effettuare l'aggiornamento 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 per architetture multiple"> +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, includere il seguente paragrafo +all'estremità della sezione "risoluzione" per avvisare circa la necessità di +effettuare la ricompilazione 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 CVE +completo nel Titolo, "Title"). Si può anche collegare un advisory di uno +sviluppatore originale e/o un'email di annuncio, quando disponibili. Evitare +link ad advisory di altre distribuzioni o advisory non ufficiali provenienti da +entità esterne. +</p> + +</body> +</section> +</chapter> +<chapter> +<title>Pubblicazione GLSA</title> +<section> +<title>Revisione tra colleghi</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> + Versioni 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 fare 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-vulnerabilità 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> +Bisogna effettuare il commit del GLSA XML nell'albero del CVS di Gentoo in modo +che compaia automaticamente nella gestione del feed RDF, nella lista dei GLSA e +negli aggiornamenti di portage. Aggiornare in primo luogo la propria directory +GLSA nel tree del repository gentoo CVS: +</p> + +<pre caption="Aggiornamento albero 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 cliccare <c>Fetch</c> nel GLSA per scaricare la versione XML, +e salvarla nella propria directory +gentoo_cvs/gentoo/xml/htdocs/security/en/glsa/ . A questo punto 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>Annuncio via E-mail</title> +<body> + +<warn> +Ogni volta che viene utilizzata una nuova installazione (software o macchina) +per inviare un annuncio GLSA, assicurarsi che il proprio 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 a +posto, quindi preparare una mail con le seguenti regole: +</p> + +<ul> + <li> + <b>Da </b> e<b>Indirizzo di Ritorno</b> devono essere impostati a + tuonome@gentoo.org + </li> + <li> + <b>To</b> e<b>Cc</b> dovrebbero essere configurati secondo regolamento + </li> + <li> + <b>Oggetto</b> deve essere "[ GLSA XXXXYY-ZZ ] la propria vulnerabilità qui" + (copiare/incollare dal titolo nel file di testo) + </li> + <li> + Il corpo della mail dovrebbe corrispondere al contenuto del file di testo, + dall'intestazione "Gentoo Linux Security Advisory" alla fine del file + </li> + <li> + L'email deve essere firmata dalla chiave GPG per l'indirizzo + tuonome@gentoo.org + </li> +</ul> + +<note> +Si riceverà un'email di ritorno da gentoo-announce dicendo che è richiesta +moderazione. Basta rispondere a questa mail e l'email di annuncio +precedentemente menzionata arriverà a destinazione. +</note> + +</body> +</section> +<section> +<title>Chiusura dei bug</title> +<body> + +<p> +Controllare che la mail sia arrivata a gentoo-announce, poi è possibile chiudere +i(l) bug relativo, regolando la condizione a <b>RESOLVED/FIXED</b>, con un +commento indicante il numero di GLSA. +</p> + +</body> +</section> +<section> +<title>Pubblicazione Errata/Aggiornamenti</title> +<body> + +<p> +Un errata viene pubblicato quando viene commesso un errore, altrimenti si sta +parlando di un aggiornamento. Quando la politica 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 si effettuano 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 politica 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_59c7b7e81a7acacb1cbde24ab708f07a.xml"> +ERRATA: [GLSA 200409-14 ] Samba: Remote printing non-vulnerability</uri> (dove +non sono presenti reali vulnerabilità) e <uri +link="http://archives.gentoo.org/gentoo-announce/msg_e75f5d493fea7c6f718a850abd59598a.xml"> +ERRATA: [GLSA 200801-09 ] X.Org X server and Xfont library: Multiple vulnerabilities</uri> +(dove i problemi non sono risolti correttamente nella prima versione). Per un +aggiornamento si veda <uri +link="http://archives.gentoo.org/gentoo-announce/msg_0f18bca197c64b634db757a18d2ae492.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>Strumenti per i Coordinatori GLSA</title> +<section> +<title>Raccolta delle Informazioni</title> +<body> + +<ul> + <li> + <uri link="http://dev.gentoo.org/~vorlon/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/~falco/glsacommit.txt">glsacommit</uri> è + una funzione bash che si occupa delle gestione del commit dei GLSA. + Caratterizzato dall'ssh-agent keyadding, glsa-check controlla più volte la + conformità ed ha delle funzioni "Sei sicuro?". Modificarlo per soddisfare le + proprie necessità e le posizioni delle directory. + </li> +</ul> + +</body> +</section> +<section> +<title>Security Subversion repository</title> +<body> + +<ul> + <li> + Il <uri link="http://overlays.gentoo.org/proj/security/timeline">Repository + Subversion Sicurezza</uri> contiene diversi strumenti per valutare in modo + collaborativo se Gentoo è affetta da nuovi identificatori CVE, e strumenti + per determinare le keywords di destinazione. Molti strumenti interagiscono + direttamente con Bugzilla, rendendo non necessari i copia-incolla manuali. + </li> +</ul> + +</body> +</section> +</chapter> +</guide> diff --git a/xml/htdocs/security/it/index.xml b/xml/htdocs/security/it/index.xml new file mode 100644 index 00000000..35188aae --- /dev/null +++ b/xml/htdocs/security/it/index.xml @@ -0,0 +1,277 @@ +<?xml version='1.0' encoding="UTF-8"?> +<!DOCTYPE guide SYSTEM "/dtd/guide.dtd"> +<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/security/it/index.xml,v 1.4 2009/07/02 22:02:53 scen Exp $ --> + +<guide link="/security/it/index.xml" lang="it"> +<title>La sicurezza in Gentoo Linux</title> + +<author title="Autore"> + <mail link="solar@gentoo.org">Ned Ludd</mail> +</author> +<author title="Autore"> + <mail link="klieber@gentoo.org">Kurt Lieber</mail> +</author> +<author title="Autore"> + <mail link="koon@gentoo.org">Thierry Carrez</mail> +</author> +<author title="Traduzione"> + <mail link="walpis@yahoo.it">Walter Pisani</mail> +</author> +<author title="Traduzione"> + <mail link="scen@gentoo.org">Davide Cendron</mail> +</author> + +<abstract> +Questa pagina è il punto di inizio per tutti i problemi di sicurezza in Gentoo +Linux +</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>2.3</version> +<date>2009-04-14</date> + +<chapter> +<title>La sicurezza in Gentoo Linux</title> +<section> +<body> + +<p> +La sicurezza è un punto principale in Gentoo Linux e garantire riservatezza e +sicurezza alle proprie macchine è di massima importanza. Il <uri +link="/proj/en/security/">Gentoo Linux Security Project</uri> ha il compito di +fornire tempestivamente informazioni sulle vulnerabilità di sicurezza in Gentoo +Linux, insieme alle patch per risolvere le vulnerabilità. I membri di q +uesto progetto lavorano direttamente con i venditori, utenti finali e altri +progetti OSS per garantire che tutti gli incidenti di sicurezza siano gestiti +con velocità e professionalità. +</p> + +<p> +È possibile trovare un documento che descrive le politiche del team di sicurezza +che segue la gestione delle vulnerabilità trovate nella distribuzione Gentoo +Linux alla pagina <uri link="/security/it/vulnerability-policy.xml">Politiche di +gestione delle vulnerabilità</uri>. +</p> + +</body> +</section> +<section> +<title>Installare un sistema Gentoo sicuro</title> +<body> + +<p> +Il <uri link="/doc/it/security/">Manuale sulla sicurezza per Gentoo</uri> offre +informazioni e consigli per costruire un sistema sicuro e rafforzare un sistema +esistente. +</p> + +</body> +</section> +<section> +<title>Mantenere il proprio sistema Gentoo sicuro</title> +<body> + +<p> +Per essere aggiornati con le fix di sicurezza bisogna richiedere la ricezione +delle GLSA e applicare le instruzioni GLSA ogniqualvolta si abbia un pacchetto +affetto installato. In alternativa, sincronizzare il proprio portage tree e +aggiornare ogni pacchetto dovrebbe mantenere aggiornata la sicurezza. +</p> + +<p> +L'integrazione dei soli aggiornamenti di sicurezza negli strumenti di Portage +è in preparazione. In questo momento, si può provare lo strumento +<c>glsa-check</c> sperimentale (parte del pacchetto <e>gentoolkit</e>) che +controlla se le specifiche GLSA sono applicate sul proprio sistema (opzione +<c>-p</c>), elenca tutte le GLSA con lo stato applicato/affetto/non affetto +(opzione <c>-l</c>) o applica determinate GLSA al proprio sistema (opzione +<c>-f</c>). +</p> + +</body> +</section> +</chapter> +<chapter> +<title>Gentoo Linux Security Announcements (GLSA)</title> +<section> +<body> + +<p> +Gentoo Linux Security Announcements (ndT Annunci di Sicurezza Gentoo Linux) sono +avvisi inviati alla comunità per informare sulle vulnerabilità di sicurezza +relative a Gentoo Linux o sui pacchetti contenuti nell'insieme dei pacchetti di +Portage. +</p> + +</body> +</section> +<section> +<title>Consultazioni Recenti</title> +<body> + +<glsa-latest/> + +<p>Per la lista di tutte le pubblicazioni GLSA, visitare <uri +link="/security/en/glsa/index.xml">la pagine con l'indice delle GLSA</uri>. +</p> + +</body> +</section> +<section> +<title>Come ricevere le GLSA</title> +<body> + +<p> +Gli avvisi GLSA sono inviati alla <uri +link="/main/it/lists.xml">mailing-list gentoo-announce@gentoo.org</uri>, e l'RDF +è disponibile a <uri +link="/rdf/en/glsa-index.rdf">http://www.gentoo.org/rdf/en/glsa-index.rdf</uri>. +</p> + +</body> +</section> +</chapter> + +<chapter> +<title>Informazione di contatto del team di sicurezza</title> +<section> +<body> + +<p> +Gentoo Linux prende molto seriamente i rapporti delle vulnerabilità di +sicurezza. Si prega di registrare i nuovi rapporti di vulnerabilità su <uri +link="https://bugs.gentoo.org">Gentoo Bugzilla</uri>, assegnarli al prodotto +<e>Gentoo Security</e> e al componente <e>Vulnerabilities</e> . Cliccare <uri +link="https://bugs.gentoo.org/enter_bug.cgi?product=Gentoo%20Security&component=Vulnerabilities"> +qui</uri> per inviare direttamente una nuova vulnerabilità di sicurezza. Il Team +di sicurezza di Gentoo Linux assicura che tutti i rapporti di bug relativi alla +sicurezza saranno gestiti in maniera opportuna. +</p> + +<p> +Se vengono trovati errori o omissioni nelle pubblicazioni delle GLSA, bisogna +registrare un bug in <uri link="https://bugs.gentoo.org">Gentoo Bugzilla</uri> +nel prodotto <e>Gentoo Security</e> , ma con il componente <e>GLSA Errors</e>. +Cliccare <uri +link="https://bugs.gentoo.org/enter_bug.cgi?product=Gentoo%20Security&component=GLSA%20Errors"> +qui</uri> per inviare direttamente un nuovo GLSA bug. +</p> + +</body> +</section> +<section> +<title>Contatti Confidenziali</title> +<body> + +<p> +Ci sono due opzioni per inviare una vulnerabilità non pubblica al Team di +Sicurezza di Gentoo Linux. Si può inviare un bug tramite <uri +link="https://bugs.gentoo.org/">Gentoo Bugzilla</uri> usando l'azione +<e>New-Expert</e> e selezionando il checkbox <e>Gentoo Security</e> nella +sezione <e>SOnly users in all of the selected groups can view this bug</e>. È +anche possibile contattarli direttamente usando una mail criptata ad uno dei +seguenti contatti di sicurezza: +</p> + +<table> +<tr> + <th>Nome</th> + <th>Responsabilità</th> + <th>Email</th> + <th>GPG keyID (cliccare per recuperare la chiave pubblica)</th> +</tr> +<tr> + <ti>Robert Buchholz</ti> + <ti>Co-responsabile operativo</ti> + <ti><mail link="rbu@gentoo.org">rbu@gentoo.org</mail></ti> + <ti> + <uri + link="http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCE7E8339"> + 0xCE7E8339</uri> + </ti> +</tr> + <tr> + <ti>Pierre-Yves Rofes</ti> + <ti>Co-responsabile operativo</ti> + <ti><mail link="py@gentoo.org">py@gentoo.org</mail></ti> + <ti> + <uri + link="http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0x320A2398"> + 0x320A2398</uri> + </ti> +</tr> +</table> + +<note> +La lista completa di tutti gli sviluppatori di Gentoo, inclusa la chiave +GPG ID, è consultabile nella <uri +link="/proj/en/devrel/roll-call/userinfo.xml">lista degli sviluppatori +attivi</uri> +</note> + +</body> +</section> +</chapter> + +<chapter> +<title>Risorse</title> +<section> +<title>Pagine di sicurezza</title> +<body> + +<ul> + <li> + <uri link="/security/en/glsa/index.xml">Indice delle GLSA</uri> -- Lista di + tutte le pubblicazioni GLSA + </li> + <li> + <uri link="/rdf/en/glsa-index.rdf">GLSA RDFfeed</uri> -- GLSA RDF live + feed. È possibile limitare il numero di GLSA accodando "?num=n" all'URL, + dove "n" dev'essere sostituito con il numero di voce desiderate. Per esempio + <uri + link="http://www.gentoo.org/rdf/en/glsa-index.rdf?num=20">http://www.gentoo. + org/rdf/en/glsa-index.rdf?num=20</uri> elencherà le ultime 20 GLSA. + </li> + <li> + <uri link="/security/it/vulnerability-policy.xml">Politiche di gestione + delle vulnerabilità</uri> -- Le politiche ufficiali del Team di sicurezza + </li> + <li> + <uri link="/proj/en/security/">Gentoo Linux Security Project</uri> -- La + pagina del progetto di sicurezza + </li> +</ul> + +</body> +</section> +<section> +<title>Links</title> +<body> + +<ul> + <li> + <uri link="/doc/it/security/">Manuale sulla sicurezza per Gentoo</uri> -- + Guida passo passo per rafforzare Gentoo Linux + </li> + <li> + <uri link="/proj/en/hardened/">Gentoo Hardened Project</uri> -- Sicurezza + avanzata in Gentoo Linux + </li> + <li> + <uri link="/proj/en/server/">Gentoo Server Project</uri> -- Mettere a fuoco + specifici problemi di un server, come la sicurezza e la stabilità + </li> + <li> + <uri link="/proj/en/devrel/roll-call/userinfo.xml">Lista Sviluppatori + attivi</uri> -- Lista dei sviluppatori attivi, incluse le chiavi GPG che + possono essere usate per verificare le GLSA + </li> +</ul> + +</body> +</section> +</chapter> +</guide> diff --git a/xml/htdocs/security/it/padawans.xml b/xml/htdocs/security/it/padawans.xml new file mode 100644 index 00000000..ecdf9c79 --- /dev/null +++ b/xml/htdocs/security/it/padawans.xml @@ -0,0 +1,345 @@ +<?xml version='1.0' encoding="UTF-8"?> +<!DOCTYPE guide SYSTEM "/dtd/guide.dtd"> +<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/security/it/padawans.xml,v 1.11 2010/05/04 20:18:22 scen Exp $ --> + +<guide link="/security/it/padawans.xml" lang="it"> +<title>Processo e stato dei Security Padawans</title> + +<author title="Autore"> + <mail link="koon@gentoo.org">Thierry Carrez</mail> +</author> +<author title="Autore"> + <mail link="dercorny@gentoo.org">Stefan Cornelius</mail> +</author> +<author title="Autore"> + <mail link="falco@gentoo.org">Raphael Marichez</mail> +</author> +<author title="Autore"> + <mail link="rbu@gentoo.org">Robert Buchholz</mail> +</author> +<author title="Traduzione"> + <mail link="luigi.mantellini@idf-hit.com">Luigi 'Comio' Mantellini</mail> +</author> +<author title="Traduzione"> + <mail link="zanetti.massimo@gmail.com">Massimo Zanetti</mail> +</author> + +<abstract> +Questo documento descrive le procedure che si applicano al processo di +reclutamento del team di sicurezza e l'attuale stato di reclutamento. +</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.3.8</version> +<date>2009-04-14</date> + +<chapter> +<title>Reclute Progetto Sicurezza</title> +<section> +<title>Padawan</title> +<body> + +<p> +Il processo di reclutamento nel gruppo di sviluppatori di sicurezza è differente +dal processo principale di reclutamento. La conoscenza delle specificità di +Gentoo non è così importante come potrebbe esserlo per altri tipi di +sviluppatore, dato che non saranno necessari i permessi di commit sul Portage +tree. Detto in altre parole, è necessario possedere un buon background in ambito +di sicurezza, buona conoscenza del'inglese scritto e si avranno progressivamente +maggiori responsabilità.. +</p> + +<p> +Tutto il processo di reclutamento può estendersi da 2 a 3 mesi, in funzione +delle capacità e conoscenze personali e dal tempo che si decide di investire nel +progetto. Parlando proprio del tempo: la maggior parte delle attività che +dovranno essere svolte coinvolgono meno di 10 minuti, ma bisogna poter reagire +ai problemi con una bassa latenza. Perciò, la dedizione costante è più +importante dell'avere grandi quantità di tempo libero. Le reclute del gruppo +sicurezza in addestramento saranno chiamate all'interno di questo documento come +<b>padawan</b>. +</p> + +</body> +</section> +<section> +<title>Stato corrente dei padawan</title> +<body> + +<table> +<tr> + <th>Nome del Padawan</th> + <th>Nome utente</th> + <th>Livello</th> + <th>Mentore</th> +</tr> +<!-- inactive (vorlon 2008-07-04) +<tr> +<ti>NeilK</ti> +<ti>mu-b</ti> +<ti>Scout</ti> +</tr> +--> +<tr> +<ti>Tomás Touceda</ti> +<ti>chiiph</ti> +<ti>Allievo</ti> +<ti>keytoaster</ti> +</tr> + +<tr> +<ti>Tony Vroon</ti> +<ti>Chainsaw</ti> +<ti>Allievo</ti> +<ti>a3li</ti> +</tr> + +<!-- inactive, rbu 2009-04-14<tr> +<ti>Emanuele Gentili</ti> +<ti>emgent</ti> +<ti>Scout</ti> +<ti>none yet</ti> +</tr>--> +<!-- nactive, a3li 2009-11-06<tr> +<ti>Lars Hartmann</ti> +<ti>psychoschlumpf</ti> +<ti>Allievo</ti> +<ti>attualmente nessuno</ti> +</tr> +--> +<tr> +<ti>Matti Bickel</ti> +<ti>mabi</ti> +<ti>allievo</ti> +<ti>attualmente nessuno</ti> +</tr> +<!-- inactive (vorlon 2008-07-04) +<tr> +<ti>Jule Slootbeek</ti> +<ti>dizzutch</ti> +<ti>Apprentice</ti> +</tr> +--> +<!-- inactive (vorlon 2008-07-04) +<tr> +<ti>Adir Abraham</ti> +<ti>adir</ti> +<ti>Apprentice</ti> +</tr> +--> +</table> + +<note> +Gli sviluppatori ed gli sviluppatori senior compaiono sulla pagina del <uri +link="/proj/en/security/index.xml">Progetto Sicurezza</uri>. +</note> + +</body> +</section> +</chapter> + +<chapter> +<title>Fasi del reclutamento</title> +<section> +<body> + +<p> +Per diventare un padawan, bisogna inviare una richiesta contenente informazioni +riguardanti le proprie conoscenze e qualifiche all'indirizzo <mail +link="security@gentoo.org">security@gentoo.org</mail> e collegarsi al canale IRC +#gentoo-security per avere una idea di come sono svolte le attività. È possibile +leggere la guida <uri link="/security/it/coordinator_guide.xml">Coordinatore +GLSA</uri> e se si è interessati al lavoro si può iniziare come uno Scout (ndt, +sentinella). +</p> + +</body> +</section> +<section> +<title>Scout</title> +<body> + +<p> +Il primo passo nell'adesione al team è quello di essere uno scout. Si dovranno +seguire le principali liste di discussione in materia di sicurezza e siti (a +a scelta) sottomettendo bug non ancora elencati in <uri +link="https://bugs.gentoo.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=Gentoo+Security&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0="> +Bug di Sicurezza correnti</uri>. È consigliabile ricercare eventuali bug +duplicati prima di sottometterne uno. Uno sviluppatore senior sarà assegnato +come proprio 'Mentore'. Lui sarà una guida rispondendo alle proprie domande +(comunque, non si esiti a contattare ulteriori sviluppatori senior per ulteriore +aiuto). È comunque saggio aggiunge la lista security@gentoo.org a quelle +monitorate. Per fare questo, è sufficiente aprire le impostazioni del proprio +account bugzilla, andare alla voce "Email Preferences" ed aggiungere +security@gentoo.org nel box in basso. Fatto questo, ogni email inviata +all'indirizzo security@gentoo.org, sarà recapitata al proprio indirizzo ad +eccezione di quelle con restrizioni. Questo aiuterà a rimanere aggiornati. +</p> + +<p> +Oltre a compilare nuovi bug report di sicurezza, si è invitati a trovarne una +eventuale soluzione ad essi (mettendo in CC i maintainer, modificando lo stato +del bug come descritto nella guida al Coordinatore GLSA). Sfortunatamente, +questo è permesso solo sui propri bug report. Si sarà autorizzati a modificare e +muovere altri bug report quando si diventerà uno sviluppatore in prova +(developer on probation). +</p> + +<p> +Cercare bug di sicurezza può essere molto difficoltoso e noioso, come un lavoro +da schiavo. Ci sono diversi modi per rendersi la vita più facile. Alcuni canali +principali, come Full-Disclosure, hanno un rateo segnale/rumore piuttosto basso, +ma ci sono anche altre <uri +link="http://oss-security.openwall.org/wiki/mailing-lists">mailing list</uri> +come oss-security che sono piu incentrate su venditori di distribuzioni. +Potreste anche essere interessati a canali secondari, ad esempio ci si puo +iscrivere a <uri link="https://secunia.com/advisories/">Secunia Advisories</uri> +attraverso una mailing list, o <uri +link="http://www.securityfocus.com/bid">BugTraq BIDs</uri> e <uri +link="http://cve.mitre.org/">CVE identifiers</uri> possono essere seguiti +tramite i feed RSS. Si possono trovare anche mezzi per gestire agilmente +identificativi CVE appena assegnati ed eseguire altri compiti di routine al link +<uri link="http://overlays.gentoo.org/proj/security/timeline">Security +SVN</uri>. Si prega di consultare il file README lì disponibile. +</p> + +<p> +InoltreÈ è possibile anche provare a trovare altre attività di proprio +interesse, come ad esempio aiutare altri sviluppatori che sono in ritardo con la +pacchettizzazione di ebuild e/o stabilizzando o verificando una vulnerabilità +dove non è sicuro se Gentoo ne sia affetta o meno. È possibile provare a +chiedere al proprio mentore per eventuali altre attività. +</p> + +<ul> + <li> + Si avrà bisogno di: un account su <uri + link="https://bugs.gentoo.org/createaccount.cgi">Gentoo bugzilla</uri> + </li> + <li>Verrà fornito: Nulla</li> + <li> + Tempo stimato per la promozione: da due settimane ad un mese, in funzione + dalle capacità ed abilità personali. + </li> +</ul> + +<note> +Sapete come cercare un bug tramite un identificatore CVE nel Bug tracker di +altre distribuzioni? Se no, trovatelo o chiedete al vostro mentore. +</note> + +</body> +</section> +<section> +<title>Allievo/Apprendista</title> +<body> + +<p> +Se si è fatto un buon lavoro come scout, si sarà invitati a diventare un +apprentice (ndt, allievo/apprendista), venendo aggiunti allo strumento segreto +chiamato 'GLSAMaker'. Si dovrà rispondere a bozze, commenti e revisioni di +avvisi di sicurezza. Si sarà anche responsabili della correzione di avvisi +abbozzati nel minor tempo possibile. Inoltre si dovrebbe comunque mantenere le +attività di scout. Abbozzare GLSA è solitamente più rilassante che andare a +caccia di bug, rendendo a questo punto più divertente iniziare il proprio +lavoro. +</p> + +<ul> + <li> + Si avrà bisogno di: Imparare le <uri + link="/security/it/vulnerability-policy.xml">Politiche di gestione delle + vulnerabilità in Gentoo Linux</uri> e la <uri + link="/security/it/coordinator_guide.xml">Guida Coordinatore GLSA</uri> + con cura + </li> + <li>Verrà fornito: Un account GLSAMaker</li> + <li> + Tempo stimato per la promozione: finché non si sarà confidenti sulle + capacità di abbozzare un avviso di sicurezza di qualità. Potrebbe prendere + intorno ad un mese se si è buoni. + </li> +</ul> + +<note> +Avete gia' letto piu' di una pagina su <uri +link="http://oss-security.openwall.org/wiki/">oss-security wiki</uri>? +</note> + +</body> +</section> +<section> +<title>Sviluppatore (in prova)</title> +<body> + +<p> +GLSA significativi e dedizione permettono di accedere alla fase successiva. +Verrà aperto dal team di sicurezza un bug di reclutamento permettendo di +attenere la magica potenza di poter modificare e muovere bug compilati da altri. +Verrà avviato un periodo di prova di 30 giorni in cui bisognerà rispondere +correttamente a quiz per poter diventare uno sviluppatore a pieno titolo. +Durante il periodo di prova, sarà necessario usare le nuove responsabilità, +dimostrando di essere pronti per gestire le stesse. +</p> + +<ul> + <li> + Si avrà bisogno di: tutto quello richiesto per diventare uno sviluppatore + Gentoo + </li> + <li> + Verrà fornito: Un account di sviluppatore Gentoo, adesione a + security@gentoo.org e diritti potenziati sul bugzilla + </li> + <li>Tempo stimato per la promozione: 30 giorni.</li> +</ul> + +</body> +</section> +<section> +<title>Sviluppatore</title> +<body> + +<p> +Alla fine del periodo di prova, si diventerà un Coordinatore GLSA a pieno titolo +potendo inviare e confermare i propri GLSA. Gloria e fama saranno con voi. +</p> + +<ul> + <li>Vi serviranno: Lacrime e sudore</li> + <li> + Vi forniremo: Diritti di commit GLSA, diritti di invio di gentoo-announce, + adesione al gruppo www_glsamaker, potere di approvazione di padawan + </li> +</ul> + +</body> +</section> +<section> +<title>Sviluppatore di sicurezza senior</title> +<body> + +<p> +Per raggiungere il santo graal del percorso di padawan ed avere infiniti poteri, +si dovrà passare attraverso i classici quiz per sviluppatori per guadagnare i +diritti di commit sul CVS del portage. Si dovrà dimostrare di non avere altra +vita fuori dal canale #gentoo-security. Quindi si avrà il potere di mascherare +eventualmente gli ebuild. +</p> + +<ul> + <li> + Si avrà bisogno di: superare con successo i quiz per sviluppatore Gentoo + </li> + <li> + Verrà fornito: Diritti di commit sul Portage per mascherare i pacchetti + </li> +</ul> + +</body> +</section> +</chapter> +</guide> diff --git a/xml/htdocs/security/it/vulnerability-policy.xml b/xml/htdocs/security/it/vulnerability-policy.xml new file mode 100644 index 00000000..18cbd182 --- /dev/null +++ b/xml/htdocs/security/it/vulnerability-policy.xml @@ -0,0 +1,831 @@ +<?xml version='1.0' encoding="UTF-8"?> +<!DOCTYPE guide SYSTEM "/dtd/guide.dtd"> +<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/security/it/vulnerability-policy.xml,v 1.6 2009/05/28 20:05:48 scen Exp $ --> + +<guide link="/security/it/vulnerability-policy.xml" lang="it"> +<title>Politiche di gestione delle vulnerabilità in Gentoo Linux</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="Autore"> + <mail link="vorlon@gentoo.org">Matthias Geerdsen</mail> +</author> +<author title="Autore"> + <mail link="rbu@gentoo.org">Robert Buchholz</mail> +</author> +<author title="Traduzione"> + <mail link="walpis@yahoo.it">Walter Pisani</mail> +</author> +<author title="Traduzione"> + <mail link="scen@gentoo.org">Davide Cendron</mail> +</author> + +<abstract> +Questo documento descrive le politiche usate in Gentoo Linux per gestire le +vulnerabilità scoperte nei pacchetti resi disponibili agli utenti. +</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>1.2.7</version> +<date>2009-04-14</date> + +<chapter> +<title>Scopo</title> +<section> +<title>Architetture supportate</title> +<body> + +<p> +Gentoo Linux è offerto sulle principali differenti architetture. Alcune di +queste architetture hanno più sviluppatori di altre, e di fatto rispondono alle +nuove vulnerabilità di sicurezza più velocemente. Mentre l'obiettivo finale del +Progetto Sicurezza di Gentoo è di garantire che tutte le architetture ricevano +le correzioni di sicurezza simultaneamente, bisogna anche bilanciare +questo obbiettivo con l'obbiettivo di rilasciare le correzioni di sicurezza e le +GLSA il più velocemente possibile in modo che la maggioranza degli utenti siano +informati e protetti. +</p> + +<p> +Per questa ragione, il team di sicurezza ha separato le architetture Gentoo in +due gruppi, <b>supportate</b> e <b>non supportate</b>: +</p> + +<ul> + <li> + <b>Supportate:</b> Queste architetture devono avere una correzione stabile + applicata prima che la GLSA possa essere rilasciata + </li> + <li> + <b>Non supportate:</b> A queste architetture saranno notificate nuove + vulnerabilità (cc sui relativi bugs), Tuttavia, non si attenderà una + correzione stabile su queste architetture prima di pubblicare la GLSA e + chiudere il bug + </li> +</ul> + +<p> +Questa è la lista delle architetture attualmente supportate: +</p> + +<table> +<tr> + <th>Architetture supportate (in ordine alfabetico)</th> +</tr> +<tr> + <ti>alpha</ti> +</tr> +<tr> + <ti>amd64</ti> +</tr> +<tr> + <ti>hppa</ti> +</tr> +<tr> + <ti>ppc</ti> +</tr> +<tr> + <ti>ppc64</ti> +</tr> +<tr> + <ti>sparc</ti> +</tr> +<tr> + <ti>x86</ti> +</tr> +</table> + +<p> +Tutte le architetture sono benvenute e incoraggiate a diventare una +architettura supportata. Ci sono due semplici criteri che bisogna seguire per +essere ufficialmente supportati dal Progetto Sicurezza di Gentoo: +</p> + +<ul> + <li> + Designare uno sviluppatore come punto principale di contatto per le + pubblicazioni sulla sicurezza (Referente per la Sicurezza dell'Architettura) + relative alla sua architettura. Questa persona ha la responsabilità di + garantire che i bug di sicurezza siano adeguatamente risolti sulla loro + particolare architettura + </li> + <li> + Aderire all'osservanza delle scadenze pubblicate per i test e la marcatura + di stabilità dei pacchetti + </li> +</ul> + +</body> +</section> +<section> +<title>Release Engineering</title> +<body> + +<p> +Il Progetto Release Engineering ("releng") nomina uno sviluppatore a contatto +principale per i problemi di sicurezza. +</p> + +<p> +Release Engineering informata il Progetto Sicurezza di Gentoo quando viene +fatto un primo snapshot dell'albero per i supporti dei rilasci. Iniziando con +il primo snapshot fino al supporto ufficiale del rilascio ("periodo di +preparazione al rilascio"), Release Engineering (l'incaricato per la sicurezza +in caso di problemi confidenziali) dovrebbe essere inserito in CC per ciascun +bug di sicurezza che entra nella fase di stabilizzazione. +</p> + +</body> +</section> +<section> +<title>Kernel</title> +<body> + +<p> +Attualmente i kernel non sono coperti dal processo di rilascio delle GLSA. Le +vulnerabilità devono ancora essere riportate e verranno corrette, ma <e>non +verrà emenata nessuna GLSA</e> a seguito della completa risoluzione del +problema. +</p> + +<note> +Questa politica potrebbe essere cambiata quando verranno aggiunti nuovi +strumenti per coprire le vulnerabilità di sicurezza che affliggono i diversi +sorgenti dei kernel. +</note> + +</body> +</section> +<section> +<title>Pacchetti non stabili</title> +<body> + +<p> +Qualche volta viene rilevata una vulnerabilità in un pacchetto che non fa parte +dell'insieme dei pacchetti stabili. Questo è il caso quando la vulnerabilità è +una regressione di sicurezza in un nuovo (~ARCH) ebuild, ma i vecchi (stabili) +pacchetti non ne sono affetti, o quando il pacchetto non ha mai avuto alcun +ebuild stabile nel tree. In questo caso la vulnerabilità deve essere ancora +riportata e sarà risolta, ma <e>nessuna GLSA sarà pubblicata</e> fino a quando +tutto sarà risolto. +</p> + +<note> +Questa politica potrebbe essere cambiata quando gli strumenti del +team di sicurezza supporteranno percorsi di aggiornamento più complessi e se un +numero sufficiente di coordinatori GLSA si aggregherà al team di sicurezza. +</note> + +</body> +</section> +</chapter> + +<chapter> +<title>Tipi di vulnerabilità</title> +<section> +<title>Vulnerabilità pubbliche</title> +<body> + +<p> +Ogni vulnerabilità deve inizialmente essere inserita in <uri +link="https://bugs.gentoo.org">Bugzilla</uri> con prodotto "Gentoo Security" e +componente "Vulnerabilities" (assegnato a <mail +link="security@gentoo.org">security@gentoo.org</mail>). Le maggiori liste di +sicurezza devono avere delle persone che ufficialmente verificano che tutte le +vulnerabilità annunciate su queste liste siano state inserite in bugzilla. +</p> + +</body> +</section> +<section> +<title>Vulnerabilità confidenziali</title> +<body> + +<p> +Le vulnerabilità confidenziali (che per esempio provengono direttamente dagli +sviluppatori o da una lista di sicurezza riservata dei venditori) devono seguire +una procedura specifica. Esse non devono apparire pubblicamente in Bugzilla, ma +solo in un mezzo di sicurezza riservato, come una sezione riservata di Bugzilla +o lo strumento GLSAMaker. Esse devono essere ricevute correttamente utilizzando +un canale di comunicazione privato tra il coordinatore GLSA e il mantenitore del +pacchetto. +</p> + +<note> +Le comunicazioni per le vulnerabilità confidenziali devono essere criptate e +devono essere inviate ai membri del team di sicurezza e criptate con le loro +chiavi GPG. La lista dei membri del team di sicurezza è disponibile su <uri +link="http://security.gentoo.org">security.gentoo.org</uri>, le loro chiavi di +identificazione possono essere individuate sull'<uri +link="http://www.gentoo.org/proj/en/devrel/roll-call/userinfo.xml">Elenco degli +Sviluppatori Gentoo Linux</uri> e le loro chiavi possono essere prese dal server +delle chiavi <uri link="http://subkeys.pgp.net:11371">subkeys.pgp.net</uri>. +</note> + +</body> +</section> +</chapter> + +<chapter> +<title>Rapidità</title> +<section> +<title>Livelli di Severità</title> +<body> + +<p> +Per dare dei tempi di reazione appropriati e delle procedure di escalation, +c'è bisogno di assegnare dei livelli di severità ad ogni vulnerabilità. Questi +livelli di severità devono essere basati su quanto è diffuso il software affetto +fra gli utenti Gentoo e quanto sia profonda la vulnerabilità. +</p> + +<p> +Le seguenti due tavole possono aiutare nell'assegnazione del livello di +severità: +</p> + +<table> +<tr> + <th>Quanto è diffuso il pacchetto</th> + <th>Configurazioni affette</th> + <th> </th> +</tr> +<tr> + <ti>Pacchetto di sistema</ti> + <ti>Predefinito o specifico</ti> + <ti>A</ti> +</tr> +<tr> + <ti> + Pacchetto comune (si suppone sia presente almeno in 1/20 delle installazioni + di Gentoo) + </ti> + <ti>Predefinito</ti> + <ti>A</ti> +</tr> +<tr> + <ti></ti> + <ti>Specifico</ti> + <ti>B</ti> +</tr> +<tr> + <ti> + Software marginale (si suppone sia presente in meno di 1/20 delle + installazioni di Gentoo) + </ti> + <ti>Predefinito</ti> + <ti>B</ti> +</tr> +<tr> + <ti> </ti> + <ti>Specifico</ti> + <ti>C</ti> +</tr> +<tr> + <ti>Pacchetto che non ha mai avuto una versione stabile affetta</ti> + <ti>Predefinito or Specifico</ti> + <ti>~</ti> +</tr> +</table> + +<table> +<tr> + <th>Valutare i tipi di vulnerabilità</th> + <th> </th> + <th>Corrispondente severità della GLSA</th> +</tr> +<tr> + <ti> + Sistema remoto completamente compromesso: codice arbitrario eseguito in + remoto con privilegi di root + </ti> + <ti>0</ti> + <ti>high (alto)</ti> +</tr> +<tr> + <ti> + Attività remote compromesse: codice arbitrario direttamente eseguito a + distanza con diritti ridotti o a livello utente su un server + </ti> + <ti>1</ti> + <ti>high (alto)</ti> +</tr> +<tr> + <ti> + Aumento di privilegi locali: difetto che abilita l'utilizzo di root quando + si ha un accesso locale + </ti> + <ti>1</ti> + <ti>high (alto)</ti> +</tr> +<tr> + <ti> + Compromissione remota passiva: codice arbitrario eseguito in remoto + inducendo un utente a visitare un server non sicuro o usando dati malevoli + </ti> + <ti>2</ti> + <ti>normal (normale)</ti> +</tr> +<tr> + <ti> + Compromissione di servizi globali: blocco di servizi, completa sottrazione + di password, database, perdita di dati (attacchi tramite collegamenti + simbolici...) + </ti> + <ti>3</ti> + <ti>normal (normale)</ti> +</tr> +<tr> + <ti>Altro: Cross-Site Scripting, sottrazione di informazioni...</ti> + <ti>4</ti> + <ti>low (basso)</ti> +</tr> +</table> + +<p> +Questa è la tabella con i livelli di severità. Essa dev'essere uguale ai livelli +di severità in bugzilla: +</p> + +<table> +<tr> + <th>Livello di severità</th> + <th>Valutazioni corrispondenti</th> + <th>Tempo di attesa</th> + <th>GLSA</th> +</tr> +<tr> + <ti>Blocker (Bloccante)</ti> + <ti>A0, B0</ti> + <ti>1 giorno</ti> + <ti>sì</ti> +</tr> +<tr> + <ti>Critical (Critico)</ti> + <ti>A1, C0</ti> + <ti>3 giorni</ti> + <ti>sì</ti> +</tr> +<tr> + <ti>Major (Maggiore)</ti> + <ti>A2, B1, C1</ti> + <ti>5 giorni</ti> + <ti>sì</ti> +</tr> +<tr> + <ti>Normal (Normale)</ti> + <ti>A3, B2, C2</ti> + <ti>10 giorni</ti> + <ti>sì</ti> +</tr> +<tr> + <ti>Minor (Minore)</ti> + <ti>A4, B3, B4, C3</ti> + <ti>20 giorni</ti> + <ti>?</ti> +</tr> +<tr> + <ti>Trivial (Non importante)</ti> + <ti>C4, ~0, ~1, ~2, ~3, ~4</ti> + <ti>40 giorni</ti> + <ti>no</ti> +</tr> +</table> + +<note> +Il tempo di attesa indicato nella tabella è il tempo massimo tra il rilascio di +una correzione da parte dello sviluppatore originale del pacchetto e il rilascio +di un ebuild stabile e la corrispondente GLSA. +</note> + +</body> +</section> +<section> +<title>Regole per i "wrangler" di bug di sicurezza</title> +<body> + +<p> +Qualcuno deve assumersi la responsabilità di "wrangler" (ndT: letteralmente +"attaccabrighe", in questo caso è colui che deve gestire per primo i bug report +non assegnati in modo specifico) dei bug di sicurezza ed eseguire i seguenti +passi in caso di nuove vulnerabilità in <uri +link="https://bugs.gentoo.org">Bugzilla</uri>: +</p> + +<ul> + <li> + Verificare i duplicati: se il bug che descrive una vulnerabilità è gia + riportato, deve essere impostato su DUPLICATE + </li> + <li> + Verifica di componenti sbagliati: se il bug non è una vulnerabilità il + componente deve essere impostato appropriatamente + </li> + <li> + Verificare se il bug è veramente una vulnerabilità e se il pacchetto di + Gentoo Linux ne è affetto, altrimenti impostare il bug su INVALID + </li> +</ul> + +<p> +Durante questa fase può essere necessario chiedere ulteriori dettagli a chi ha +riportato il bug. Quest'ultimo rimane con stato NEW finche è necessario. Quando +(se) il bug supera questi test di validità, dovrebbe essere accettato e il +wrangler del bug deve fare quanto segue: +</p> + +<ul> + <li> + Rinominare il bug includendo la categoria/nome del pacchetto all'inizio (per + esempio: "net-mail/clamav: DoS usando file RAR") + </li> + <li>Valutare e assegnare un livello di severità (vedere sopra)</li> + <li>impostare lo stato in ASSIGNED</li> + <li> + Aggiornare il campo "Status Whiteboard" con il corretto codice e stato della + severità + </li> + <li> + Inserire nel campo CC del bug i mantenitori del pacchetto in base alle + informazioni contenute nel file metadata del pacchetto stesso + </li> + <li> + impostare il campo URL con l'indirizzo del relativo bug upstream o a + qualcosa di simile + </li> + <li> + cercare identificatori CVE riservati o assegnati e aggiungerli al titolo del + bug, altrimenti richiedere un CVE + </li> + <li> + opzionalmente assegnare un coordinatore GLSA al bug, e aggiungere il nome + del coordinatore nel campo "Status Whiteboard" + </li> +</ul> + +<warn> +Non cambiare la severità del bug una volta che è stato assegnato. Se si vuole +aumentare la pressione sullo sviluppatore riguardo alla necessità di risoluzione +del bug, usare preferibilmente il campo di Priorità. +</warn> + +</body> +</section> +<section> +<title>Tempo a disposizione e procedure di backup</title> +<body> + +<p> +Questo controllo deve essere fatto velocemente dopo la crezione del bug per dare +poco tempo alle vulnerabilità maggiori e mostrare un apprezzamento al reporter +del bug. Il tempo a disposizione è di 12 ore. Il wrangler del bug di sicurezza +deve fare una lista dei possibili coordinatori GLSA con la disponibilità e aree +di specializzazione preferite. Per assicurare una permanente invio, il lavoro di +wrangler dei bug di sicurezza dovrebbe avere dei rimpiazzi appropriati. +</p> + +</body> +</section> +</chapter> + +<chapter> +<title>Correzione dei bug e bozze della GLSA</title> +<section> +<title>Regole del coordinatore GLSA</title> +<body> + +<p> +Il coordinatore GLSA è responsabile dei seguenti punti: +</p> + +<ul> + <li> + determinare cosa deve essere fatto per chiudere la vulnerabilità (per + esempio identificare la versione rilasciata dagli sviluppatori originali + contenente la correzione) + </li> + <li> + se la correzione non è stata ancora resa disponibile dagli sviluppatori + originali, assicurarsi che il bug sia correttamente segnalato ad essi e che + il campo "Status Whiteboard" sia in <c>upstream</c> + </li> + <li> + se la correzione è disponibile, impegnare il mantenitore del pacchetto a + produrre e effettuare il commit di un'ebuild contenente la correzione + aggiornando il campo "Status Whiteboard" a <c>ebuild</c> + </li> + <li> + una volta effettuato il commit dell'ebuild, valutare le keyword necessarie + per l'ebuild corretto e far testare (e far contrassegnare come stabile) + l'ebuild contenente la correzione ai relativi team delle specifiche + architetture coinvolte (i team delle architetture, nonchè releng durante la + preparazione al rilascio, devono essere in cc sul bug) e impostare il campo + "Status Whiteboard" a <c>stable</c> + </li> + <li> + I mantenitori delle architetture dovrebbero contrassegnare l'ebuild stabile + se non c'è regressione nell'ebuild contenente la correzione rispetto + all'ultima versione vulnerabile + </li> + <li> + in parallelo, scrivere una bozza di GLSA usando lo strumento GLSAMaker + </li> + <li> + Quando l'ebuild correttivo è pronto per tutte le architetture supportate, + impostare il campo "Status Whiteboard" a <c>glsa</c> + </li> +</ul> + +<note> +Se il bug progredisce ed il coordinatore GLSA assegnato non reagisce, gli altri +membri del team di sicurezza possono aiutare a mantenere attivo il bug +aggiornandone lo stato. +</note> + +</body> +</section> +<section> +<title>Tempo a disposizione e procedure di escalation</title> +<body> + +<p> +Avendo poco tempo per la risoluzione della vulnerabilità, sono state definite +un numero di procedure di escalation. Incluse queste: +</p> + +<ul> + <li> + quando un bug in stato di attesa ha un bisogno urgente di essere corretto, + bisogna cambiare il campo "Status Whiteboard" aggiungendo una "+" alle + controparti: <c>upstream+</c>, <c>ebuild+</c>,<c>stable+</c> e <c>glsa+</c> + </li> + <li> + se non è disponibile nessuna correzione da parte degli sviluppatori + originali del pacchetto (in stato <c>upstream+</c>), deve essere presa + una decisione per mascherare il pacchetto: il team di sicurezza può + mascherare un pacchetto che non dipende da sè stesso, ma necessita + dell'approvazione di un responsabile principale prima di mascherare un + pacchetto che non è assestante. + </li> + <li> + se il mantenitore non mostra progressi nel produrre l'ebuild entro 48 ore + dopo il sollecito (stato <c>ebuild+</c>), il team di sicurezza deve provare + creare l'ebuild da sè + </li> + <li> + se i test e le correzioni impiegano troppo tempo (stato <c>stable+</c>), il + team di sicurezza cercherà sui canali IRC e nella lista gentoo-dev di + prendere più tester. Altrimenti contrassegnerà l'ebuild come stabile da sè + o, nell'eventualità che questo non possa essere fatto per problemi di + stabilità, mascherarlo (vedere la politica di approvazione per il + mascheramento di sicurezza qui sopra) + </li> + <li> + se il coordinatore della GLSA non presenta una bozza della GLSA (stato + <c>glsa+</c>), gli altri membri del team di sicurezza devono fare una bozza + della GLSA e inviarla per presa visione + </li> +</ul> + +</body> +</section> +<section> +<title>Buone abitudini per i bug di sicurezza</title> +<body> + +<p> +I bug di sicurezza differiscono da altri bug, in quanto un facile e semplice +percorso di aggiornamento deve essere presentato agli utenti tramite la GLSA. Di +conseguenza i mantenitori del pacchetto e i coordinatori GLSA deveno seguire +queste semplici buone abitudini. +</p> + +<ul> + <li> + L'ebuild incluso nella correzione di sicurezza deve avere un proprio numero + di versione, in modo che venga preso nel normale processo di aggiornamente + del sistema: usare gli incrementi di versione se necessario + </li> + <li> + L'ebuild incluso nella correzione di sicurezza deve avere un numero di + versione maggiore rispetto alle precedenti versioni pubblicate, in modo + che un facile processo di aggiornamento possa essere proposto agli utenti + </li> + <li> + Nel caso di una patch, deve essere applicata solo alla versione più recente, + non c'è bisogno di un incremento di versione per tutti gli ebuild con la + versione contenente la patch + </li> + <li> + Le versioni vulnerabili devono essere lasciate nel tree finche il bug + entrerà nello stato <c>stable</c>, per valutare correttamente che keyword + siano disponibili per la versione contenente la correzione + </li> +</ul> + +</body> +</section> +<section> +<title>GLSA temporanee</title> +<body> + +<p> +Se una vulnerabilità <e>blocker</e> o <e>critical</e> o <e>major</e> non può +essere totalmente corretta nel tempo indicato un allarme immediato GLSA deve +essere scritta con le informazioni su cosa fare. Questa GLSA sarà sostituita da +una GLSA finale nel momento in cui la correzione definitiva sarà disponibile. +</p> + +<p> +Se un pacchetto comune (tipo A o B) è nascosto (masked) per ragioni di +sicurezza, una GLSA temporanea deve essere pubblicata per spiegare perchè non è +disponibile e/o perchè gli utenti devono disinstallare la versione corrente. +Quasta GLSA sarà sostituita dalla GLSA finale quando la correzione e il +relativo pacchetto saranno disponibili. +</p> + +</body> +</section> +</chapter> + +<chapter> +<title>Processi della pubblicazione GLSA</title> +<section> +<title>Revisione</title> +<body> + +<p> +Quando è pronta, una GLSA deve essere sottoposta a revisione, due membri del +team di sicurezza devono approvare la bozza della GLSA. Quando la bozza passa il +processo di revisione, gli viene assegnato un numero ufficiale GLSA +</p> + +</body> +</section> +<section> +<title>Rilascio di GLSA</title> +<body> + +<p> +Quando la GLSA passa il processo di revisione (e dopo essersi assicurari che +l'ebuild sia entrato nel ramo stabile), il coordinatore GLSA deve scrivere l'XML +della GLSA nel repository del Gentoo CVS. Fatto questo,la GLSA comparirà +automaticamente sulla <uri link="http://glsa.gentoo.org">pagina +ufficiale dell'indice delle GLSA</uri> e nel <uri +link="http://www.gentoo.org/rdf/en/glsa-index.rdf">RDF feed</uri>. +</p> + +</body> +</section> +<section> +<title>Pubblicazione della GLSA</title> +<body> + +<p> +La versione GLSA in formato testo deve essere pubblicata dal coordinatore GLSA +sui seguenti mezzi di comunicazione: +</p> + +<table> +<tr> + <ti>Gentoo Linux official announcement mailing-list</ti> + <ti> + <mail link="gentoo-announce@lists.gentoo.org"> + gentoo-announce@lists.gentoo.org</mail> + </ti> +</tr> +<tr> + <ti>Bugtraq security mailing-list</ti> + <ti> + <mail link="bugtraq@securityfocus.com">bugtraq@securityfocus.com</mail> + </ti> +</tr> +<tr> + <ti>Full-disclosure security mailing-list</ti> + <ti> + <mail + link="full-disclosure@lists.grok.org.uk">full-disclosure@lists.grok.org.uk + </mail> + </ti> +</tr> +<tr> + <ti>Linuxsecurity.com advisories service</ti> + <ti> + <mail + link="security-alerts@linuxsecurity.com">security-alerts@linuxsecurity.com + </mail> + </ti> +</tr> +<tr> + <ti>Gentoo Linux announcement forum</ti> + <ti><uri>http://forums.gentoo.org/viewforum.php?f=16</uri></ti> +</tr> +</table> + +<p> +Deve essere inviata una singola email, con le seguenti regole: +</p> + +<ul> + <li>Il campo <c>To:</c> deve essere gentoo-announce</li> + <li>Il campo <c>Cc:</c> deve contenere gli altri indirizzi mail</li> + <li> + I campi <c>From:</c> e <c>Return-Path:</c> devono contenere gli indirizzi + @gentoo.org dei coordinatori GLSA + </li> + <li> + Il campo <c>Subject:</c> deve essere "[ GLSA XXXXYY-ZZ ] Inserire qui la + vulnerabilità" + </li> + <li>Il corpo della mail deve contenere solo la versione testo della GLSA</li> + <li>La mail deve essere firmato con la chiave GPG del coordinatore GLSA</li> +</ul> + +<note> +Le chiavi ID degli sviluppatori sono reperibili nella <uri +link="http://www.gentoo.org/proj/en/devrel/roll-call/userinfo.xml">Lista degli +Sviluppatori</uri>di Gentoo Linux. Tutte le chiavi GPG del team di sicurezza +sono pubblicate sul server delle chiavi pubbliche, incluse (ma non limitate a) +<uri link="http://subkeys.pgp.net:11371">subkeys.pgp.net</uri>. +</note> + +<note> +Per minimizzare errori sul processo di pubblicazione, viene ricevuto un avviso +automatico di avvenuta pubblicazione. +</note> + +<p> +Quando il GLSA viene pubblicato, il corrispettivo bug in bugzilla deve essere +impostato a FIXED, con il numero GLSA di riferimento nella sezione commenti del +bug. +</p> + +</body> +</section> +<section> +<title>GLSA errate</title> +<body> + +<p> +A volte un errore supera il processo di revisione e una GLSA non corretta viene +pubblicata al mondo. A secondo della criticità dell'errore, la seguente politica +per errori di stampa deve essere applicata: +</p> + +<table> +<tr> + <th>Tipi di errori di stampa</th> + <th>Cosa fare</th> +</tr> +<tr> + <ti>Tipi: presentazione, errori di grammatica o di sintassi</ti> + <ti>Niente</ti> +</tr> +<tr> + <ti> + Errore nel titolo: il titolo di un altro pacchetto o non descrive la + vulnerabilità correttamente + </ti> + <ti>Un errore di stampa deve essere pubblicato, replicando quello errato</ti> +</tr> +<tr> + <ti>Errore nella descrizione: il problema non è descritto correttamente</ti> + <ti>L'XML della GLSA deve essere corretto, ma non pubblicato</ti> +</tr> +<tr> + <ti> + Omissione: la GLSA è corretta ma incompleta, inoltre bisogna aggiornare un + altro pacchetto per prendere la protezione dalla vulnerabilità + </ti> + <ti> + Una GLSA separata deve essere pubblicata sull'altro pacchetto vulnerabile + </ti> +</tr> +<tr> + <ti> + Errore nel numero di versione infetta/non infetta, ma la gente usa un + pacchetto stabile e applicando le istruzioni della GLSA sono comunque + protetti + </ti> + <ti>L'XML della GLSA deve essere corretto, ma non pubblicato</ti> +</tr> +<tr> + <ti> + Errore nel numero di versione infetta/non infetta, la gente che applica le + istruzione della GLSA non è comunque protetta + </ti> + <ti>Un errore di stampa deve essere pubblicato, replicando quello errato</ti> +</tr> +</table> + +</body> +</section> +</chapter> +</guide> |