Exécutables signés sous Linux
Pour des raisons de sécurité, il est souhaitable de vérifier l'intégrité du code avant exécution, en évitant les logiciels falsifiés par un attaquant. Donc, ma question est
_ {Comment signer un code exécutable et exécuter uniquement un logiciel approuvé sous Linux?
J'ai lu le travail de van Doom et autres, Conception et implémentation d'exécutables signés pour Linux, et le TLC (Client de confiance de Linux) d'IBM de Safford & Zohar. TLC utilise le contrôleur TPM, c'est-à-dire Nice, mais le document date de 2005 et je n'ai pas pu trouver d'alternatives actuelles.
Connaissez-vous une autre option?
UPDATE: Et à propos des autres systèmes d'exploitation? OpenSolaris? Famille BSD?
Le module DigSig kernel implémente la vérification des fichiers binaires signés par un outil appelé bsign. Cependant, aucun travail n’a été effectué depuis la version 2.6.21 du noyau Linux.
Je réalise que c'est une question ancienne mais je viens de la trouver.
J'ai écrit il y a quelque temps déjà que le support d'exécutable signé pour le noyau Linux (autour de la version 2.4.3) était en place, et j'avais tout le chaînage d'outils en place pour signer les exécutables, vérifier les signatures à execve(2), mettre en cache les informations de validation de la signature ouvert pour écrire ou autrement modifié), incorporant les signatures dans des programmes ELF arbitraires, etc. Il introduisit quelques pénalités de performance lors de la première exécution de chaque programme (car le noyau devait charger dans le fichier entier , plutôt que de simplement demander page 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 le poursuivre car il était confronté à plusieurs problèmes trop importants pour justifier la complexité:
Nous n'avions pas encore construit le support pour bibliothèques signées . Les bibliothèques signées nécessiteraient également de modifier le chargeur
ld.soet le mécanismedlopen(3). Ce n'était pas impossible, mais compliquait l'interface: le chargeur devrait-il demander au noyau de valider une signature ou le calcul devrait-il être effectué entièrement dans l'espace utilisateur? Comment se protéger contre un processusstrace(2)d si cette partie de la validation est effectuée dans l'espace utilisateur? Serions-nous obligés d'interdirestrace(2)entièrement sur un tel système?Que ferions-nous à propos de programmes qui fournissent leur propre chargeur ?
Un grand nombre de programmes sont écrits dans des langages qui ne sont pas compilés en objets ELF. Nous aurions besoin de fournir langue-spécifique modifications à
bash,Perl,python,Java,awk,sed, et ainsi de suite, pour que chacun des interprètes puisse également valider des signatures . Étant donné que la plupart de ces programmes sont du texte brut au format libre, ils ne possèdent pas la structure qui facilite l’intégration de signatures numériques dans des fichiers d’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?Beaucoup d'interprètes sont grand ouverts à propos de ce qu'ils permettent;
bash(1)peut communiquer avec les systèmes distants entièrement par lui-même à l'aide deechoet/dev/tcp, et peut facilement être amené à exécuter tout ce qu'un attaquant a besoin de faire. Signé ou non, vous ne pouviez plus leur faire confiance une fois qu’ils étaient sous le contrôle d’un pirate informatique.Le principal facteur de motivation pour la prise en charge des exécutables signés provient des rootkits remplaçant les
/bin/ps,/bin/ps,/bin/kill, etc. fournis par le système. Oui, il y a d'autres raisons utiles d'avoir des exécutables signés. Cependant, les rootkits sont devenus de plus en plus impressionnants au fil du temps, nombre d’entre eux s’appuyant sur kernel hacks pour cacher leurs activités aux administrateurs. Une fois que le noyau a été piraté, le jeu est terminé. En raison de la sophistication des rootkits, les outils que nous espérions éviter d’être utilisés n’étaient plus très appréciés par la communauté des pirates informatiques.L'interface de chargement du module du noyau était grande ouverte. Une fois qu'un processus a le privilège
root, il était facile d'injecter un module du noyau sans aucune vérification. Nous aurions pu aussi é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 réalité la falsification - en quelque sorte. Les utilisateurs et distributeurs doivent être libres de modifier (altérer) le logiciel en fonction de leurs besoins. Même la simple recompilation du logiciel (sans changer de code source) pour la personnalisation est quelque chose qui est fait assez souvent, mais qui casserait la signature de code binaire. En conséquence, le modèle de signature de code binaire n'est pas particulièrement 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, ceci peut être rendu aussi sécurisé (sinon plus, vis-à-vis de la transparence dans le code source) que la signature de code binaire.
Regardez ceci: http://linux-ima.sourceforge.net/
Il ne signe pas encore, mais il permet toujours la vérification.
Je peux répondre à la question du point de vue du SE Solaris 10 et 11: tous les fichiers binaires sont signés. Pour vérifier la signature, utilisez '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 a récemment ajouté un processus de démarrage vérifié pour Solaris 11. Pour plus d'informations, voir - Introduction au démarrage vérifié Solaris
Il existe certaines fourchettes de classe production du code OpenSolaris. Trois d’entre elles méritent d’être explorées sont Illumos, SmartOS et OmniOS.
Jetez un coup d'oeil à Medusa DS9 . J'y ai joué il y a longtemps ( long ), mais si je me souviens bien, vous pouvez enregistrer des fichiers binaires spécifiques et toute modification n'est pas autorisée au niveau du noyau. Bien sûr, il peut être remplacé par un accès local à la machine, mais ce n’était pas vraiment facile. Il existe un démon intelligent, appelé constable, vérifiant tout ce qui se passe sur la machine et si quelque chose d'extraordinaire se produit, il se met à crier.
Je ne l'ai jamais essayé, mais jetez un coup d'œil à: http://blog.codenoise.com/signelf-digitally-signing-elf-binaries . La solution fonctionne sans avoir besoin du support du noyau et semble prête à fonctionner.
Le code du signataire peut être trouvé à http://sourceforge.net/projects/signelf/
Cela ne résout pas la question "Exécuter uniquement le code de confiance sur Linux", mais cela résout partiellement le problème en permettant au programme de se détecter lui-même d'une éventuelle falsification/corruption.
http://en.wikipedia.org/wiki/PKCS
Utilisez un signe PKCS7 (S/MIME). Générez votre propre paire cert/clé privée, auto-signez le cert, puis signez votre fichier avec la clé privée et le cert à l'aide de PKCS7. Il attache le certificat à celui-ci, puis il peut se vérifier au moment de l'exécution à l'aide de la commande openssl (man smime ou tout simplement faire de l'aide openssl). Ceci est inviolable car même si la clé publique se trouve dans les fichiers que vous distribuez, la signature S/MIME pour cette clé publique ne peut être générée qu'avec la clé privée que vous ne distribuerez pas. Donc, si le fichier est signé par votre certificat, il doit avoir été signé par une personne possédant la clé privée et, comme vous n'avez pas donné cette clé à qui que ce soit, il doit provenir de vous.
Voici comment créer le certificat auto-signé.
http://www.akadia.com/services/ssh_test_certificate.html
Vous devrez convaincre openssl de faire confiance à votre certificat en tant que racine d’autorité (-CAfile), puis de le vérifier en tant que racine et de vérifier que le certificat du fichier vous appartient (hachage du certificat) et de vérifier le hachage. Notez que, même si cela n’est pas documenté, le statut de sortie d’openssl reflète la validité du signe que vous vérifiez lors de la vérification smime. C'est 0 si cela correspond, non nul si ce n'est pas le cas.
Notez que tout cela n’est pas sécurisé car si la vérification est dans votre code, ils peuvent simplement supprimer la vérification s’ils veulent vous battre. Le seul moyen sûr de le faire serait d’avoir le vérificateur dans le système d’exploitation et de le faire vérifier votre fichier binaire et de le refuser s’il n’est pas signé. Mais comme il n’existe pas de vérificateur dans le système d’exploitation et que linux peut être modifié pour le supprimer/le contourner de toute façon ... C’est vraiment bon pour la détection des fichiers corrompus plus que pour empêcher les gens de vous contourner.
J'aime penser à la sécurité en tant que chaîne. Le maillon plus faible de la chaîne peut compromettre l’ensemble du système. Ainsi, le tout devient " empêchant un utilisateur non autorisé d’obtenir le mot de passe root ".
Comme suggéré par @DanMoulding, la source du logiciel est également importante et, à l'avenir, les magasins d'applications OS officiels seront probablement la norme. Pensez aux magasins Play Store, Apple ou Microsoft.
Je pense que l’installation et la distribution de code malveillant caché est le problème beaucoup plus insidieux. Après tout, pour charger un code incorrect, il faut d’abord l’installer quelque part sur le système. Bien entendu, plus de niveaux de sécurité sont généralement meilleurs. La question est: cela en vaut-il le coût?
À mon avis, la réponse est "ça dépend". Vous pouvez réduire les risques en adoptant un ensemble de stratégies de sécurité, comme suggéré par @sleblanc. Vous pouvez chiffrer votre système de fichiers ( https://en.wikipedia.org/wiki/Linux_Unified_Key_Setup ), utiliser des systèmes de fichiers en lecture seule pour les fichiers binaires ou utiliser un mécanisme pour signer et vérifier les fichiers binaires.
Cependant, quel que soit le mécanisme que vous utilisez, vous ne pouvez rien faire une fois que l'accès root est obtenu par un attaquant. Les outils de vérification de signature peuvent être remplacés par une version altérée ou tout simplement désactivée. Peu importe que les outils s’exécutent dans l’espace utilisateur ou dans l’espace noyau une fois que la machine a été compromise (bien que cette dernière soit plus sécurisée, bien sûr). ).
Il serait donc agréable que le noyau Linux puisse intégrer 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, il s’agit de l’approche adoptée pour les versions récentes macOS. Certains fichiers ne peuvent pas être modifiés (et parfois lus) même par le compte root et des restrictions sont également imposées sur les stratégies et les modules du noyau (par exemple, seul le kext signé ou autorisé peut être chargé sur le système). Windows a adopté plus ou moins la même approche avec AppLocker.
Je conviens que la philosophie autour de Linux, GNU et al. tourne autour du bricolage. D'autre part, je pense également que certains systèmes méritent une protection contre des vulnérabilités telles que la falsification de logiciels, qui peuvent porter atteinte à la confidentialité et à l'intégrité des utilisateurs d'un système.
Les implémentations de 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 la signature du fichier exécutable à l'aide des outils de l'espace utilisateur. Placez les exécutables dans une image d'archive ou de système de fichiers et signez-la à l'aide d'une clé privée. si cette clé privée reste sur vos machines de développement (private), lorsque votre serveur est piraté, les attaquants n'ont toujours aucun moyen de signer leurs propres images et d'injecter leur code sans inciter le système à monter des images non signées. Il s'étend plus loin dans la chaîne:
- insérez vos services dans des images en lecture seule montées au moment de l'exécution;
- faire fonctionner la machine à partir d'un système de fichiers signé en lecture seule;
- implémentez un démarrage sécurisé sur vos machines, en exécutant un chargeur de démarrage qui applique l'intégrité du support de démarrage;
- avoir confiance que les membres de votre organisation ne toucheront pas à vos machines.
Bien faire les choses est une entreprise difficile. Il est beaucoup plus simple de contourner tout cela en concevant votre système sous une autre approche:
- mettre en quarantaine les utilisateurs du système. N'introduisez pas de moyen permettant aux utilisateurs d'exécuter des commandes sur votre système. Évitez de vous faufiler à l'intérieur des programmes qui reposent sur des données fournies par l'utilisateur.
- concevez vos procédures de déploiement à l'aide de la gestion de la configuration et assurez-vous que vos déploiements sont "reproductibles", ce qui signifie qu'ils conduisent au même résultat fonctionnel lorsque vous les déployez plusieurs fois. Cela vous permet de "neutraliser les machines en orbite" que vous pensez avoir été compromises.
- traitez vos machines comme si elles étaient compromises: effectuez régulièrement des audits pour vérifier l'intégrité de vos systèmes. Sauvegardez vos données sur des images séparées et redéployez les systèmes régulièrement. Signez des images et demandez aux systèmes de rejeter les images non signées.
- utiliser des certificats: privilégier une approche "épinglage de certificat". Déployez un certificat racine pour vos applications (ce qui entraînera le rejet automatique des signatures qui n'ont pas été certifiées par votre organisation) mais demandez au moins au système de gérer les empreintes digitales des images actuelles et d'avertir les administrateurs lorsque ces dernières ont changé. Bien qu'il soit possible d'implémenter tout cela à l'aide de chaînes de clés, l'authentification par certificat a été conçue pour cette application précise.