Oui, mais c'est bien ce que je pensais, ce type de protection ne permet que de se dédouaner de problèmes d'accès aux ressources système de la machine locale sur lequel s'exécute le programme. Et la sécurité c'est bien plus que çà. On peut faire du gruyère sandboxé, sans problèmes. C'est pour ça que je dis que c'est du "bullshit marketting". Ca permet de colmater des brèches et ça facilite le travail du développeur pour border son appli.
Maintenant je pense qu'on est d'accord les diverses techniques d'isolation des process sont toujours plutôt meilleures que "rien du tout je risque de laisser /etc/shadow en lecture et en plus je risque le buffer overflow", m'enfin ça ne suffit pas à faire une appli sécurisée, et l'article prête à confusion.
Bof. Avec les techniques modernes de sandboxing tu peux contrôler exactement ce à quoi ton programme a accès, fichier par fichier, socket par socket, etc. Tu peux mettre en place une véritable politique de sécurité extrêmement fine et sans aucune coopération du programme que tu exécutes. En fait, tu as un niveau de contrôle qui est comparable à celui offert par le noyau linux associé aux capabilities. Un peu comme si tu créais un utilisateur spécifique pour faire tourner un programme et que tu contrôlais exactement ce à quoi il a accès. Et je ne parle même pas des mécanismes de signature de code. Ok, l'article prête à confusion, mais les machines virtuelles permettent tout de même de faire beaucoup plus de choses que ce qu'on peut faire en C ou en C++. Donc évacuer ça par "bullshit marketting", c'est exactement du même niveau que de dire que l'extension NX des AMD est du marketing. C'est faux, même si ça ne résout pas tous les problèmes...
Je dis pas que ça fait tout ce que fait .NET, mais il faut toujours se méfier des phrases du type "Perl ne sait pas faire", j'en ai déjà fait les frais 8-)
Oui, oui, je connais le mode safe de perl, mais bon, ce n'est vraiment qu'une partie infime de ce qu'on peut faire avec Java ou .NET.
[^] # Re: Bravo l'innovation!!!
Posté par boubou . En réponse à la dépêche Mono 1.0 sous le feu des projecteurs. Évalué à 2.
Maintenant je pense qu'on est d'accord les diverses techniques d'isolation des process sont toujours plutôt meilleures que "rien du tout je risque de laisser /etc/shadow en lecture et en plus je risque le buffer overflow", m'enfin ça ne suffit pas à faire une appli sécurisée, et l'article prête à confusion.
Bof. Avec les techniques modernes de sandboxing tu peux contrôler exactement ce à quoi ton programme a accès, fichier par fichier, socket par socket, etc. Tu peux mettre en place une véritable politique de sécurité extrêmement fine et sans aucune coopération du programme que tu exécutes. En fait, tu as un niveau de contrôle qui est comparable à celui offert par le noyau linux associé aux capabilities. Un peu comme si tu créais un utilisateur spécifique pour faire tourner un programme et que tu contrôlais exactement ce à quoi il a accès. Et je ne parle même pas des mécanismes de signature de code. Ok, l'article prête à confusion, mais les machines virtuelles permettent tout de même de faire beaucoup plus de choses que ce qu'on peut faire en C ou en C++. Donc évacuer ça par "bullshit marketting", c'est exactement du même niveau que de dire que l'extension NX des AMD est du marketing. C'est faux, même si ça ne résout pas tous les problèmes...
Ceci étant dit:
perl + sandbox sur Google (3ème lien):
http://secu.zzu.edu.cn/book/Perl/Perl%20Bookshelf%20%5B3rd%20Ed%5D/(...))
Je dis pas que ça fait tout ce que fait .NET, mais il faut toujours se méfier des phrases du type "Perl ne sait pas faire", j'en ai déjà fait les frais 8-)
Oui, oui, je connais le mode safe de perl, mais bon, ce n'est vraiment qu'une partie infime de ce qu'on peut faire avec Java ou .NET.