Exécutables signés sous Linux

Question

Pour des raisons de sécurité, il est souhaitable de vérifier l'intégrité du code avant son exécution, éviter les logiciels falsifiés par un attaquant.Donc ma question est

Comment signer du code exécutable et exécuter uniquement des logiciels fiables sous Linux ?

J'ai lu l'ouvrage de van Doom et coll., Conception et implémentation d'exécutables signés pour Linux, et celui d'IBM CCM (Client Linux de confiance) par Safford & Zohar.TLC utilise le contrôleur TPM, ce qui est bien, mais le document date de 2005 et je n'ai pas pu trouver d'alternatives actuelles.

Connaissez-vous d'autres options ?

MISE À JOUR:Et pour les autres OS ?OuvrirSolaris ?La famille BSD ?

Answer 1

Le DigSig noyau module implémente la vérification des fichiers binaires signés par un outil appelé bsign. Cependant, il n'y a pas eu de travaux depuis la version 2.6.21 du noyau Linux.

Answer 2

Je sais que c'est une question ancienne, mais je viens trouvé.

J'ai écrit support exécutable signé pour le noyau Linux (dans la version 2.4.3) un certain temps, et si l'ensemble toolchain en place pour executables de signature, la vérification des signatures au moment de execve(2), la mise en cache des informations de validation de signature (compensation de la validation lorsque le fichier a été ouvert pour l'écriture ou autrement modifiées), noyant les signatures dans les programmes ELF arbitraires, etc. Il a fait introduire des pénalités de performance lors de la première exécution de chaque programme (parce que le noyau a dû charger dans l'ensemble fichier, plutôt que la demande pages les pages nécessaires), mais une fois que le système était dans un état stable, il a bien fonctionné.

Mais nous avons décidé de cesser de poursuivre parce qu'il fait face à plusieurs problèmes qui étaient trop importants pour justifier la complexité:

• Nous avions soutien non encore construit pour signées bibliothèques . bibliothèques signées nécessiteraient de modifier également le chargeur de ld.so et le mécanisme de dlopen(3). Ce n'était pas impossible, mais ne compliquerait l'interface: devrions-nous le chargeur demander au noyau de valider une signature ou si le calcul se fait entièrement dans l'espace utilisateur? Comment peut-on protéger contre un processus strace(2)d si cette partie de la validation se fait dans l'espace utilisateur? Serions-nous obligés d'interdire strace(2) entièrement sur un tel système?

  Que ferions-nous à propos de qui fournissent leur propre chargeur ?

• Un grand nombre de programmes sont écrits dans des langues qui ne compilent pas aux objets ELF. Il faudrait fournir spécifique à la langue modifications à bash, perl, python, java, awk, sed, et ainsi de suite, pour chacun des interprètes de pouvoir aussi valider les signatures. Étant donné que la plupart de ces programmes sont le texte brut format libre, ils ne disposent pas de la structure qui a fait l'intégration des signatures numériques dans des fichiers d'objets ELF si facile. Où seraient les signatures être stockées? Dans les scripts? Dans les attributs étendus? Dans une base de données externe de signatures?

• De nombreux interprètes sont ouverts de ce qu'ils permettent; bash(1) peut communiquer avec des systèmes distants entièrement sur son propre à l'aide echo et /dev/tcp, et peut facilement être dupé dans l'exécution de tout un attaquant doit faire. Signé ou non, vous ne pouviez pas leur faire confiance une fois qu'ils étaient sous le contrôle d'un pirate informatique.

• Le facteur de motivation pour le soutien de executables signé vient de rootkits remplaçant le système fourni /bin/ps, /bin/ps, /bin/kill, et ainsi de suite. Oui, il y a d'autres raisons utiles d'avoir signé executables. Cependant, rootkits obtenu beaucoup plus impressionnant au fil du temps, avec beaucoup compter sur kernel hacks pour cacher leurs activités des administrateurs. Une fois que le noyau a été piraté, tout le jeu est terminé. En raison de la sophistication des rootkits les outils que nous avons l'espoir d'empêcher leur utilisation ont été Inoccupation faveur de la communauté de piratage.

• L'interface de chargement du module du noyau était grand ouvert. Une fois qu'un processus a root privilège, il était facile d'injecter un module de noyau sans aucun contrôle. Nous aurions pu également écrit un autre vérificateur pour les modules du noyau, mais était très primitive de l'infrastructure autour des modules du noyau.

Answer 3

Le modèle GNU/Linux/FOSS encourage en fait la falsification – en quelque sorte.Les utilisateurs et les créateurs de distribution doivent être libres de modifier (falsifier) ​​le logiciel en fonction de leurs besoins.Même la simple recompilation du logiciel (sans modifier le code source) pour la personnalisation est quelque chose qui se fait assez souvent, mais qui interromprait la signature de code binaire.En conséquence, le modèle de signature de code binaire n'est pas particulièrement bien adapté à GNU/Linux/FOSS.

