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).
Meme si n'etant pas sur et certain, n'ayant jamais joue avec ca professionellement parlant, je pense que oui en Java, le SecurityManager etant un objet comme les autres, a verifier dans la doc.
Apres, par experience, je pourrais pas etre categorique. Oui, je sais, ma reponse est une reponse de normand.
Vu comment .Net a l'air bien pense, j'ai envie de dire "oui bien sur", mais ca reste un feeling, je laisse timaniac repondre a la question de facon sur et certaine.
Voir ma remarque au dessus. Pour moi, c'est quand même sacrément jouer avec le feu.
Pas forcement, non.
Regarde Firefox par exemple, ou les plugin sont un de ses gros atouts.
Ca m'emballe pas forcement de savoir que tous les plugins peuvent avoir acces a mes infos personnelles, ou qu'inversement aucun ne peut avoir acces a des infos perso parce que ca limite l'interet des plugins.
Avec un tel systeme tu peux mettre en place un systeme de plugin truste par la mofo, et ainsi en tirer un reelle gain.
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?)).
J'ai du mal a comprendre la question tu peux preciser un peu?
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.
C'est un point de vue, il se tient tout a fait.
On pourrait argumenter qu'il est plus fiable d'avoir une base solide fournissant ce mecanisme plutot que de devoir le reimplementer soit meme, avec des failles potentielles, mais ton point de vue est plus que comprehensible (entendre par la technique et pas purement politique comme 99% des conneries qui se disent ici contre mono).
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.
Je dirais pas que l'un est plus audite que l'autre, sincerement.
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.
[^] # Re: Pourquoi Mono ?
Posté par thedude . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Meme si n'etant pas sur et certain, n'ayant jamais joue avec ca professionellement parlant, je pense que oui en Java, le SecurityManager etant un objet comme les autres, a verifier dans la doc.
Apres, par experience, je pourrais pas etre categorique. Oui, je sais, ma reponse est une reponse de normand.
Vu comment .Net a l'air bien pense, j'ai envie de dire "oui bien sur", mais ca reste un feeling, je laisse timaniac repondre a la question de facon sur et certaine.
Voir ma remarque au dessus. Pour moi, c'est quand même sacrément jouer avec le feu.
Pas forcement, non.
Regarde Firefox par exemple, ou les plugin sont un de ses gros atouts.
Ca m'emballe pas forcement de savoir que tous les plugins peuvent avoir acces a mes infos personnelles, ou qu'inversement aucun ne peut avoir acces a des infos perso parce que ca limite l'interet des plugins.
Avec un tel systeme tu peux mettre en place un systeme de plugin truste par la mofo, et ainsi en tirer un reelle gain.
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?)).
J'ai du mal a comprendre la question tu peux preciser un peu?
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.
C'est un point de vue, il se tient tout a fait.
On pourrait argumenter qu'il est plus fiable d'avoir une base solide fournissant ce mecanisme plutot que de devoir le reimplementer soit meme, avec des failles potentielles, mais ton point de vue est plus que comprehensible (entendre par la technique et pas purement politique comme 99% des conneries qui se disent ici contre mono).
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.
Je dirais pas que l'un est plus audite que l'autre, sincerement.
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.