Admettons que ton code essaie d'ouvrir un fichier. La méthode d'ouverture de fichier va appeler un SecurityManager (c'est l'objet responsable de l'application de la politique de sécurité) qui va examiner la pile d'appels de méthodes, ce qui va lui indiquer la provenance du code qui essaie d'accéder au fichier (en général, la politique se définit au niveau des fichiers JAR, donc le SecurityManager saura de quel JAR vient le code qui essaie d'ouvrir le fichier)
À partir de ça, il va simplement regarder ses règles de sécurité, qui vont dire par exemple "x.jar peut accéder sans limites au système de fichier, y.jar peut seulement lire les fichiers dans /tmp, et z.jar n'a pas la permission d'accéder au fs", et va soit autoriser l'opération, soit envoyer une exception.
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.
Je te met un contexte non_trusted* en level non_trusted* et catégorie non_trusted* sur le code par défaut, ben ton appli elle va s'amuser a faire quoi que ce soit.
Ben justement, on peut avoir dans la même VM du code "trusted" et du code "non-trusted", et on voudra que le code "trusted" puisse faire ce qu'il a besoin de faire, sans que le code "non-trusted" puisse faire n'importe quoi. C'est impossible à faire si la sécurité est gérée uniquement par l'OS, parce que les permissions sont au niveau process. Là, on veut quelque chose de plus fin. 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
Bien évidemment, chacune des permissions est complètement paramétrable, on peut par exemple autoriser les connexions sur un port précis d'un serveur précis et refuser tout le reste.
Ensuite c'est la difficulté a implémenté cette solution, mais intrinsèquement la vm n'apporte pas un "plus de sécurité", elle apporte bien un "plus de sécurité" car elle gère plus facilement la sécurité
Le but n'est pas de remplacer l'OS. Le but, c'est de fournir un environnement limité qui servira à exécuter du code dans lequel on n'a pas forcément confiance. Ça permet par exemple d'avoir une application qui pourra être étendue par des plugins tiers qui ne pourront pas faire n'importe quoi.
[^] # Re: Pourquoi Mono ?
Posté par Buf (Mastodon) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Admettons que ton code essaie d'ouvrir un fichier. La méthode d'ouverture de fichier va appeler un SecurityManager (c'est l'objet responsable de l'application de la politique de sécurité) qui va examiner la pile d'appels de méthodes, ce qui va lui indiquer la provenance du code qui essaie d'accéder au fichier (en général, la politique se définit au niveau des fichiers JAR, donc le SecurityManager saura de quel JAR vient le code qui essaie d'ouvrir le fichier)
À partir de ça, il va simplement regarder ses règles de sécurité, qui vont dire par exemple "x.jar peut accéder sans limites au système de fichier, y.jar peut seulement lire les fichiers dans /tmp, et z.jar n'a pas la permission d'accéder au fs", et va soit autoriser l'opération, soit envoyer une exception.
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.
Je te met un contexte non_trusted* en level non_trusted* et catégorie non_trusted* sur le code par défaut, ben ton appli elle va s'amuser a faire quoi que ce soit.
Ben justement, on peut avoir dans la même VM du code "trusted" et du code "non-trusted", et on voudra que le code "trusted" puisse faire ce qu'il a besoin de faire, sans que le code "non-trusted" puisse faire n'importe quoi. C'est impossible à faire si la sécurité est gérée uniquement par l'OS, parce que les permissions sont au niveau process. Là, on veut quelque chose de plus fin. 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
Bien évidemment, chacune des permissions est complètement paramétrable, on peut par exemple autoriser les connexions sur un port précis d'un serveur précis et refuser tout le reste.
Ensuite c'est la difficulté a implémenté cette solution, mais intrinsèquement la vm n'apporte pas un "plus de sécurité", elle apporte bien un "plus de sécurité" car elle gère plus facilement la sécurité
Le but n'est pas de remplacer l'OS. Le but, c'est de fournir un environnement limité qui servira à exécuter du code dans lequel on n'a pas forcément confiance. Ça permet par exemple d'avoir une application qui pourra être étendue par des plugins tiers qui ne pourront pas faire n'importe quoi.