Au lieu de cela, ce type de logiciel repose davantage sur la génération de signatures et/ou de hachages sécurisés des packages sources.En combinaison avec un modèle de distribution de packages fiable et fiable, cela peut être rendu tout aussi sécurisé (sinon plus, en termes de transparence du code source) que la signature de code binaire.

Answer 4

Jetez un oeil à ceci: http://linux-ima.sourceforge.net/

Il est pas encore signé, mais il permet encore la vérification.

Answer 5

Je peux répondre à la question dans une perspective Solaris 10 et 11 OS, tous les binaires sont signés. Pour vérifier l'utilisation de la signature 'elfsign' ...

$ elfsign verify -v /usr/bin/bash
elfsign: verification of /usr/bin/bash passed.
format: rsa_sha1.
signer: O=Oracle Corporation, OU=Corporate Object Signing, OU=Solaris Signed Execution, CN=Solaris 11.
signed on: Fri Oct 04 17:06:13 2013.

Oracle ont récemment ajouté un processus de démarrage vérifié pour Solaris 11 aussi, pour plus de détails voir - Solaris Vérifié Boot introduction

Il y a des fourches de qualité de production du code OpenSolaris, trois sont Illumos mérite d'être étudié, SmartOS et OmniOS.

Answer 6

Jetez un oeil à Medusa DS9 . Je jouais avec lui une longue ( long ) il y a le temps, mais si je me souviens bien, vous pouvez enregistrer les fichiers binaires spécifiques et toute modification n'a pas été autorisé au niveau du noyau. Bien sûr, il peut être remplacé par un accès local à la machine, mais il n'a pas été vraiment facile. Il y a un démon intelligent, appelé agent de police, tout vérifier ce qui se passe sur la machine et si quelque chose hors de l'ordinaire se produit, il commence à crier.

Answer 7

Je ne l'ai jamais essayé, mais jeter un oeil à: http: / /blog.codenoise.com/signelf-digitally-signing-elf-binaries . La solution fonctionne sans avoir besoin de soutien du noyau, et ressemble à être prêt à aller.

On peut trouver le code pour le signataire http://sourceforge.net/projects/signelf/

Il ne résout pas le « Exécuter uniquement le code de confiance sur linux » question, mais il ne résout en partie le problème en faisant un moyen pour que le programme lui-même détecter une éventuelle manipulation / corruption

Answer 8

http://en.wikipedia.org/wiki/PKCS

Utilisez un signe PKCS7 (S / MIME) de celui-ci. Générer votre propre cert / clé privée paire, auto-signer le cert puis signer votre fichier avec la clé privée et cert en utilisant PKCS7. Il va fixer le Cert, et il peut se vérifier lors de l'exécution en utilisant la commande OpenSSL (homme smime ou tout simplement faire de l'aide OpenSSL). Ceci est infalsifiable parce que même si la clé publique est dans les fichiers que vous donnez, la signature S / MIME pour cette clé publique ne peut être généré avec la clé privée que vous ne distribuer. Donc, si le fichier est signé par votre cert, il doit avoir été signé par une personne avec la clé privée et que vous n'avez pas donné la clé privée à tout le monde, il doit venir de vous.

Voici comment faire le certificat auto-signé.

http://www.akadia.com/services/ssh_test_certificate.html

Vous devez convaincre OpenSSL faire confiance à votre cert comme racine de l'autorité (-CAfile), puis vérifiez avec que la racine, et aussi vérifier que le certificat sur le fichier est le vôtre (Hacher le cert) et le contrôle le hachage. Notez que bien qu'il ne soit pas documenté, l'état de sortie de OpenSSL reflète la validité du signe que vous vérifiez lorsque vous faites un smime vérifier. Il est 0 si elle correspond, non nulle si elle ne fonctionne pas.

Notez que tout cela n'est pas sécurisé parce que si le chèque est dans votre code, ils peuvent tout simplement retirer le chèque s'ils veulent vous battre. La seule façon sûre de le faire serait d'avoir le vérificateur dans le système d'exploitation et avoir vérifier votre binaire et refuser de l'exécuter si elle n'est pas signé. Mais puisqu'il n'y a pas checker dans le système d'exploitation et Linux peut être modifié pour supprimer / by-pass de toute façon ... Ce que cela est vraiment bon pour est tout simplement détecter les fichiers corrompus plus que d'essayer de garder les gens de vous sans passer.

Answer 9

