Regarde Firefox par exemple, ou les plugin sont un de ses gros atouts.
Je parlait de la sécurité.
Chrome ou IE8 sont plus secure que fx tant qu'ils n'auront pas fait du process tabing et les autres conneries du même style. (voui voui tu m'as bien lu, j'ai bien dis qu'IE8 était supérieur à fx sur au moins un domaine ;))
Et d'après defcon , je suis pas sur que les "plugins" de fx soient considéré comme une bonne chose niveau sécu http://www.defcon.org/html/defcon-17/dc-17-speakers.html#Liv(...)
(enfin je dis ça, je dois bien avoir 3 ou 4 plugins sur mon iceweasel moi)
J'ai du mal a comprendre la question tu peux preciser un peu?
Grosso modo, dans le même espace mémoire, tu as du code sur et du code non sur. Serait il possible qu'un attaquant, a partir de son code "non sur" arrive a phagocyter le code dis "sur" ? (création dynamique de classe héritant du contexte de classes autorisées, buffer overflow sur _son_ code , trampoline... Enfin je suis pas un expert dedans, mais il doit exister un certain nombre de vecteur d'attaques possibles quand on permet a une classe de s'executer dans le même espace qu'une autre classe)
Les VM Java et .Net sont des produits tres critiques pour Sun/oracle et MS, tres utilisees sur les serveurs, utilisees par des gens qui ont des besoins critiques en secu, le degre de confiance accordable aux deux process secu est, je pense, le meme.
Le problème (enfin de mon point de vue) est que le noyau est utilisé par tout le monde, soumis a des attaques incessantes (il y a certainement encore des 0-day ), etc...
Bref, l'os, étant une base commune, risque de concentrer plus de monde compétent, du fait qu'il touche plus de monde.
Ensuite le but de l'os est de gerer les ressources, et donc la sécurité de celles ci.
Quand bien même l'os est passablement complexe, la sécurité reste un des but primaires de l'os.
De l'autre coté, la VM n'a pas pour but primaire d'assurer la sécu, mais d'executer les classes. Ceci peut rendre le code plus complexe, car devant effectuer plus de choses, et souvent utilisant des techniques plus haut niveau.
Les techniques haut niveau réduisant d'autant le code et la complexité de celui ci, aidant donc à l'audit et à une bonne fiabilité. Mais il introduit aussi d'autres sources potentiels de bugs (bugs isses des libs haut niveau utilisés, etc...)
Bref, l'un dans l'autre, j'ai moins confiance dans une vm java (seulement récemment libéré), en une vm .net (celle ms, peu, vu qu'elle n'est pas libre, celle mono, pas des masses, car bien que n'étant pas libre, n'est pas vraiment sur une position "critique" sur le système, donc souvent moins regardé).
Ensuite c'est peut être un simple préjugé de ma part ;)
[^] # Re: Pourquoi Mono ?
Posté par briaeros007 . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Je parlait de la sécurité.
Chrome ou IE8 sont plus secure que fx tant qu'ils n'auront pas fait du process tabing et les autres conneries du même style. (voui voui tu m'as bien lu, j'ai bien dis qu'IE8 était supérieur à fx sur au moins un domaine ;))
Et d'après defcon , je suis pas sur que les "plugins" de fx soient considéré comme une bonne chose niveau sécu
http://www.defcon.org/html/defcon-17/dc-17-speakers.html#Liv(...)
(enfin je dis ça, je dois bien avoir 3 ou 4 plugins sur mon iceweasel moi)
J'ai du mal a comprendre la question tu peux preciser un peu?
Grosso modo, dans le même espace mémoire, tu as du code sur et du code non sur. Serait il possible qu'un attaquant, a partir de son code "non sur" arrive a phagocyter le code dis "sur" ? (création dynamique de classe héritant du contexte de classes autorisées, buffer overflow sur _son_ code , trampoline... Enfin je suis pas un expert dedans, mais il doit exister un certain nombre de vecteur d'attaques possibles quand on permet a une classe de s'executer dans le même espace qu'une autre classe)
Les VM Java et .Net sont des produits tres critiques pour Sun/oracle et MS, tres utilisees sur les serveurs, utilisees par des gens qui ont des besoins critiques en secu, le degre de confiance accordable aux deux process secu est, je pense, le meme.
Le problème (enfin de mon point de vue) est que le noyau est utilisé par tout le monde, soumis a des attaques incessantes (il y a certainement encore des 0-day ), etc...
Bref, l'os, étant une base commune, risque de concentrer plus de monde compétent, du fait qu'il touche plus de monde.
Ensuite le but de l'os est de gerer les ressources, et donc la sécurité de celles ci.
Quand bien même l'os est passablement complexe, la sécurité reste un des but primaires de l'os.
De l'autre coté, la VM n'a pas pour but primaire d'assurer la sécu, mais d'executer les classes. Ceci peut rendre le code plus complexe, car devant effectuer plus de choses, et souvent utilisant des techniques plus haut niveau.
Les techniques haut niveau réduisant d'autant le code et la complexité de celui ci, aidant donc à l'audit et à une bonne fiabilité. Mais il introduit aussi d'autres sources potentiels de bugs (bugs isses des libs haut niveau utilisés, etc...)
Bref, l'un dans l'autre, j'ai moins confiance dans une vm java (seulement récemment libéré), en une vm .net (celle ms, peu, vu qu'elle n'est pas libre, celle mono, pas des masses, car bien que n'étant pas libre, n'est pas vraiment sur une position "critique" sur le système, donc souvent moins regardé).
Ensuite c'est peut être un simple préjugé de ma part ;)