Non, je parle de vrai sandboxing, où on pourra donner des privilièges différents suivant l'origine du code au sein du même processus.
Très simple a faire en "java" ou en ".net" ?
Tu m'explique déjà comment tu donnes des privilèges différent au sein du _même_ processus, que ce processus soit géré par le noyau ou la vm ?
Ah moins que tu ne considère que la vm est "le processus", et que le code executé (applet ou autre) ne sont pas constituf d'un processus (dans la vm).
Dans ce cas ca veut dire que tu exécute un code dans un conteneur, non/faiblement audité avec des droits extrêmement étendu par rapport à ce que fait le code.
même si la VM qui la fait tourner a tous les privilèges de l'utilisateur courant, l'applet ne pourra pas accéder aux fichiers du disque, ni établir de connexions réseaux avec d'autres serveurs que celui d'où vient le code.
Même chose si tu lance ton applet avec ou les bonnes règles selinux et/ou setuid=nobody
Ta vm fait juste tourner un processus, et gère ce processus.
Attention, je ne dis pas que la vm est forcément un mauvais choix, mais il faut savoir l'utiliser avec recul et ne pas reposer la sécurité sur la vm. la vm est un _ajout_, ni plus ni moins. Et en plus c'est du code bien lourd, et peu audité (comparé au noyau)
Bref croire que parce que c'est dans une vm c'est plus sécure qu'un système bien configuré, c'est faux.
Une vm a un intérêt : reposer la sécurité sur des composants utilisateurs et non pas systèmes. Elle est aussi souvent plus simple a gérer car ne gère qu'un seul type particulier d'interaction itou.
Les deux sont utiles, les deux ont des buts différents, mais intrinsèquement, la sécurité finale doit toujours être assuré par le système.
[^] # Re: Pourquoi Mono ?
Posté par briaeros007 . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Très simple a faire en "java" ou en ".net" ?
Tu m'explique déjà comment tu donnes des privilèges différent au sein du _même_ processus, que ce processus soit géré par le noyau ou la vm ?
Ah moins que tu ne considère que la vm est "le processus", et que le code executé (applet ou autre) ne sont pas constituf d'un processus (dans la vm).
Dans ce cas ca veut dire que tu exécute un code dans un conteneur, non/faiblement audité avec des droits extrêmement étendu par rapport à ce que fait le code.
même si la VM qui la fait tourner a tous les privilèges de l'utilisateur courant, l'applet ne pourra pas accéder aux fichiers du disque, ni établir de connexions réseaux avec d'autres serveurs que celui d'où vient le code.
Même chose si tu lance ton applet avec ou les bonnes règles selinux et/ou setuid=nobody
Ta vm fait juste tourner un processus, et gère ce processus.
Attention, je ne dis pas que la vm est forcément un mauvais choix, mais il faut savoir l'utiliser avec recul et ne pas reposer la sécurité sur la vm. la vm est un _ajout_, ni plus ni moins. Et en plus c'est du code bien lourd, et peu audité (comparé au noyau)
Bref croire que parce que c'est dans une vm c'est plus sécure qu'un système bien configuré, c'est faux.
Une vm a un intérêt : reposer la sécurité sur des composants utilisateurs et non pas systèmes. Elle est aussi souvent plus simple a gérer car ne gère qu'un seul type particulier d'interaction itou.
Les deux sont utiles, les deux ont des buts différents, mais intrinsèquement, la sécurité finale doit toujours être assuré par le système.