Gentoo Logo

Politiche di gestione delle vulnerabilità in Gentoo Linux

Indice:

1.  Scopo

Architetture supportate

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.

Per questa ragione, il team di sicurezza ha separato le architetture Gentoo in due gruppi, supportate e non supportate:

  • Supportate: Queste architetture devono avere una correzione stabile applicata prima che la GLSA possa essere rilasciata
  • Non supportate: 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

Questa è la lista delle architetture attualmente supportate:

Architetture supportate (in ordine alfabetico)
alpha
amd64
hppa
ppc
ppc64
sparc
x86

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:

  • 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
  • Aderire all'osservanza delle scadenze pubblicate per i test e la marcatura di stabilità dei pacchetti

Kernel

I kernel non sono coperti dal processo di rilascio delle GLSA. Le vulnerabilità devono ancora essere riportate e verranno corrette, ma non verrà emenata nessuna GLSA a seguito della completa risoluzione del problema.

Nota: L'utility kernel-check, è stata sviluppata per fornire le informazioni di sicurezza riguardanti il kernel.

Pacchetti non stabili

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 nessuna GLSA sarà pubblicata fino a quando tutto sarà risolto.

Nota: 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.

2.  Tipi di vulnerabilità

Vulnerabilità pubbliche

Ogni vulnerabilità deve inizialmente essere inserita in Bugzilla con prodotto "Gentoo Security" e componente "Vulnerabilities" (assegnato a security@gentoo.org). 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.

Vulnerabilità confidenziali

Le vulnerabilità confidenziali (che per esempio provengono direttamente dagli sviluppatori o da una lista di sicurezza riservata) 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.

Nota: 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 security.gentoo.org, le loro chiavi di identificazione possono essere individuate sull'Elenco degli Sviluppatori Gentoo Linux e le loro chiavi possono essere prese dal server delle chiavi subkeys.pgp.net. L'uso di IRC o altri metodi non criptati è scoraggiato.

3.  Rapidità

Livelli di Severità

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à.

Le seguenti due tavole possono aiutare nell'assegnazione del livello di severità:

Quanto è diffuso il pacchetto Configurazioni affette
Pacchetto di sistema Predefinito o specifico A
Pacchetto comune (si suppone sia presente almeno in 1/20 delle installazioni di Gentoo) Predefinito A
Specifico B
Software marginale (si suppone sia presente in meno di 1/20 delle installazioni di Gentoo) Predefinito B
Specifico C
Pacchetto che non ha mai avuto una versione stabile affetta Predefinito or Specifico ~
Valutare i tipi di vulnerabilità Corrispondente severità della GLSA
Sistema remoto completamente compromesso: codice arbitrario eseguito in remoto con privilegi di root 0 high (alto)
Attività remote compromesse: codice arbitrario direttamente eseguito a distanza con diritti ridotti o a livello utente su un server 1 high (alto)
Aumento di privilegi locali: difetto che abilita l'utilizzo di root quando si ha un accesso locale 1 high (alto)
Compromissione remota passiva: codice arbitrario eseguito in remoto inducendo un utente a visitare un server non sicuro o usando dati malevoli 2 normal (normale)
Compromissione di servizi globali: blocco di servizi, completa sottrazione di password, database, perdita di dati (attacchi tramite collegamenti simbolici...) 3 normal (normale)
Altro: Cross-Site Scripting, sottrazione di informazioni... 4 low (basso)

Questa è la tabella con i livelli di severità. Essa dev'essere uguale ai livelli di severità in bugzilla:

Livello di severità Valutazioni corrispondenti Tempo di attesa GLSA
Blocker (Bloccante) A0, B0 1 giorno
Critical (Critico) A1, C0 3 giorni
Major (Maggiore) A2, B1, C1 5 giorni
Normal (Normale) A3, B2, C2 10 giorni
Minor (Minore) A4, B3, B4, C3 20 giorni ?
Trivial (Non importante) C4, ~0, ~1, ~2, ~3, ~4 40 giorni no

Nota: 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.

