Perché esiste un repository di pacchetti separato per gli aggiornamenti di sicurezza di Debian?


18

Perché non caricano i pacchetti nel normale repository di pacchetti? È una convenzione generale (IE, anche altre distro separano i repository)?


Suggerirei di non avere altre distro che potrebbero essere eccessivamente lunghe, anche per archivio vuoi dire pacchetto repo? Immagino che lo faccia, ma assicurandomi di non voler dire un ramo svn / git o qualcosa del genere.
xenoterracide,

Risposte:


16

Debian ha un canale di distribuzione che fornisce solo aggiornamenti di sicurezza in modo che gli amministratori possano scegliere di eseguire un sistema stabile con solo il minimo assoluto di modifiche. Inoltre, questo canale di distribuzione è in qualche modo separato dal canale normale: tutti gli aggiornamenti di sicurezza vengono alimentati direttamente security.debian.org, mentre si consiglia di utilizzare i mirror per tutto il resto. Questo ha una serie di vantaggi. (Non ricordo quali di queste sono le motivazioni ufficiali che ho letto sulle mailing list di Debian e quali sono le mie mini-analisi. Alcune di queste sono toccate nelle FAQ sulla sicurezza di Debian .)

  • Gli aggiornamenti di sicurezza vengono diffusi immediatamente, senza il ritardo dovuto agli aggiornamenti del mirror (che possono aggiungere circa 1 giorno di propagazione).
  • Gli specchi possono diventare stantii. La distribuzione diretta evita questo problema.
  • C'è meno infrastruttura da mantenere come servizio critico. Anche se la maggior parte dei server Debian non sono disponibili e le persone non possono installare nuovi pacchetti, purché security.debian.orgpuntino a un server funzionante, gli aggiornamenti di sicurezza possono essere distribuiti.
  • Gli specchi possono essere compromessi (questo è successo in passato). È più facile guardare un singolo punto di distribuzione. Se un utente malintenzionato è riuscito a caricare un pacchetto dannoso da qualche parte, security.debian.orgpotrebbe inviare un pacchetto con un numero di versione più recente. A seconda della natura dell'exploit e della tempestività della risposta, questo potrebbe essere sufficiente per mantenere alcune macchine non infette o almeno avvisare gli amministratori.
  • Sempre meno persone hanno diritti di upload su security.debian.org. Ciò limita le possibilità per un utente malintenzionato di provare a sovvertire un account o una macchina per iniettare un pacchetto dannoso.
  • I server che non necessitano di un normale accesso al web possono essere tenuti dietro un firewall che consente solo security.debian.orgattraverso.

2
Il repository di sicurezza precede la firma dei file di rilascio per i repository, pertanto il mirroring è stato scoraggiato, in quanto ha diluito la fiducia implicita del download da security.debian.org. Tale argomento è scomparso in una certa misura ora che i metadati del pacchetto sono firmati.
jmtd,

l'host security.debian.orgsi risolve in un mucchio di indirizzi, quindi forse è un pool di macchine, anche se tecnicamente non ha mirror.
Faheem Mitha,

8

Sono abbastanza sicuro che Debian inserisca anche gli aggiornamenti di sicurezza nel repository normale.

Il motivo per avere un repository separato che contiene solo aggiornamenti di sicurezza è che è possibile configurare un server, puntarlo solo sul repository di sicurezza e automatizzare gli aggiornamenti. Ora hai un server che è garantito per avere le ultime patch di sicurezza senza introdurre accidentalmente bug causati da versioni incompatibili, ecc.

Non sono sicuro che questo meccanismo esatto venga utilizzato da altre distro. C'è un yumplugin per gestire questo genere di cose per CentOS, e Gentoo attualmente ha una mailing list di sicurezza ( portageè attualmente in fase di modifica per supportare gli aggiornamenti solo della sicurezza). FreeBSD e NetBSD forniscono entrambi modi per eseguire controlli di sicurezza su porte / pacchetti installati, che si integrano bene con i meccanismi di aggiornamento integrati. Tutto sommato, l'approccio di Debian (e probabilmente quello di Ubuntu, dal momento che sono così strettamente correlati) è una delle soluzioni più semplici a questo problema.


sì, perché una patch di sicurezza non potrebbe mai introdurre un altro bug.
xenoterracide,

"s. Ora hai un server che è garantito per avere le ultime patch di sicurezza senza introdurre accidentalmente bug causati da versioni incompatibili, ecc." non è quello che significa? Suppongo di poter sostenere che le versioni incompatibili sono il punto discutibile ... cosa significa esattamente ... il più delle volte le persone che supportano solo le patch di sicurezza non lo fanno perché pensano che ABI / API sia l'unica cosa che stai guardando.
xenoterracide,

@xeno Stai criticando l'idea di suddividere questi repository o ci stai avvisando che non ci sono garanzie?
Tshepang,

1
@xeno A seconda di come gli upstream gestiscono le cose, le patch di bugfix possono essere troppo invadenti per una versione "stabile".
Tshepang,

3
La stragrande maggioranza delle patch di sicurezza sono banalmente piccole: riordinare gli argomenti su un memset, correggere un controllo dei limiti su uno strncmp o what-have-you. Naturalmente, potrebbero plausibilmente introdurre altri bug, ma il rischio è molto piccolo e teorico, mentre il bug di sicurezza scoperto è molto pratico.
jmtd,

2

Aiuta con due cose:

  1. sicurezza: prima ottieni le tue correzioni di sicurezza, quindi sei a minor rischio durante l'aggiornamento del resto
  2. gli aggiornamenti di sicurezza dovrebbero essere archiviati a un livello di sicurezza elevato, poiché si tende a fare affidamento su di essi per proteggere il resto del sistema, quindi è possibile che questo repository abbia controlli di sicurezza più forti per prevenire compromessi

potrebbero esserci altre ragioni, ma quelle sono le due che troverei utili


Sei sicuro di essere archiviato ad un livello di sicurezza elevato ? Lo dico perché esprimi dubbi, potrebbe esserlo .
Tshepang,

Tshepang ben individuato - Non ho visibilità dell'ambiente in cui esiste il repository, ma è così che lo configurerei :-)
Rory Alsop,

5
Esiste almeno una forma di livello di sicurezza superiore: solo il team di sicurezza può inviare un pacchetto security.debian.org. Non conosco i dettagli di implementazione.
Gilles 'SO- smetti di essere malvagio' il
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.