Discussion :

[cho7]

Bonjour les gens,

j'essaie de faire tourner ma jvm dans un environnement sécurisé, càd en interdisant à l'utilisateur d'écrire sur le disque dur et d'agir sur la jvm

Mais j'aimerai aussi que tout le reste soit autorisé.

En gros une sorte de java.security.AllPermission mais avec un java.io.FilePermission read (et pas write/delete) un java.lang.RuntimePermission exitVM à false

Ou pour faire plus simple, lister explicitement ce que le programme n'a pas le droit de faire, plutôt que de lister ce qu'il a le droit.

Tel qu'est fait le java.security.manager j'ai l'impression que ce n'est pas possible sans lister explicitement tout ce qui est autorisé...

Si quelqu'un a une idée.

Une alternative serait de chrooter le programme dans un dossier, mais sur une machine pas forcément de type unix, là aussi je suis ouvert à toute suggestion.

Le but est de fournir dans mon appli une console jython capable d'exécuter du code python arbitraire. Je ne veux pas que l'utilisateur chevronné puisse utiliser la console pour mettre en vrac le serveur.

Question bonus :
On peut appliquer une permission non pas a un codebase mais a une classe précise ?

Genre j'ai dans mon package une class Main, Foo, et Bar, je veux que seules Main et Foo puisse lire et écrire sur le disque, mais je veux du readonly pour Bar

Merci pour votre aide !

[Invité]

Salut

Alors plusieurs réponses :

• À ma connaissance, pour lister les permissions, c'est basé sur le principe de white list et non blacklist. Ce qui dans ce cas est plus sécurisé : au pire si tu as oublié une permission, ça peut entrainer une gêne passagère facile á régler. Si tu as oublié quelque chose d'interdit, ça peut "mettre en vrac le server". Donc je crois que tu vas avoir le droit de te taper la liste complète : http://java.sun.com/javase/6/docs/te...rmissions.html Bon courage !!!
• Tu peux donner les permissions à une classe précise avec un truc un peu moche : mettre tes classes dans un jar à part et utiliser le codeBase pour ce jar uniquement (mettre le jar ailleurs). Comme dit c'est moche mais je vois rien d'autre au pieds levé (en dehors de coder ta propre classe policy. En fait peut-être que cette solution serait le plus rapide pour toi si tu ne souhaites rien faire de configurable http://java.sun.com/javase/7/docs/te...hangingDefault Tu connais tes classes et ce qu'elles peuvent faire, et appliquer un masque pour les permissions non autorisées.

[cho7]

Hello,
merci pour ta réponse !

Ton idée de créer une classe Policy m'a donné l'idée de me créer mon propre SecurityManager en le surchargeant !

C'est beaucoup plus simple, puisque par défaut il laisse tout passer, et je n'ai eu qu'à overrider la méthode checkWrite. J'ai appelé humblement ma classe ReadOnlySecurityManager

[thelvin]

Notons au passage que c'est une aberration en termes de sécurité, et que faire ça ou ne rien faire, ça ne fait pas trop de différence.

Il y a une raison pour laquelle ça marche en whitelist et pas en blacklist.

[tchize_]

+1, c'est un emplatre ta sécurité. Ainsi, même si on sais plus utiliser l'api File pour faire des IO, il reste les problèmes suivant:

1) je peux exécuter n'importe quoi, y compris une commande shell qui modifie le fichier
2) As-tu vérifié que les FileChannel ne contournent pas le problème?
3) Qu'en est-il des temp file, souvent nécessaires en écriture aux applications?

En pratique et de manière détaillée, quel est ton besoin?