6.6. Controllare l'autenticità dei pacchetti

La sicurezza è molto importante per gli amministratori di Falcot Corp. Di conseguenza, devono garantire che vengano installati solo i pacchetti di cui è garantita la provenienza da Debian senza alcuna manomissione lungo il percorso. Un autore di attacchi informatici potrebbe tentare di aggiungere codice dannoso ad un pacchetto altrimenti legittimo. Tale pacchetto, se installato, potrebbe fare qualsiasi cosa per cui l'autore dell'attacco l'ha progettato, tra cui ad esempio scoprire password o informazioni riservate. Per ovviare a questo rischio, Debian fornisce un sigillo di garanzia a prova di manomissione per garantire, in fase di installazione, che un pacchetto venga veramente dal suo manutentore ufficiale e non sia stato modificato da terzi.

Il sigillo funziona con una catena di hash crittografici ed una firma ben spiegato nel dettaglio in apt-secure(8). A partire da Debian 10 Buster il file firmato è InRelease, fornito dai mirror Debian. Esiste anche un file legacy chiamato Release. Entrambi contengono un elenco dei file Packages (comprese le forme compresse, Packages.gz e Packages.xz, e le versioni incrementali), insieme ai loro hash SHA256, che garantiscono che i file non siano stati manomessi. Questi file Packages, contengono un elenco dei pacchetti Debian disponibili sul mirror insieme ai loro hash, che assicurano che anche il contenuto dei pacchetti stessi non sia stato alterato. La differenza tra InRelease e Release è che il primo è firmato crittograficamente in linea, mentre per il secondo viene fornita una firma separata sotto forma del file Release.gpg.

APT ha bisogno di un insieme di chiavi pubbliche GnuPG affidabili, disponibili sui mirror, per verificare le firme nei file InRelease e Release.gpg. Le ottiene dai file in /etc/apt/trusted.gpg.d/ e dal portachiavi /etc/apt/trusted.gpg (gestito dal comando apt-key). Le chiavi ufficiali Debian sono fornite ed aggiornate tramite il pacchetto debian-archive-keyring che le inserisce in /etc/apt/trusted.gpg.d/:

# ls /etc/apt/trusted.gpg.d/
debian-archive-bookworm-automatic.asc
debian-archive-bookworm-security-automatic.asc
debian-archive-bookworm-stable.asc
debian-archive-bullseye-automatic.asc
debian-archive-bullseye-security-automatic.asc
debian-archive-bullseye-stable.asc
debian-archive-buster-automatic.asc
debian-archive-buster-security-automatic.asc
debian-archive-buster-stable.asc

IN PRATICA Aggiungere chiavi fidate

Quando si aggiunge una sorgente di pacchetti di terze parti al file sources.list, APT ha bisogno di venire istruiti a fidarsi della corrispondente chiave GPG (altrimenti continuerà a ricordare che non può garantire l'autenticità dei pacchetti provenienti da quel repository). Il primo passo è ovviamente ottenere la chiave pubblica. Spesso, la chiave viene fornita come un piccolo file di testo, che verrà chiamato nei prossimi esempi key.asc.

Per aggiungere la chiave al portachiavi fidato di APT, l'amministratore può semplicemente inserirla in un file *.gpg in /etc/apt/trusted.gpg.d/ (i file*.asc sono sconsigliati e possono causare problemi). Ciò è supportato a partire da Debian Stretch. Con le versioni precedenti si doveva eseguire apt-key add < key.asc, che è già considerato obsoleto.

Sebbene questo sia un comportamento molto comune, crea anche un possibile problema. APT non sa quale chiave appartiene a quale repository. Se una delle chiavi nel portachiavi di APT corrisponde alla firma di un archivio, APT considera l'archivio come autenticato. Una volta che una chiave è stata aggiunta al portachiavi fidato, un malintenzionato potrebbe effettivamente fornire la propria "versione" di un mirror Debian firmato dalla stessa chiave. Potrebbe quindi essere meglio mettere la chiave come file *.gpg in /usr/share/keyrings/ e usare il campo Signed-By in sources.list per i repository di terze parti, come mostrato nell'esempio seguente.

Immaginate che la Falcot Corp. gestisca un proprio repository pubblico e che voi vogliate utilizzarlo. Lo hanno firmato e forniscono anche una chiave disponibile pubblicamente da scaricare. Per limitare la chiave al repository, si può fare semplicemente così:

$ sudo wget -O falcot-keyring.gpg -P /usr/share/keyrings https://packages.falcot.com/debian/repository.gpg

deb [ signed-by=/usr/share/keyrings/falcot-keyring.gpg ] https://packages.falcot.com/debian bullseye main

Attenzione: l'aggiunta e l'utilizzo di repository di terze parti comporta sempre un rischio per la sicurezza e la stabilità!

Una volta che le chiavi appropriate sono nel portachiavi, APT controllerà le firme prima di qualsiasi operazione rischiosa, in modo che le interfacce visualizzino un avviso se viene chiesto di installare un pacchetto la cui autenticità non può essere accertata.

Si noti che i pacchetti binari di solito non sono firmati. L'integrità di un pacchetto può essere confermata solo verificando i suoi hashsum con una fonte affidabile (e possibilmente firmata) di hashsum.

CASO SPECIFICO Repository non firmati

Sebbene, in generale, i repository non firmati non dovrebbero essere usati, alcuni utenti potrebbero comunque richiederli, ad esempio per fornire alcuni pacchetti compilati localmente. APT può essere forzato ad accettare un repository di questo tipo anteponendo all'URL del repository allow-insecure=yes o trusted=yes. Lo dimostreremo usando l'esempio di Sezione 15.3, «Creazione di un repository di pacchetti per APT»:

deb [ trusted=yes ] http://packages.falcot.com/ updates/
deb [ trusted=yes ] http://packages.falcot.com/ internal/