Je suis d'accord que la philosophie entourant Linux, GNU et al. tourne autour de bricoler. D'autre part, je crois aussi que certains systèmes méritent une protection contre les vulnérabilités telles que la falsification des logiciels, ce qui peut porter atteinte à la vie privée et l'intégrité des utilisateurs d'un système.

implémentations du noyau ne peuvent pas suivre le cycle de développement rapide du noyau lui-même. Je recommande plutôt de mettre en œuvre une forme de vérification de signature de fichier exécutable en utilisant les outils de l'espace utilisateur. La place executables dans une image d'archive ou système de fichiers et de signer l'image en utilisant une clé privée; si cette clé privée reste sur vos machines de développement (privé), lorsque votre serveur est piraté, les attaquants ont encore aucun moyen de signer leurs propres images et injecter son code sans tromper le système pour monter des images non signées. Elle se prolonge en outre le long de la chaîne:

• ont vos services contenus dans l'exécution-monté en lecture seule des images;
• a la machine s'enfuir d'un système de fichiers signé, en lecture seule;
• mettre en œuvre démarrage sécurisé sur vos machines, l'exécution d'un bootloader qui applique l'intégrité du support de démarrage;
• la confiance que les membres de votre organisation ne trafiquer vos machines.

Obtenir tout est bien un disque effort. Il est beaucoup plus simple de contourner tout en concevant votre système sous une autre approche:

• les utilisateurs de quarantaine du système. Ne pas introduire des moyens pour les utilisateurs d'exécuter des commandes sur votre système. Évitez les bombardements de l'intérieur des programmes qui reposent sur des données introduites par l'utilisateur.
• concevoir vos procédures de déploiement grâce à la gestion de la configuration et vous assurer que vos déploiements sont « reproductibles », ce qui signifie qu'ils conduisent au même résultat fonctionnel lorsque vous les déployer à plusieurs reprises. Cela vous permet de « nuke orbite » machines que vous croyez avoir été compromise.
• traiter vos machines comme si elles étaient compromis: exécuter régulièrement des audits pour vérifier l'intégrité de vos systèmes. Sauvegardez vos données sur les images séparées et redéployer les systèmes régulièrement. Inscrivez-vous et les images ont des systèmes rejettent des images non signés.
• utiliser des certificats: favoriser une approche « épinglage de certificat ». Ne déployer un certificat racine pour vos applications (qui fournira le rejet automatique des signatures qui ne sont pas certifiés par votre organisation), mais à tout le moins que le système gérer les empreintes digitales d'images et de notifier les administrateurs lorsque les empreintes digitales ont changé. Bien qu'il soit possible de mettre en œuvre toutes ces chaînes à l'aide de clés, l'authentification à base de certificats a été conçu pour cette application exacte.

Answer 10

Je me plais à penser à la sécurité comme une chaîne. Le maillon faible de la chaîne peut compromettre tout le système. Donc, la chose devient « empêcher un utilisateur non autorisé d'obtenir le mot de passe root ».

Comme suggéré par @DanMoulding la source du logiciel est également important et dans l'avenir les magasins probablement d'applications officielles OS sera la norme. Pensez à Play Store, les magasins Apple ou Microsoft.

  

Je pense que l'installation et la distribution de code malveillant caché est la   problème beaucoup plus insidieux. Après tout, afin de charger le mauvais code, il est   obtenu d'abord être installé sur le système quelque part. Plus de couches   la sécurité sont généralement mieux, bien sûr. La question est: est-il utile   le coût?

A mon avis, la réponse est « ça dépend ». Vous pouvez réduire le risque en adoptant un ensemble de politiques de sécurité comme suggéré par @sleblanc. Vous pouvez crypter votre système de fichiers ( https://en.wikipedia.org/wiki/Linux_Unified_Key_Setup ), utiliser en lecture seule pour les systèmes de fichiers binaires ou utiliser un mécanisme pour signer et vérifier les binaires.

Cependant quel que soit le mécanisme que vous utilisez il n'y a rien que vous pouvez faire une fois que l'accès root est obtenu par un attaquant. Les outils de vérification de signature peut être remplacée par une version trafiquée ou tout simplement désactivé et il n'a pas d'importance si les outils fonctionnent dans l'espace utilisateur ou l'espace noyau, une fois que la machine a été compromise (bien que ce dernier serait plus sûr bien sûr ).

Il serait bien si le noyau Linux pourrait intègre un module de vérification de signature et une autre couche de sécurité entre l'utilisateur root et le système d'exploitation.

Par exemple, c'est l'approche adoptée sur les versions récentes de macOS . Certains fichiers ne peuvent pas être modifiés (et lire parfois), même par le compte root et il y a des restrictions aussi sur les politiques et les modules du noyau (par exemple uniquement signé ou kext autorisé peut être chargé sur le système). de Windows adopté plus ou moins la même approche avec AppLocker .