Exécutables signés sous Linux

Je me rends compte que c'est une question ancienne mais je viens juste de la trouver.

J'ai écrit le support des exécutables signés pour le noyau Linux (vers la version 2.4.3) il y a quelque temps, et j'avais toute la chaîne d'outils en place pour signer les exécutables, en vérifiant les signatures à execve(2) temps, la mise en cache des informations de validation de signature (effacement de la validation lorsque le fichier a été ouvert pour écriture ou autrement modifié), intégration des signatures dans des programmes ELF arbitraires, etc. Cela a introduit des pénalités de performances lors de la première exécution de chaque programme (car le noyau a dû charger dans l'intégralité fichier, plutôt que de simplement demander les pages nécessaires), mais une fois que le système était dans un état stable, cela fonctionnait bien.

Mais nous avons décidé d'arrêter de le poursuivre car il rencontrait plusieurs problèmes trop importants pour justifier sa complexité :

• Nous n'avions pas encore construit de support pour les bibliothèques signées . Les bibliothèques signées nécessiteraient également de modifier le ld.so chargeur et le dlopen(3) mécanisme. Ce n'était pas impossible mais compliquait l'interface :fallait-il que le chargeur demande au noyau de valider une signature ou bien le calcul devait-il se faire entièrement en espace utilisateur ? Comment se protéger contre un strace(2) d processus si cette partie de la validation est effectuée dans l'espace utilisateur ? Serions-nous obligés d'interdire strace(2) entièrement sur un tel système ?

  Que ferions-nous des programmes qui fournissent leur propre chargeur ?

• Un grand nombre de programmes sont écrits dans des langages qui ne se compilent pas en objets ELF. Nous aurions besoin de fournir des informations spécifiques à la langue modification de bash , perl , python , java , awk , sed , et ainsi de suite, pour que chacun des interprètes puisse également valider les signatures. Étant donné que la plupart de ces programmes sont en texte brut au format libre, ils n'ont pas la structure qui a facilité l'intégration des signatures numériques dans les fichiers objets ELF. Où les signatures seraient-elles stockées ? Dans les scripts ? Dans les attributs étendus ? Dans une base de données externe de signatures ?

• De nombreux interprètes sont grands ouverts sur ce qu'ils autorisent ; bash(1) peut communiquer avec des systèmes distants entièrement par lui-même en utilisant echo et /dev/tcp , et peut facilement être amené à exécuter tout ce qu'un attaquant doit faire. Signés ou non, vous ne pouviez pas leur faire confiance une fois qu'ils étaient sous le contrôle d'un pirate informatique.

• La principale motivation pour la prise en charge des exécutables signés provient des rootkits remplaçant le /bin/ps fourni par le système , /bin/ps , /bin/kill , etc. Oui, il existe d'autres raisons utiles d'avoir des exécutables signés. Cependant, les rootkits sont devenus beaucoup plus impressionnants au fil du temps, beaucoup s'appuyant sur le noyau hacks pour cacher leurs activités aux 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 espérions empêcher d'être utilisés tombaient en disgrâce dans la communauté des hackers.

• L'interface de chargement des modules du noyau était largement ouverte. Une fois qu'un processus a root privilège, il était facile d'injecter un module du noyau sans aucune vérification. Nous aurions également pu écrire un autre vérificateur pour les modules du noyau, mais l'infrastructure du noyau autour des modules était très primitive.

Le modèle GNU/Linux/FOSS encourage en fait la falsification -- en quelque sorte. Les utilisateurs et les distributeurs doivent être libres de modifier (altérer) le logiciel en fonction de leurs besoins. Même la simple recompilation du logiciel (sans changer le code source) pour la personnalisation est quelque chose qui se fait assez souvent, mais casserait la signature du code binaire. Par conséquent, 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 source. En combinaison avec un modèle de distribution de paquets fiable et de confiance, cela peut être rendu tout aussi sécurisé (sinon plus, vis-à-vis de la transparence dans le code source) que la signature de code binaire.

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

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

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