Désactiver la réflexion Java pour le thread en cours

Question

Je dois appeler un code Java semi-fiable et vouloir désactiver la possibilité d'utiliser la réflexion pendant la durée de l'exécution de ce code. Est-ce que cela peut être fait avec un SecurityManager, et si oui, comment?

Clarification/Contexte: Ceci est une suite à another question concernant la restriction des paquets qui peuvent être appelés à partir de JavaScript/Rhino. La réponse acceptée fait référence à une entrée de blog sur la façon de faire cela, et elle nécessite deux étapes, la première utilisant une API Rhino (ClassShutter), la seconde désactivant la réflexion et Class.forName(). Je pensais que je pourrais faire cette seconde étape plus proprement en utilisant un SecurityManager (en apprendre plus sur SecurityManager, qui, comme on l'a souligné, est une bête complexe, en cours de route). Pour résumer, je veux (à partir du code, pas de réglage du fichier) pour désactiver Class.forName() et tout accès à l'ensemble du paquet de réflexion.

Answer 1

Cela dépend de ce que vous essayez de restreindre.

En général, l'API accessible au public n'est pas restreinte. Toutefois, tant que vous n'accordez pas l'autorisation ReflectPermission("suppressAccessChecks") au code non fiable, il ne pourra pas accéder à l'API non publique dans un autre package.

Si vous disposez d'une liste de packages auxquels vous souhaitez restreindre tous les accès, il existe deux étapes. Tout d'abord, dans les propriétés Security, include the restricted package in the package.access list. Puis donnez votre de confiance code RuntimePermission("accessClassInPackage." + pkg).

Une façon courante de distinguer votre code non fiable est de le charger à partir d'un emplacement différent, et de vous référer aux différentes bases de code dans votre fichier de politique lors de l'octroi des permissions.

L'architecture de sécurité Java est très puissante, mais je sais que c'est aussi compliqué; Si vous voulez un exemple plus concret, veuillez décrire exactement quels appels vous voulez restreindre et je vais essayer d'être plus explicite.

---

faire ce que vous voulez sans modifier le fichier java.policy et/ou le fichier java.security serait très difficile, voire impossible. Le java.security.Policy représente l'information dans java.policy, mais il n'offre pas l'accès en écriture. Vous pouvez créer votre propre implémentation Policy et l'installer au moment de l'exécution tant que n'importe quel SecurityManager le permet. Par contre, vous pouvez spécifier un fichier java.policy personnalisé en tant qu'option de ligne de commande. Si vous fournissez une application complète avec une sorte de lanceur, cela pourrait être facilement accompli. Il fournit également une certaine transparence à vos utilisateurs. Un utilisateur averti peut vérifier les autorisations que vous souhaitez accorder à l'application.

Answer 2

Eh bien, vous pouvez remplacer SecurityManager.checkMemberAccess et donner une définition plus stricte. Cependant, cela ne fonctionne pas vraiment comme ça. Que se passe-t-il par exemple si le code définit un finaliseur?

Sur la clarification: D'autres API utilisent la réflexion et d'autres API. Par exemple, java.beans, LiveConnect et Rhino. Par exemple, un adversaire pourrait créer un nouveau contexte Rhino sans l'obturateur et ainsi amorcer dans le JRE complet. Avec un système ouvert, une liste noire ne peut jamais être terminée.En résumé: pour utiliser le modèle de sécurité Java, vous devez travailler avec, pas contre.

Answer 3

J'ai écrit un remplacement de ClassShutter qui permet un contrôle d'accès à grains fins, par exemple, par méthode, par champ:

http://riven8192.blogspot.com/2010/07/java-rhino-fine-grained-classshutter.html