I repository RPM di grandi dimensioni e popolari vengono in genere replicati in tutto il mondo. I progetti e le aziende che forniscono i pacchetti utilizzano reti di distribuzione dei contenuti (CDN) e siti mirror per rendere i loro pacchetti disponibili ai consumatori. Per molti progetti open source, ciò include l'hosting da parte di volontari. Per rilevare ed evitare pacchetti sostitutivi dannosi, i proprietari dei pacchetti possono firmare i file del pacchetto e i consumatori possono verificare tali firme.
Sebbene GPG possa firmare qualsiasi file, il controllo manuale delle firme dei pacchetti non è scalabile per gli amministratori di sistema. Il formato RPM ha un'area specificatamente riservata per contenere una firma dell'intestazione e del carico utile. Il rpm l'utilità utilizza le chiavi GPG per firmare i pacchetti e la propria raccolta di chiavi pubbliche importate per verificare i pacchetti. YUM e DNF utilizzano i file di configurazione del repository per fornire puntatori alle posizioni delle chiavi pubbliche GPG e assistere nell'importazione delle chiavi in modo che RPM possa verificare i pacchetti.
Per questo articolo userò chiavi e pacchetti di EPEL. La chiave pubblica è inclusa in un pacchetto RPM, che configura anche il yum repo . Per alcuni progetti, la chiave potrebbe anche essere disponibile direttamente da un sito Web di origine.
L'utilità rpm ha una propria gestione delle chiavi
Dal rpm l'utilità ha una propria gestione delle chiavi, non è necessario importare le chiavi pubbliche GPG nel proprio portachiavi GPG personale. In effetti, non puoi semplicemente verificare il file con gpg comandi perché la firma non è dell'intero file .rpm. La firma è invece associata solo alle parti critiche del pacchetto.
Esegui il comando seguente per utilizzare rpm per verificare un pacchetto:
$ rpm -K epel-release-latest-8.noarch.rpm
epel-release-latest-8.noarch.rpm: digests SIGNATURES NOT OK
In questo caso, viene visualizzato il messaggio "SIGNATURES NOT OK" perché la chiave non è stata ancora importata per RPM. Il comportamento predefinito di rpm comandi consiste nel verificare la firma dei pacchetti durante qualsiasi installazione o verificare le interazioni. Se ciò non è possibile, perché il pacchetto non è firmato o la chiave pubblica non è disponibile, potrebbe essere necessario specificare il --nogpgcheck opzione per saltare questo passaggio.
Se hai accesso alla chiave pubblica GPG, puoi utilizzare il seguente comando per importare manualmente una chiave:
$ rpm --import RPM-GPG-KEY-EPEL-8 Poiché i metadati della chiave sono archiviati nel database RPM, puoi eseguire query ed eliminare chiavi come qualsiasi pacchetto.
Utilizzare il comando seguente per elencare le chiavi:
$ rpm -qa gpg-pubkey*
gpg-pubkey-7fac5991-4615767f
gpg-pubkey-2f86d6a1-5cf7cefb Utilizzare questo comando per ottenere le informazioni su una chiave:
$ rpm -qi gpg-pubkey-2f86d6a1-5cf7cefb
Name : gpg-pubkey
Version : 2f86d6a1
Release : 5cf7cefb
Architecture: (none)
Install Date: Mon 01 Jun 2020 12:14:38 PM EDT
Group : Public Keys
Size : 0
License : pubkey
Signature : (none)
Source RPM : (none)
Build Date : Wed 05 Jun 2019 10:17:31 AM EDT
Build Host : localhost
Relocations : (not relocatable)
Packager : Fedora EPEL (8) <[email protected]>
Summary : gpg(Fedora EPEL (8) <[email protected]>)
Description :
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: rpm-4.14.2 (NSS-3)
...omitted... Il comando seguente viene utilizzato per rimuovere una chiave:
$ sudo rpm -e gpg-pubkey-2f86d6a1-5cf7cefb
Altre opzioni per la gestione delle chiavi sono descritte nella pagina man inclusa con rpmkey pacchetto.
YUM e DNF possono aggiungere chiavi al database RPM
Altri gestori di pacchetti rendono ancora più semplice la gestione delle chiavi. YUM e DNF utilizzano i file di configurazione in /etc/yum.repos.d per specificare un URL per la chiave GPG utilizzata per verificare i pacchetti in quel repository. Le utility possono quindi importare la chiave se non è già disponibile per la verifica.
Nel yum repo file di configurazione, la riga gpgcheck=1 indica che il controllo GPG deve essere eseguito per tutti i pacchetti in questo repository. È un valore booleano che può essere modificato nella configurazione o sovrascritto temporaneamente dalla riga di comando con il --nogpgcheck opzione.
Se la chiave pubblica GPG non è stata ancora importata in RPM quando inizia l'installazione di un pacchetto, allora yum (o dnf ) può avviare un'importazione della chiave. Il gpgkey=URI riga specifica l'origine della chiave da importare. Questa origine può essere qualsiasi URI, incluso un file locale o un collegamento Web remoto. Il yum o dnf l'utilità si interromperà e chiederà conferma per importare la chiave dopo aver mostrato l'ID chiave e l'impronta digitale.
warning: /var/cache/dnf/epel-fafd94c310c51e1e/packages/zsh-syntax-highlighting-0.7.1-1.el8.noarch.rpm: Header V3 RSA/SHA256 Signature, key ID 2f86d6a1: NOKEY
Extra Packages for Enterprise Linux 8 - x86_64 1.6 MB/s | 1.6 kB 00:00
Importing GPG key 0x2F86D6A1:
Userid : "Fedora EPEL (8) <[email protected]>"
Fingerprint: 94E2 79EB 8D8F 25B2 1810 ADF1 21EA 45AB 2F86 D6A1
From : /etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-8
Is this ok [y/N]: y La chiave viene aggiunta a RPM, quindi la verifica e l'installazione del pacchetto continuano.
Preparati a firmare un pacco
Se stai creando e distribuendo i tuoi file di pacchetto RPM, puoi firmare quei pacchetti con rpmsign utilità.
Il primo passaggio consiste nel creare una coppia di chiavi GPG per la firma. Assicurati di esportare e condividere anche la chiave pubblica. Per i pacchetti che verranno distribuiti pubblicamente, è una buona idea utilizzare una nuova coppia di chiavi e un portachiavi in una posizione condivisa. Inoltre, usa il --full-gen-key opzione e quindi scegli di creare una chiave di sola firma anziché quella predefinita, che crea sia una chiave di firma che di crittografia.
$ gpg --keyring /shared/rpm/.gpg --no-default-keyring --full-gen-key Anche se solo una persona sta usando la chiave per firmare i pacchetti, crea una coppia di chiavi separata da usare per la firma. Non utilizzare la stessa chiave per altre attività quotidiane come la crittografia delle e-mail personali.
Successivamente, dobbiamo installare il rpm-sign pacchetto e impostare un rpmmacros file che specifica la chiave da utilizzare. Il rpm-sign il pacchetto include una pagina man per rpmsign che descrive il processo. Nota che il nome del pacchetto ha un trattino che non fa parte del nome del comando.
$ sudo yum install rpm-sign
$ man rpmsign
I comandi RPM ottengono la loro configurazione da diversi rpmmacros File. C'è un file predefinito con molti campioni che si trova in /usr/lib/rpm/macros . Se più persone sono responsabili della firma dei pacchetti utilizzando la stessa chiave, inserisci un file di configurazione centrale in /etc/rpm/macros Posizione. Infine, per una persona specifica che firma i pacchetti, il ~/.rpmmacros dell'utente il file può essere configurato per puntare alla chiave GPG corretta.
La voce minima per rpmmacros file è specificare il nome della chiave. È possibile utilizzare un nome o l'ID chiave. Ottieni l'ID chiave con gpg --list-keys comando.
Suggerimento:esegui rpmsign comando prima di impostare il gpg_name variabile e il messaggio mostrerà il formato.
$ rpmsign --addsign my-custom-package.rpm
You must set "%_gpg_name" in your macro file
Oltre al nome della chiave, se il portachiavi si trova in un punto diverso dall'utente predefinito ~/.gnupg directory, usa il percorso_gpg variabile per impostare la posizione. Questo valore sarà lo stesso utilizzato con il --keyring opzione quando è stata creata la chiave.
Sono disponibili opzioni aggiuntive se il binario GPG o la sintassi dei comandi richiede qualcosa oltre i valori predefiniti previsti.
Firma e pubblica pacchetti
Ora sei pronto per firmare il pacchetto o i pacchetti. Secondo il rpmsign pagina man, il --addsign e --resign i comandi sono intercambiabili. Entrambi sostituiranno la parte della firma di un file del pacchetto RPM con le informazioni correnti.
Il comando seguente è un esempio di utilizzo di --addsign bandiera:
$ rpmsign --addsign myprod-2.x86_64.rpm myprod-libs-2.x86_64.rpm
Versioni precedenti di rpmbuild incluso un --sign opzione che potrebbe firmare il pacchetto durante il processo di compilazione se le chiavi GPG e rpmmacro i file sono stati configurati correttamente. Il --sign l'opzione è ora deprecata a favore del passaggio separato dell'utilizzo di rpmsign . Questo approccio incoraggia a creare, testare, firmare, pubblicare flusso di lavoro.
Infine, rendi disponibili ai client i pacchetti e la chiave pubblica GPG. Un'opzione è imitare il progetto EPEL e creare un file RPM che includa la chiave pubblica GPG e uno o più yum repo file che puntano alla posizione dei pacchetti firmati. Per le organizzazioni che ospitano pacchetti su un Red Hat Satellite Server, iniziare caricando la chiave pubblica GPG e quindi assegnando tale chiave al prodotto o al repository che contiene i pacchetti firmati. Tutti i pacchetti in un repository devono essere firmati con la stessa chiave. Questo è un motivo comune per cui gli amministratori di Satellite rinunciano ai pacchetti prima di caricarli.
Concludi
Ora che sai di più sulla gestione dei pacchetti RPM con GPG, puoi capire meglio come lavorare con rpm , yum e dnf .
Per ulteriori letture, consulta Protezione delle chiavi di firma RPM e le guide all'amministrazione e alla gestione dei contenuti nella documentazione di Red Hat Satellite.
[ Vuoi saperne di più sulla sicurezza? Consulta la checklist di sicurezza e conformità IT. ]