là tu parles plutôt de qualité du code produit, qui dépend effectivement autant des possibilités offertes par le langage que du développeur.
Je penses qu'en parlant de sécurité il fait plutôt allusion à "lautre côté" du problème : l'exécution de code tiers. Comme s'assurer que le logiciel ne fais pas de bétise (erreur de programmation) voir ne tente pas de faire une action plus ou moins douteuse (virus ?) ?
C'est ce qu'apporte des environnements (plutôt que langage même si c'est lié) comme Java ou .NET en définissant une machine virtuelle premettant de contrôler à l'exécution tout ce qu'effectue le programme : contrôle des accès mémoires, des accès disques, accès réseaux, de manière plus général aux API, et ceci de manière très fine. Le développeur a accès à ces API pour définir sa propre politique de sécurité ou utiliser les politiques existantes.
Un programme plus "traditionnel" qui n'est pas exécuté dans un environnement "managé" n'a pour seul garde fou que l'OS qui fixe des limitations plus ou moins grossières là où il est capable d'effectuer des vérifications (cloisonnement mémoire, accès disque et périphérique, etc.)
Exemple concrêt : une application qui utilise des plugins les charge généralement dans son espace mémoire, en tout cas du point de vue de l'OS. Il a généralement les mêmes droits que l'application "hôte". Pourtant le plugin peut être téléchargé sur internet, et avoir un comportement plus ou moins douteux.
A moins de mettre en place un cloisonnement manuel (style fork avec utilisation de comptes avec actions restreintes) qui revient à réinventer un framework de sécurité...
Dans un environnement type Java ou .NET on peut donner des droits particuliers pour ces modules (d'ailleur un module provenant d'un composant téléchargé aura automatiquement par défaut une politique de sécurité très restrictive) et créer des cloisonnement de manière propre pour s'assurer que le plugin ne fait pas n'importe quoi sur la machine, et ne fait pas n'importe quoi dans l'application hôte (ne serais-ce que pour pouvoir décharger le module responsable sans tout péter).
Mais tout cela demande un modèle de code exécutable qui soit contrôlable, ce qui suppose un certain nombre de limitations sur les instructions qui sont exposés. C'est l'intérêt d'avoir un bytecode intermédiaire. Ce qui au passage impose un certain nombre de limitation aux langages qui sont implémentés au dessus.
[^] # Re: Mauvaise approche d'un vrai problème!
Posté par TImaniac (site web personnel) . En réponse au journal Qu'est-ce qu'un langage sécurisé ?. Évalué à 3.
Je penses qu'en parlant de sécurité il fait plutôt allusion à "lautre côté" du problème : l'exécution de code tiers. Comme s'assurer que le logiciel ne fais pas de bétise (erreur de programmation) voir ne tente pas de faire une action plus ou moins douteuse (virus ?) ?
C'est ce qu'apporte des environnements (plutôt que langage même si c'est lié) comme Java ou .NET en définissant une machine virtuelle premettant de contrôler à l'exécution tout ce qu'effectue le programme : contrôle des accès mémoires, des accès disques, accès réseaux, de manière plus général aux API, et ceci de manière très fine. Le développeur a accès à ces API pour définir sa propre politique de sécurité ou utiliser les politiques existantes.
Un programme plus "traditionnel" qui n'est pas exécuté dans un environnement "managé" n'a pour seul garde fou que l'OS qui fixe des limitations plus ou moins grossières là où il est capable d'effectuer des vérifications (cloisonnement mémoire, accès disque et périphérique, etc.)
Exemple concrêt : une application qui utilise des plugins les charge généralement dans son espace mémoire, en tout cas du point de vue de l'OS. Il a généralement les mêmes droits que l'application "hôte". Pourtant le plugin peut être téléchargé sur internet, et avoir un comportement plus ou moins douteux.
A moins de mettre en place un cloisonnement manuel (style fork avec utilisation de comptes avec actions restreintes) qui revient à réinventer un framework de sécurité...
Dans un environnement type Java ou .NET on peut donner des droits particuliers pour ces modules (d'ailleur un module provenant d'un composant téléchargé aura automatiquement par défaut une politique de sécurité très restrictive) et créer des cloisonnement de manière propre pour s'assurer que le plugin ne fait pas n'importe quoi sur la machine, et ne fait pas n'importe quoi dans l'application hôte (ne serais-ce que pour pouvoir décharger le module responsable sans tout péter).
Mais tout cela demande un modèle de code exécutable qui soit contrôlable, ce qui suppose un certain nombre de limitations sur les instructions qui sont exposés. C'est l'intérêt d'avoir un bytecode intermédiaire. Ce qui au passage impose un certain nombre de limitation aux langages qui sont implémentés au dessus.