À coté de ça, elle pourra avoir un fichier de politique de sécurité, indiquant quel code possède quelles permissions.
J'en reviens donc a ma question :
Comment tu définis tu différencie tes codes ?
Si pour toi "code" c'est une execution d'un .class ou une connerie comme ça, oublie tout de suite, tu parle juste de processus (à l'intérieur de ta vm).
Et les règles de sécu d'un processus dans une vm java, on peut lui donner les mêmes, voir bien plus, avec un processus noyau.
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é (c'est au niveau de l'administration que la sécurité s'effectue, et pas au niveau du processus en réalité).
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.
* catégorie, level, contexte non standard, mais rien n'interdit de les créer ;)
mais ça s'active et s'utilise très facilement.
Et c'est la la _seule_ différence a mes yeux : ca s'utilise très facilement (soyons franc, selinux est plutot assez compliqué a utiliser et a configurer. Mais très très très puissant).
Non, parce que l'environnement d'exécution pourra avoir besoin d'accéder à des fichiers locaux (un fichier de préférences, par exemple), mais on voudra quand même empêcher l'applet de lire quoi que ce soit sur le disque local.
C'est pas l'applet qui lis mais la vm, la nuance est de taille.
En gros tu viens de montrer un changement de contexte lors d'un exec.
Bref, ca reste possible d'un point de vue noyau, mais encore une fois je suis bien conscient que l'administration est sans commune mesure.
[^] # Re: Pourquoi Mono ?
Posté par briaeros007 . En réponse au journal Utiliser Mono sans peur. Évalué à 3.
J'en reviens donc a ma question :
Comment tu définis tu différencie tes codes ?
Si pour toi "code" c'est une execution d'un .class ou une connerie comme ça, oublie tout de suite, tu parle juste de processus (à l'intérieur de ta vm).
Et les règles de sécu d'un processus dans une vm java, on peut lui donner les mêmes, voir bien plus, avec un processus noyau.
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é (c'est au niveau de l'administration que la sécurité s'effectue, et pas au niveau du processus en réalité).
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.
* catégorie, level, contexte non standard, mais rien n'interdit de les créer ;)
mais ça s'active et s'utilise très facilement.
Et c'est la la _seule_ différence a mes yeux : ca s'utilise très facilement (soyons franc, selinux est plutot assez compliqué a utiliser et a configurer. Mais très très très puissant).
Non, parce que l'environnement d'exécution pourra avoir besoin d'accéder à des fichiers locaux (un fichier de préférences, par exemple), mais on voudra quand même empêcher l'applet de lire quoi que ce soit sur le disque local.
C'est pas l'applet qui lis mais la vm, la nuance est de taille.
En gros tu viens de montrer un changement de contexte lors d'un exec.
Bref, ca reste possible d'un point de vue noyau, mais encore une fois je suis bien conscient que l'administration est sans commune mesure.