Là où la VM apporte un plus, c'est justement qu'elle donne la possibilité de fixer les permissions jar par jar, et pas juste une permission au niveau du processus complet.
Cela me pose quand même de gros problème, tu vas me dire que je suis parano mais
1°) vu que c'est le même espace mémoire tu ouvre quand même une grosse boite de pandore (suffit d'une faille dans un jar "autorisé", ou un code volontairement malicieux (si c'est possible), et tout le système s'écroule, sachant que tu as accés à la mémoire du jar autorisé vu que tu es dans le même processus (vm?)).
2°) et il gère comment les sécurité lors de la compilation et de l'execution du code binaire ? Les optimisation ne risquent elles pas de gener la VM ? Et les tranpolines , comment il retrouve ses petits ?
3°) est il possible de révoquer les permissions sans redemarrer les process ? (le système de base de linux ne le permet pas, mais selinux si).
Ben justement, on peut avoir dans la même VM du code "trusted" et du code "non-trusted"
Voir ma remarque au dessus. Pour moi, c'est quand même sacrément jouer avec le feu.
En plus de ça, les permissions qu'on peut régler ne concernent pas que l'accès au système de fichiers, on peut aussi autoriser/interdire :
- les connexions réseau
- le chargement de classes supplémentaires
- l'appel à System.exit() (termine la VM)
- la génération de byte code
- l'accès aux membres privés ou protégés des classes
- et surement plein de choses que j'oublie
En ce qui concerne le spécifique a java, bien entendu que l'os ne peut rien faire (os java sinon), mais pour les connexions réseaux etc... t'inquiète que selinux sait faire (d'ailleurs ca peut poser des problèmes quand on teste des policy non adapté. Ben pourquoi mon interface monte plus ?? XD )
Ça permet par exemple d'avoir une application qui pourra être étendue par des plugins tiers qui ne pourront pas faire n'importe quoi.
Je vais me répeter, mais pour moi cette architecture c'est sacrément jouer avec le feu.
Je reconnais l'intérêt technique, mais étant d'un naturel prudent, je persiste a penser qu'il serait plus sache de modifier l'architecture du programme pour que ce soit executé de façon séparé si on a pas confiance dans le code.
D'autant plus que l'on peut pas vraiment dire que la vm et le process de sécurité d'une vm, aussi utilisé soit elle, a été aussi audité que les procédures de sécu du noyau.
[^] # Re: Pourquoi Mono ?
Posté par briaeros007 . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Cela me pose quand même de gros problème, tu vas me dire que je suis parano mais
1°) vu que c'est le même espace mémoire tu ouvre quand même une grosse boite de pandore (suffit d'une faille dans un jar "autorisé", ou un code volontairement malicieux (si c'est possible), et tout le système s'écroule, sachant que tu as accés à la mémoire du jar autorisé vu que tu es dans le même processus (vm?)).
2°) et il gère comment les sécurité lors de la compilation et de l'execution du code binaire ? Les optimisation ne risquent elles pas de gener la VM ? Et les tranpolines , comment il retrouve ses petits ?
3°) est il possible de révoquer les permissions sans redemarrer les process ? (le système de base de linux ne le permet pas, mais selinux si).
Ben justement, on peut avoir dans la même VM du code "trusted" et du code "non-trusted"
Voir ma remarque au dessus. Pour moi, c'est quand même sacrément jouer avec le feu.
En plus de ça, les permissions qu'on peut régler ne concernent pas que l'accès au système de fichiers, on peut aussi autoriser/interdire :
- les connexions réseau
- le chargement de classes supplémentaires
- l'appel à System.exit() (termine la VM)
- la génération de byte code
- l'accès aux membres privés ou protégés des classes
- et surement plein de choses que j'oublie
En ce qui concerne le spécifique a java, bien entendu que l'os ne peut rien faire (os java sinon), mais pour les connexions réseaux etc... t'inquiète que selinux sait faire (d'ailleurs ca peut poser des problèmes quand on teste des policy non adapté. Ben pourquoi mon interface monte plus ?? XD )
Ça permet par exemple d'avoir une application qui pourra être étendue par des plugins tiers qui ne pourront pas faire n'importe quoi.
Je vais me répeter, mais pour moi cette architecture c'est sacrément jouer avec le feu.
Je reconnais l'intérêt technique, mais étant d'un naturel prudent, je persiste a penser qu'il serait plus sache de modifier l'architecture du programme pour que ce soit executé de façon séparé si on a pas confiance dans le code.
D'autant plus que l'on peut pas vraiment dire que la vm et le process de sécurité d'une vm, aussi utilisé soit elle, a été aussi audité que les procédures de sécu du noyau.