14 votes

Validation de la confiance des signatures avec gpg ?

Nous aimerions utiliser des signatures gpg pour vérifier certains aspects de notre système outils de gestion de la configuration du système. De plus, nous aimerions utiliser un modèle de "confiance" dans lequel les clés individuelles des administrateurs et nos systèmes font confiance à cette clé principale (et à l'utilisateur). utilisent le "réseau de confiance" pour valider les signatures de nos administrateurs système).

Cela nous donne beaucoup de flexibilité, comme la possibilité de facilement révoquer la confiance sur une clé quand quelqu'un part, mais nous avons rencontré un problème. Alors que le gpg La commande dire à vous si une clé est non fiable, il ne semble pas retourner un code de sortie indiquant cette ce fait. Par exemple :

# 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 partie qui nous intéresse est la suivante :

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

Le code de sortie renvoyé par gpg dans ce cas est de 0, malgré la confiance de confiance :

# echo $?
0

Comment faire pour que gpg échoue dans le cas où quelque chose est signé avec une signature non fiable ?

J'ai vu certaines suggestions selon lesquelles le gpgv retournera un code de sortie correct, mais malheureusement, la commande gpgv ne sait pas comment récupérer les clés des serveurs de clés. Je suppose que nous pouvons analyser la sortie d'état (en utilisant --status-fd) de gpg mais y a-t-il un meilleur moyen ?

8voto

Eric Noob Points 531

Voilà ce que j'ai obtenu :

#!/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

Il recherche les informations de confiance qui gpg sorties sur --status-fd . Le script sort avec une erreur en présence d'une signature non fiable (ou invalide/aucune signature) :

$ 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

Le script sort sans erreur en présence d'une signature valide et fiable :

$ 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

5voto

Andre de Miranda Points 322

Laissez-moi donc essayer de diviser le problème :

Le premier problème semble être que la clé que vous testez n'est pas fiable.

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

J'ai supposé que c'était intentionnel... mais avant de voir comment réparer, laissez-moi vous suggérer d'utiliser gpgv 代わりに gpg -v ? Vous verrez pourquoi dans une minute :

$ 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

Pas de clé, pas de confiance... Non nous importons la clé dans 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

J'espère que cela vous aidera

1voto

Hamish Downer Points 9012

Deux options me viennent à l'esprit (autres que l'analyse syntaxique de la sortie).

Une façon rapide et sale serait d'exécuter les deux gpg y gpgv . La première série de gpg s'assurerait que la clé a été récupérée du serveur de clés, et ensuite gpgv vous donnera le code de retour que vous voulez.

Une manière plus élégante et contrôlée (bien qu'elle implique plus de travail) serait d'utiliser la fonction gpgme pour vérifier la signature. Il s'agit d'une bibliothèque C, bien qu'il existe des wrappers pour Perl , PHP , Python y Ruby . (Celui de Python est assez bas niveau, tandis que celui de Ruby a des abstractions de plus haut niveau, je ne suis pas sûr pour Perl ou PHP).

La bibliothèque GPGME semble communiquer avec les serveurs de clés lorsque je l'ai utilisée, mais vous devriez le confirmer. J'ai écrit un peu de code qui utilise la bibliothèque gpgme de ruby (recherche de verify y verified_ok? pour le code qui vérifie une signature, et pour sig_output_lines pour un code qui détermine si une signature est fiable).

-1voto

gWaldo Points 11827

Qu'en est-il de la migration de votre configuration système vers un outil comme Puppet ou Chef ?

Bien qu'il s'agisse d'une quantité de travail non triviale, Chef (je n'ai pas utilisé Puppet) vous devez créer des comptes d'utilisateurs (et des clés publiques/privées sont générées). Bien que cela n'empêche pas les gens de modifier les fichiers locaux sur le serveur, chef-client s'exécute périodiquement, et écrasera leurs changements lors de la prochaine exécution. (Les exécutions périodiques récurrentes se produisent par défaut).

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X