Serait il possible qu'un attaquant, a partir de son code "non sur" arrive a phagocyter le code dis "sur" ?
Non, c'est "by design" qu'une VM comme Java ou .NET empêche celà.
C'est "by design" que du code natif laisse faire tout et n'importe quoi.
C'est pas pour rien qu'un OS est obligé pour contourner le problème de s'appuyer sur les rings matériels offerts par le processeur pour cloisonner les processus et donc gérer les droits utilisateurs.
Bref, l'os, étant une base commune, risque de concentrer plus de monde compétent, du fait qu'il touche plus de monde.
L'OS contient surtout une quantité hallucinante de code tournant dans un même espace mémoire. Une VM a un code extrêmement réduit, et la gestion de sécu, là où passe tout le code utilisateur et donc est la seule "véritable" faille de la VM, est une partie insignifiante de ce que représente tout le joli monde que l'on trouve dans le kernel.
De l'autre coté, la VM n'a pas pour but primaire d'assurer la sécu, mais d'executer les classes.
Un des buts d'une VM est d'abstraire le code machine qui n'offre de base aucune sécurité, pour justement proposer un modèle de machine (VM) entièrement contrôlable par l'environnement d'exécution. Bref, by design encore une fois, une VM est conçu pour avoir une maîtrise complète du code exécuté.
Un OS n'a que vaguement la main à travers les appels systèmes et s'appui sur le hardware in fine.
Suffit de voir des projets de recherche sur les OS comme Singularity qui propose un modèle de sécurité entièrement logiciel, uniquement possible parcque s'appuyant sur une VM qui défini un jeu d'instruction entièrement contrôlable par l'OS. http://en.wikipedia.org/wiki/Singularity_%28operating_system(...)
La plus grosse faille de sécu de ces VM, c'est là où elle appel du code natif. En dehors du coeur (JIT et runtime en soit), la gros trou est au niveau des bindings vers des libs natives (IHM ou autre).
C'est là que la VM n'a plus la main sur le code exécuté, et c'est là que ca peut devenir dangereux.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Non, c'est "by design" qu'une VM comme Java ou .NET empêche celà.
C'est "by design" que du code natif laisse faire tout et n'importe quoi.
C'est pas pour rien qu'un OS est obligé pour contourner le problème de s'appuyer sur les rings matériels offerts par le processeur pour cloisonner les processus et donc gérer les droits utilisateurs.
Bref, l'os, étant une base commune, risque de concentrer plus de monde compétent, du fait qu'il touche plus de monde.
L'OS contient surtout une quantité hallucinante de code tournant dans un même espace mémoire. Une VM a un code extrêmement réduit, et la gestion de sécu, là où passe tout le code utilisateur et donc est la seule "véritable" faille de la VM, est une partie insignifiante de ce que représente tout le joli monde que l'on trouve dans le kernel.
De l'autre coté, la VM n'a pas pour but primaire d'assurer la sécu, mais d'executer les classes.
Un des buts d'une VM est d'abstraire le code machine qui n'offre de base aucune sécurité, pour justement proposer un modèle de machine (VM) entièrement contrôlable par l'environnement d'exécution. Bref, by design encore une fois, une VM est conçu pour avoir une maîtrise complète du code exécuté.
Un OS n'a que vaguement la main à travers les appels systèmes et s'appui sur le hardware in fine.
Suffit de voir des projets de recherche sur les OS comme Singularity qui propose un modèle de sécurité entièrement logiciel, uniquement possible parcque s'appuyant sur une VM qui défini un jeu d'instruction entièrement contrôlable par l'OS.
http://en.wikipedia.org/wiki/Singularity_%28operating_system(...)
La plus grosse faille de sécu de ces VM, c'est là où elle appel du code natif. En dehors du coeur (JIT et runtime en soit), la gros trou est au niveau des bindings vers des libs natives (IHM ou autre).
C'est là que la VM n'a plus la main sur le code exécuté, et c'est là que ca peut devenir dangereux.