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?)).
Oui, c'est sûr que ça n'a rien de magique, une faille dans une lib privilégiée peut mettre à terre tout le système. Ça n'empêche pas que ça offre quand même des possibilités intéressantes qui seraient très difficiles à faire autrement, et impossibles à faire de façon portable. Quant à l'"accès à la mémoire", oublie pas qu'on est dans une VM, même le code "trusted" n'a pas accès à la mémoire autrement que par les objets dont il possède des références. Un scan de la mémoire pour aller y chercher des infos sensibles est exclu dans tous les cas.
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 ?
Je sais pas exactement comment c'est géré en interne, mais la VM est toujours capable de fournir la pile d'appel, même dans du code qui a été compilé, optimisé, voire inliné. Donc ça ne doit pas poser de problème.
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).
Avec l'implémentation standard, je suis pas sûr, mais le SecurityManager est un objet parfaitement normal, on peut sans problème en créer une sous-classe capable de changer les permissions à chaud si besoin.
Pour moi, c'est quand même sacrément jouer avec le feu.
Comme je l'ai dit avant, le but n'est pas de remplacer les sécurités de l'OS, mais de fournir un moyen pratique et surtout portable d'avoir certaines garanties au niveau sécurité. Si vraiment on a besoin d'une sécurité absolue, il faudra envisager autre chose, mais ça sera forcément beaucoup plus lourd, et risque de nécessiter pas mal de boulot de config au niveau de l'OS : créer des contextes d'exécution séparés, régler les permissions, prévoir un système de communication inter-processus qui pourra passer les barrières mises en place, etc. Et au final, on pourra aussi très facilement oublier un détail qui va complètement détruire tout l'édifice ;)
[^] # Re: Pourquoi Mono ?
Posté par Buf (Mastodon) . En réponse au journal Utiliser Mono sans peur. Évalué à 3.
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?)).
Oui, c'est sûr que ça n'a rien de magique, une faille dans une lib privilégiée peut mettre à terre tout le système. Ça n'empêche pas que ça offre quand même des possibilités intéressantes qui seraient très difficiles à faire autrement, et impossibles à faire de façon portable. Quant à l'"accès à la mémoire", oublie pas qu'on est dans une VM, même le code "trusted" n'a pas accès à la mémoire autrement que par les objets dont il possède des références. Un scan de la mémoire pour aller y chercher des infos sensibles est exclu dans tous les cas.
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 ?
Je sais pas exactement comment c'est géré en interne, mais la VM est toujours capable de fournir la pile d'appel, même dans du code qui a été compilé, optimisé, voire inliné. Donc ça ne doit pas poser de problème.
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).
Avec l'implémentation standard, je suis pas sûr, mais le SecurityManager est un objet parfaitement normal, on peut sans problème en créer une sous-classe capable de changer les permissions à chaud si besoin.
Pour moi, c'est quand même sacrément jouer avec le feu.
Comme je l'ai dit avant, le but n'est pas de remplacer les sécurités de l'OS, mais de fournir un moyen pratique et surtout portable d'avoir certaines garanties au niveau sécurité. Si vraiment on a besoin d'une sécurité absolue, il faudra envisager autre chose, mais ça sera forcément beaucoup plus lourd, et risque de nécessiter pas mal de boulot de config au niveau de l'OS : créer des contextes d'exécution séparés, régler les permissions, prévoir un système de communication inter-processus qui pourra passer les barrières mises en place, etc. Et au final, on pourra aussi très facilement oublier un détail qui va complètement détruire tout l'édifice ;)