Regole per i "wrangler" di bug di sicurezza

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 Bugzilla:

  • Verificare i duplicati: se il bug che descrive una vulnerabilità è gia riportato, deve essere impostato su DUPLICATE
  • Verifica di componenti sbagliati: se il bug non è una vulnerabilità il componente deve essere impostato appropriatamente
  • Verificare se il bug è veramente una vulnerabilità e se il pacchetto di Gentoo Linux ne è affetto, altrimenti impostare il bug su INVALID

Durante questa fase può essere necessario chiedere ulteriori dettagli a chi ha riportato il bug. Quest'ultimo rimane con stato UNCONFIRMED o CONFIRMED finche è necessario. Quando (se) il bug supera questi test di validità, può essere marcato come IN_PROGRESS e il wrangler del bug deve fare quanto segue:

  • Rinominare il bug includendo la categoria/nome del pacchetto all'inizio (per esempio: "net-mail/clamav: DoS usando file RAR)
  • Rimuovere le informazioni riguardante la versione se non esiste una versione corretta disponibile. Bug con titoli come <=categoria/pacchetto-1.2.3 dove 1.2.3 è l'ultima versione del pacchetto deve essere evitato
  • Valutare e assegnare un livello di severità (vedere sopra)
  • impostare lo stato in IN_PROGRESS
  • Aggiornare il campo "Status Whiteboard" con il corretto codice e stato della severità
  • Inserire nel campo CC del bug i mantenitori del pacchetto in base alle informazioni contenute nel file metadata del pacchetto stesso
  • impostare il campo URL con l'indirizzo del relativo bug upstream o a qualcosa di simile
  • cercare identificatori CVE riservati o assegnati e aggiungerli al titolo del bug, altrimenti richiedere un CVE
  • Inserire il numero del bug nel tracker CVE (dato che il wrangler vi ha accesso)
  • settare l'alias come identificatore CVE. In caso di CVE multipli inserire il primo in ordine crescente.

Avvertenza: 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à.

Tempo a disposizione e procedure di backup

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.

4.  Correzione dei bug e bozze della GLSA

Regole del coordinatore GLSA

Il coordinatore GLSA è responsabile dei seguenti punti:

  • determinare cosa deve essere fatto per chiudere la vulnerabilità (per esempio identificare la versione rilasciata dagli sviluppatori originali contenente la correzione)
  • 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 upstream
  • 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 ebuild
  • 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 stable
  • I mantenitori delle architetture dovrebbero contrassegnare l'ebuild stabile se non c'è regressione nell'ebuild contenente la correzione rispetto all'ultima versione vulnerabile
  • in parallelo, scrivere una bozza di GLSA usando lo strumento GLSAMaker
  • Quando l'ebuild correttivo è pronto per tutte le architetture supportate, impostare il campo "Status Whiteboard" a glsa

Nota: 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.

Tempo a disposizione e procedure di escalation

Avendo poco tempo per la risoluzione della vulnerabilità, sono state definite un numero di procedure di escalation. Incluse queste:

  • quando un bug in stato di attesa ha un bisogno urgente di essere corretto, bisogna cambiare il campo "Status Whiteboard" aggiungendo una "+" alle controparti: upstream+, ebuild+,stable+ e glsa+
  • se non è disponibile nessuna correzione da parte degli sviluppatori originali del pacchetto (in stato upstream+), deve essere presa una decisione per mascherare il pacchetto: il team di sicurezza può mascherare un pacchetto che non dipende da sè stesso, ma il responsabile principale dovrebbe essere consultato prima di mascherare un pacchetto che non è assestante.
  • se il mantenitore non mostra progressi nel produrre l'ebuild entro 48 ore dopo il sollecito (stato ebuild+), il team di sicurezza deve provare creare l'ebuild da sè
  • se i test e le correzioni impiegano troppo tempo (stato stable+), 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)
  • se il coordinatore della GLSA non presenta una bozza della GLSA (stato glsa+), gli altri membri del team di sicurezza devono fare una bozza della GLSA e inviarla per presa visione

