Existe-t-il des systèmes d'exploitation qui vérifient les signatures de programme avant de les exécuter?
Si oui, quels sont ces OS? Sont-ils spécialement conçus? Est-il difficile d'appliquer ce type de vérification de programme aux systèmes d'exploitation courants que nous utilisons?
Sinon, pourquoi les gens n'ont-ils pas inventé de tels systèmes d'exploitation?
La vérification de signature de package est assez courante avec les gestionnaires de packages d'aujourd'hui. Ce que je demande, c'est une vérification de signature au moment du chargement.
iOS et Android tous les deux valident la signature de chaque morceau de code avant de les charger en mémoire.
Les applications Windows UWP sont également toutes vérifiées pour la signature avant d'être également chargées.
La vérification de signature de package est assez courante avec les gestionnaires de packages d'aujourd'hui. Ce que je demande, c'est une vérification de signature au moment du chargement.
La différence est énorme en termes de performances. Une signature de package est vérifiée lors de son installation et non après.
Pour être efficace, la signature de code doit être vérifiée pour chaque binaire avant son exécution ou son chargement.
De plus, une attention particulière doit être apportée par le système d'exploitation (ou l'environnement d'exécution) afin de s'assurer qu'une page mémoire marquée comme exécutable est signée (ou, au moins, qui a été chargée à partir de quelque chose qui a été correctement signé). Cette exigence est extrêmement difficile à appliquer dans tout environnement qui n'a pas été conçu avec la signature de code à l'esprit, car il a tendance à casser beaucoup de code hérité.
Pourquoi tous les OS ne vérifient-ils pas la signature des programmes? Tout simplement parce qu'au début, la plupart des programmes étaient écrits et compilés localement, et encore aujourd'hui, certaines applications métier sont spécifiquement conçues localement. Beaucoup de programmes de haute qualité sont distribués comme source et peut être compilés localement. Cela a souvent du sens sur les serveurs haute performance car les options de compilation peuvent être utilisées pour modifier un programme pour des besoins spécifiques. Si vous ne pouviez utiliser que l'exécutable signé de sources connues, tout cela ne serait pas possible.
Bien sûr, pour un système d'exploitation destiné aux utilisateurs finaux comme Android ou iOS, les choses vont différemment, et il est logique d'autoriser uniquement les exécutables installés à partir de sources bien connues.
Mais même sur ma box Windows, je serais très déçu si je ne pouvais pas écrire, construire et exécuter un programme en C ou C++ ...
AppLocker , qui peut parfois restreindre l'exécution de l'application à une liste blanche basée sur des attributs définis par l'administrateur, y compris le nom d'éditeur d'une signature ou le hachage d'un fichier spécifique. .
Le plus gros problème est bien sûr les frais généraux d'administration, qui doivent spécifiquement mettre sur liste blanche tous les programmes dont un utilisateur pourrait avoir besoin. De plus, de nombreux éditeurs ne signent pas leurs applications. Et bien sûr, ce n'est pas une solution infaillible - par exemple un bogue dans un programme sur liste blanche pourrait encore être exploité pour exécuter du code arbitraire1.
En fait, la signature de l'exécutable n'est même pas la partie importante. La liste blanche peut être implémentée par chemin d'accès pour toute la différence qu'elle fait - ce qui est important dans ce schéma est que l'utilisateur n'a aucune autorisation d'écriture dans le répertoire du programme2. En supposant que cela soit vrai, quel avantage la vérification au moment de l'exécution offre-t-elle par rapport à la vérification au moment de l'installation? Personne ne peut changer le programme installé. Si le vecteur d'attaque est l'édition hors ligne de fichiers, le chiffrement complet du disque est la bonne réponse.
1 La plupart de ces bogues ne seraient pas considérés comme graves dans un environnement normal, où ils n'entraîneraient pas une élévation de privilèges. W ^ X peut toujours être contourné avec ROP .
2 Même la vérification de la signature de l'exécutable manquera par défaut les modules externes (par exemple les bibliothèques liées dynamiquement). Et permettre cela peut avoir des impacts significatifs sur les performances .
Linux possède déjà les mécanismes nécessaires dans le noyau (depuis la version 3.7), appelés IMA :
Les objectifs du sous-système d'intégrité du noyau sont de détecter si des fichiers ont été accidentellement ou malicieusement modifiés, à distance et localement, d'évaluer la mesure d'un fichier par rapport à une "bonne" valeur stockée en tant qu'attribut étendu et d'appliquer l'intégrité du fichier local. Ces objectifs sont complémentaires aux protections MAC (Mandatory Access Control) fournies par les modules LSM, tels que SElinux et Smack, qui, selon la politique, peuvent tenter de protéger l'intégrité des fichiers.
Avec IMA, les fichiers sensibles peuvent être étiquetés "immuables" (ce que vous feriez avec des fichiers exécutables), ce qui les signe avec une clé RSA spéciale. La signature est validée lors de l'accès aux fichiers, ce qui empêche toute falsification hors ligne. L'exécution de fichiers qui ne sont pas immuables peut être interdite via les politiques SElinux.
Bien sûr, l'utilisabilité d'un tel système est réduite. Pour créer et exécuter vos propres fichiers sur un tel système, vous aurez besoin d'une clé privée de confiance pour les signer en premier. Les mises à niveau logicielles sont susceptibles de nécessitent un redémarrage afin de mettre à jour les fichiers immuables avant qu'ils ne soient verrouillés.
La vérification du temps de chargement est très coûteuse et n'est pas infaillible.
Existe-t-il des systèmes d'exploitation qui vérifient les signatures de programme avant de les exécuter?
[~ # ~] modifier [~ # ~] : Comme indiqué dans les commentaires, ces systèmes d'exploitation. ChromeOS pour par exemple.
Si oui, quels sont ces OS? Sont-ils spécialement conçus? Est-il difficile d'appliquer ce type de vérification de programme aux systèmes d'exploitation courants que nous utilisons?
Il est assez difficile de vérifier un programme au moment du chargement. De plus, même si vous le faites avec succès, une fois qu'un programme a été lancé, l'attaquant peut toujours donner une entrée malformée et provoquer des ravages (débordements de tampon). Cela dit, il existe des modules logiciels qui vérifient leurs signatures au moment du chargement (attestation logicielle, par exemple OpenSSL compatible FIPS). Avoir un système d'exploitation pour chaque processus coûte très très cher.
À mesure que l'attention se tourne vers le cloud computing, vous voudrez vous assurer que vous êtes en mesure d'exécuter des logiciels de haute assurance sur des systèmes même non fiables. Je dirais que peu de recherches seraient effectuées sur la protection du système contre les logiciels qui y sont exécutés. Au lieu de cela, l'accent sera davantage mis sur le calcul de confiance, même dans un environnement non approuvé. Vous pouvez avoir une chaîne de confiance de base comme une attestation système ou logicielle (reportez-vous au lien du bas) si vous le souhaitez au moment du chargement. L'important serait de s'assurer que le logiciel n'est pas compromis au moment de l'exécution.
Regardez cette discussion: n programme interprété en cours d'exécution peut-il prouver de manière cryptographique qu'il est identique à une version de code source publiée?
De nombreuses réponses mentionnent des systèmes d'exploitation généraux ayant un support relativement récent, mais je ne vois aucune mention des TPM et du Trusted Computing Group . Un module de plateforme sécurisée fournit le matériel minimum nécessaire pour effectuer une exécution signée avec une chaîne d'intégrité à partir du démarrage du micrologiciel en tant que module de carte mère standard de qualité grand public. Il fonctionne en permettant aux étapes de démarrage d'étendre les registres de hachage avec des mesures de chaque étape suivante avant l'exécution, puis en fournissant un mécanisme de magasin de clés verrouillé qui peut être conditionnel à ces valeurs de registre de hachage.
Avec le TPM résolvant le problème Chicken and Egg pour l'ICP et le démarrage précoce, l'accès aux ressources pouvait être limité aux logiciels autorisés dans une politique spécifique dans la mesure où ce code était lui-même sans exploitation. Sans démarrage vérifié, la vérification des signatures d'exécution n'a aucun intérêt sans aucune raison de croire que le système et la stratégie PKI ne sont pas modifiés.
À ma connaissance (qui n'est pas à jour), seuls Apple et Google avaient suffisamment de contrôle sur leurs plates-formes matérielles pour expérimenter avec des TPM par défaut et je ne pense pas non plus avoir implémenté un TCG complet style de démarrage vérifié. Mais la menace d'être abandonné par une adoption soudaine de ces nouveaux appareils a poussé les fournisseurs de systèmes d'exploitation à commencer à implémenter certains composants d'intégrité d'exécution.
NetBSD a veriexec.
https://wiki.netbsd.org/guide/veriexec/
https://www.netbsd.org/docs/guide/en/chap-veriexec.html
Il est très bien adapté aux serveurs accessibles sur Internet, avec un niveau de sécurité élevé ( https://wiki.netbsd.org/kernel_secure_levels/#index2h1 ).
Microsoft Windows 7+ peut être configuré pour autoriser uniquement l'exécution des programmes signés Authenticode.
Mais vous devez comprendre que cela signifie uniquement que vous savez qui a créé le virus qui a détruit votre ordinateur. Ce n'est pas vraiment une fonction de sécurité, car elle ne vous dit rien sur une application qu'elle est signée. Oui, vous savez que $ RANDOM_GUY de Chine, d'Ukraine, d'Angola, où qu'il soit créé. Mais à quoi cela vous servirait-il vraiment si vos précieuses données sont chiffrées et que $ RANDOM_GUY demande 20BTC pour les déchiffrer. Et si le logiciel vole toutes vos données, à quoi cela vous fera-t-il de savoir que $ RANDOM_GUY les a probablement volées?
Premièrement, je suis clairement un non-expert sur tout ce que je vais dire, alors soyez prudent ...
Dans le monde du logiciel libre dans lequel je vis, les gens travaillent sur versions reproductibles . L'objectif est que chaque fichier binaire téléchargé puisse être vérifié par l'utilisateur lui-même en le construisant. Beaucoup distributions et projets logiciels s'y intéressent. Si je me souviens bien, cette idée a été lancée par les bitcoins et suivie par le projet tor.
D'après ce que j'ai entendu, certaines personnes ont suggéré qu'après que suffisamment de packages soient reproductibles, le hachage pourrait être partagé de certaines manières p2p. Donc, pour répondre à votre question, à mon avis, au moment du chargement, un vérificateur peut simplement hacher le binaire et vérifier s'il correspond au hachage publié par les autres, bien que cela puisse être lent en fonction de la vitesse de votre connexion Internet (peut-être que la connexion doit passer par tor).
De plus, il se trouve que je connais 2 distributions plus que d'autres, je vais donc en dire plus avec elles:
D'après ce que j'ai entendu, Debian fera de reproductible-build une exigence de politique après que suffisamment de paquets soient reproductibles.
Guix implémente la commande guix challenge afin que l'on puisse vérifier le hachage de votre build local avec le build officiel sur Hydra.
Je ne suis pas un "expert" mais juste un utilisateur commun de certains des outils.
Partage sur les versions reproductibles un peu plus et que les commentaires n'étaient pas au bon endroit, d'où le partage ici. D'après le peu que je comprends, utilisé et expérimenté, ce qu'il fait vous donne un package .deb avec un fichier texte .buildinfo. Le fichier texte buildinfo aura les noms et les numéros de version de toutes les bibliothèques qui étaient nécessaires dans l'environnement de construction pour créer le binaire.
Donc, si vous vous méfiez d'un package binaire (à partir de l'archive ou même à l'extérieur) qui contient le fichier texte buildinfo, il peut ou non être trivial de tester les packages en recréant l'environnement de construction exact et en comparant les hachages de la version finale. packages binaires.
Il peut également être possible d'avoir une sorte de toile de confiance afin que plus de gens puissent sauter et dire que les hachages correspondent, ce qui le rend un peu plus fiable peut-être. Il peut y avoir des cas Edge que je ne connais pas.