Convalida della fiducia delle firme con gpg?


13

Vorremmo usare le firme gpg per verificare alcuni aspetti dei nostri strumenti di gestione della configurazione del sistema. Inoltre, vorremmo utilizzare un modello di "trust" in cui le singole chiavi sysadmin sono firmate con una chiave di firma master, e quindi i nostri sistemi si fidano di quella chiave master (e utilizzano la "rete di fiducia" per convalidare le firme dei nostri amministratori di sistema).

Questo ci dà molta flessibilità, come la possibilità di revocare facilmente la fiducia su una chiave quando qualcuno lascia, ma abbiamo riscontrato un problema. Mentre il gpgcomando ti dirà se una chiave non è attendibile, non sembra restituire un codice di uscita che indica questo fatto. Per esempio:

# gpg -v < foo.asc
Version: GnuPG v1.4.11 (GNU/Linux)
gpg: armor header: 
gpg: original file name=''
this is a test
gpg: Signature made Fri 22 Jul 2011 11:34:02 AM EDT using RSA key ID ABCD00B0
gpg: using PGP trust model
gpg: Good signature from "Testing Key <someone@example.com>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: ABCD 1234 0527 9D0C 3C4A  CAFE BABE DEAD BEEF 00B0
gpg: binary signature, digest algorithm SHA1

La parte che ci interessa è questa:

gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.

Il codice di uscita restituito da gpg in questo caso è 0, nonostante l'errore di fiducia:

# echo $?
0

Come possiamo far fallire gpg nel caso in cui qualcosa sia firmato con una firma non attendibile?

Ho visto alcuni suggerimenti secondo cui il gpgvcomando restituirà un codice di uscita corretto, ma sfortunatamente gpgvnon sa come recuperare le chiavi dai server di chiavi. Suppongo che possiamo analizzare l'output di stato (usando --status-fd) da gpg, ma c'è un modo migliore?

Risposte:


6

Questo è ciò che è finito con:

#!/bin/sh

tmpfile=$(mktemp gpgverifyXXXXXX)
trap "rm -f $tmpfile" EXIT

gpg --status-fd 3 --verify "$@" 3> $tmpfile || exit 1
egrep -q '^\[GNUPG:] TRUST_(ULTIMATE|FULLY)' $tmpfile

Questo cerca le informazioni sulla fiducia che gpgproducono --status-fd. Lo script esce con un errore in presenza di una firma non attendibile (o firma non valida / nessuna):

$ sh checksig sample.sh.bad 
gpg: Signature made Mon 24 Jun 2013 11:42:58 AM EDT using RSA key ID DCD5C569
gpg: Good signature from "Test User <testuser@example.com>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 6FCD 3CF0 8BBC AD50 662E  5070 E33E D53C DCD5 C569
$ echo $?
1

Lo script si chiude senza errori in presenza di una firma valida e attendibile:

$ sh checksig sample.sh.good
gpg: Signature made Mon 24 Jun 2013 11:38:49 AM EDT using RSA key ID 5C2864A8
gpg: Good signature from "Lars Kellogg-Stedman <...>"
$ echo $?
0

5

Quindi fammi provare a dividere il problema:

Il primo problema sembra che la chiave con cui stai testando non sia attendibile.

gpg -v < test.txt.asc 
gpg: armor header: Version: GnuPG v1.4.11 (GNU/Linux)
gpg: original file name='test.txt'
this is a test
gpg: Signature made Thu 11 Aug 2011 09:09:35 PM EST using RSA key ID FE1B770E
gpg: using PGP trust model
gpg: Good signature from "John Doe <jdoe@noemail.com>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 5DD8 216D ADB1 51E8 4326  3ACA 1DED BB72 FE1B 770E
gpg: binary signature, digest algorithm SHA1

Ho pensato che questo fosse intenzionale ... ma prima di arrivare a come risolvere, lascia che ti suggerisca di usare gpgv invece di gpg -v ? Vedrai perché tra un minuto:

$ gpgv < test.txt.asc 
gpgv: keyblock resource `/user/.gnupg/trustedkeys.gpg': file open error
gpgv: Signature made Thu 11 Aug 2011 09:09:35 PM EST using RSA key ID FE1B770E
gpgv: Can't check signature: public key not found

$ echo $?
2

Nessuna chiave, nessuna fiducia ... No importiamo la chiave in trustedkeys.gpg

$ gpg --no-default-keyring --keyring trustedkeys.gpg --import jdoe_pub.gpg
gpg: keyring `/user/.gnupg/trustedkeys.gpg' created
gpg: key FE1B770E: public key "John Doe <jdoe@noemail.com>" imported
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)
$ gpgv < test.txt.asc 
gpgv: Signature made Thu 11 Aug 2011 09:09:35 PM EST using RSA key ID FE1B770E
gpgv: Good signature from "John Doe <jdoe@noemail.com>"

$ echo $?
0

Spero che sia d'aiuto


Ho commentato gpgv nella mia domanda: il problema con gpgv è che mentre restituisce un codice di errore più utile, non sa come recuperare le chiavi da un server di chiavi.
Larks

1

Vengono in mente due opzioni (oltre all'analisi dell'output).

Un modo rapido e sporco sarebbe quello di eseguire entrambi gpg e gpgv. La prima esecuzione di gpgassicurerà che la chiave sia stata prelevata dal keyserver e quindi gpgvti fornirà il codice di ritorno desiderato.

Un modo più elegante e controllato (sebbene implichi più lavoro) sarebbe quello di utilizzare la libreria gpgme per verificare la firma. È una libreria C, sebbene esistano wrapper per Perl , PHP , Python e Ruby . (Quello di Python è di livello piuttosto basso, mentre quello di Ruby ha alcune astrazioni di livello superiore, non sono sicuro di Perl o PHP).

La libreria GPGME sembra parlare con i server di chiavi quando l'ho usata, sebbene tu voglia confermarlo. Ho scritto un po 'di codice che utilizza la libreria ruby ​​gpgme (cerca verifye verified_ok?cerca il codice che verifica una firma, e un po' di codicesig_output_lines per capire se una firma è attendibile).


-1

Che dire della migrazione della configurazione del sistema su uno strumento come Puppet o Chef ?

Mentre una quantità non banale di lavoro, Chef (non ho usato Puppet) è necessario creare account utente (e vengono generate le chiavi pub / private). Sebbene ciò non impedisca alle persone di modificare i file locali sul server, chef-client viene eseguito periodicamente e sovrascriveranno le modifiche alla successiva esecuzione. (Le esecuzioni periodiche ricorrenti si verificano per impostazione predefinita.)

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.