Buone abitudini per i bug di sicurezza

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.

  • 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
  • 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
  • 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
  • Le versioni vulnerabili devono essere lasciate nel tree finche il bug entrerà nello stato stable, per valutare correttamente che keyword siano disponibili per la versione contenente la correzione

GLSA temporanee

Nota: Non è più una pratica comune.

Se una vulnerabilità blocker o critical o major 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.

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.

5.  Processi della pubblicazione GLSA

Revisione

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

Rilascio di GLSA

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 pagina ufficiale dell'indice delle GLSA e nel RDF feed.

Pubblicazione della GLSA

La versione GLSA in formato testo deve essere pubblicata dal coordinatore GLSA sui seguenti mezzi di comunicazione:

Gentoo Linux official announcement mailing-list gentoo-announce@lists.gentoo.org
Gentoo Linux announcement forum http://forums.gentoo.org/viewforum.php?f=16

Deve essere inviata una singola email, con le seguenti regole:

  • Il campo To: deve essere gentoo-announce
  • I campi From: e Return-Path: devono contenere gli indirizzi @gentoo.org dei coordinatori GLSA
  • Il campo Subject: deve essere "[ GLSA XXXXYY-ZZ ] Inserire qui la vulnerabilità"
  • Il corpo della mail deve contenere solo la versione testo della GLSA
  • La mail deve essere firmato con la chiave GPG del coordinatore GLSA

Nota: Le chiavi ID degli sviluppatori sono reperibili nella Lista degli Sviluppatoridi Gentoo Linux. Tutte le chiavi GPG del team di sicurezza sono pubblicate sul server delle chiavi pubbliche, incluse (ma non limitate a) subkeys.pgp.net.

Nota: Per minimizzare errori sul processo di pubblicazione, viene ricevuto un avviso automatico di avvenuta pubblicazione.

Nota: Dal 2 Febbraio 2012, noi abbiamo deciso di non mettere in CC terze parti. La mailing list gentoo-announce ha poco traffico, quindi loro dovrebbero essere sottoscritti li. Generalmente, liste di sicurezza come full-disclosure o bugtraq non sono il nostro punto di riferimento e avere varie distribuzioni che inviano notizie sulle stesse vulnerabilità non è di alcuna utilità per molti lettori. quindi anche loro dovrebbero essere sottoscritti a gentoo-announce.

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. Il tool GLSAMaker 2 offre questa possibilità.

GLSA errate

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:

Tipi di errori di stampa Cosa fare
Tipi: presentazione, errori di grammatica o di sintassi Niente
Errore nel titolo: il titolo di un altro pacchetto o non descrive la vulnerabilità correttamente Un errore di stampa deve essere pubblicato, replicando quello errato
Errore nella descrizione: il problema non è descritto correttamente L'XML della GLSA deve essere corretto, ma non pubblicato
Omissione: la GLSA è corretta ma incompleta, inoltre bisogna aggiornare un altro pacchetto per prendere la protezione dalla vulnerabilità Una GLSA separata deve essere pubblicata sull'altro pacchetto vulnerabile
Errore nel numero di versione infetta/non infetta, ma la gente usa un pacchetto stabile e applicando le istruzioni della GLSA sono comunque protetti L'XML della GLSA deve essere corretto, ma non pubblicato
Errore nel numero di versione infetta/non infetta, la gente che applica le istruzione della GLSA non è comunque protetta Un errore di stampa deve essere pubblicato, replicando quello errato


Stampa

Aggiornato il 2 febbraio 2012

Oggetto: Questo documento descrive le politiche usate in Gentoo Linux per gestire le vulnerabilità scoperte nei pacchetti resi disponibili agli utenti.

Thierry Carrez
Autore

Sune Kloppenborg Jeppesen
Autore

Matthias Geerdsen
Autore

Robert Buchholz
Autore

Alex Legler
Autore

Donate to support our development efforts.

Copyright 2001-2014 Gentoo Foundation, Inc. Questions, Comments? Contact us.