JBoss en mode sécurisé


Principe

Cas général

L'activation du SecurityManager au lancement d'un programme java permet de s'assurer que celui-ci ne fera que des actions autorisées par l'administrateur. L'exemple le plus grossier est l'interdiction dans un composant JEE d'une commande comme System.exit();. . Et ne pensez pas que ça n'arrive jamais, il suffit d'un copier/coller sans trop réfléchir...

Le premier contrôle est évidemment du ressort des développeurs qui peuvent éviter ce genre de bourdes par des revues de code et de vérifications automatisées, avec des outils comme checkstyle.

D'autres cas peuvent être litigieux, car prévus par les développeurs, mais non déclarés à l'exploitation. On peut penser par exemple à des accès disque ou réseau.

Intérêt dans JBoss

Même en faisant une confiance absolue aux développeurs, il peut être utile de limiter les actions autorisées aux applications.

JBoss permet de déployer des applications à chaud, via sa console jmx. Les applications déployées de cette façon ne sont pas forcément dans le répertoire de JBoss, voire sur un autre serveur. Interdire toute action à une application déployée depuis une localisation non prévue permet de limiter les risques !

Mise en place

Cas général

Le SecurityManager est activé au lancement de java, en passant les paramètres suivants :

-Djava.security.manager 
-Djava.security.policy=myapp.policy

Le fichier <code>myapp.policy contient les permissions accordées à l'application. Les permissions par défaut sont dans le fichier jre/lib/java.policy.

JBoss

Au lancement de JBoss, on peut passer ces paramètres via la variable JAVA_OPTS :

set JAVA_OPTS=-Djava.security.manager -Djava.security.policy="./server/secured/conf/server.policy"

Jusqu'à la version 4.0.2, JBoss fournissait un fichier server.policy dans le répertoire conf des configurations. Ce fichier par défaut n'existe plus depuis la version 4.0.3, ce qui est plutôt une bonne chose car il ne servait à rien puisqu'il autorisait tout à toutes les classes !

grant
   permission java.security.AllPermission;
};

Fichier policy par défaut

Sur les wiki de JBoss, il est proposé un fichier policy par défaut. Ce fichier peut encore être affiné, puisqu'il fait une totale confiance aux classes de JBoss, ainsi qu'à toutes les archives déployées comme librairie. Il donne aussi beaucoup de liberté aux applications déployées au niveau du réseau.

Fichier policy affiné

La technique pour affiner un tel fichier peut être fastidieuse. On positionne en général les permissions auquelles on pense en premier lieu, muis commence le travail de fourmi qui consiste à lancer l'application, à constater qu'il manque une permission, puis à modifier le fichier et relancer l'ensemble.

Si cette technique est envisageable pour un administrateur chevronné, elle pendrait trop de temps pour un néophyte.

Utilitaire jChains

L'utilitaire open source jChains permet de recenser toutes les permissions nécessaires à une application.

La procédure (expliquée surla page d'accueil de l'utilitaire) est la suivante :

  title ORBD
  c:\java\jdk505\bin\orbd -ORBInitialPort 1050 -serverPollingTime 200
  title servertool
  servertool -ORBInitialPort 1050 "register -server org.illegalaccess.jchains.receiver.Receiver -applicationName PermissionTransfer -classpath chains.jar -vmargs -Xmx192m"
  title JBoss - jChains
  set JBOSS_CLASSPATH=jchains.jar
  set JAVA_OPTS=-Dorg.illegalaccess.emitClass=org.illegalaccess.jchains.intercept.CORBAEmitter 
                -Dorg.illegalaccess.jchains.outputfile=jbossout 
                -Dorg.illegalaccess.jchains.CNameServiceIOR=corbaloc::localhost:1050/NameService 
                -Djava.security.manager=org.illegalaccess.jchains.intercept.JChainsSecInterceptor
  run -c jchains

Quelques précautions supplémentaires doivent être prises :

  permission javax.management.MBeanTrustPermission "register";

Attention, jChains est très verbeux, il faudra retravailler ces permissions, en le regroupant. Rien que pour le démarrage de JBoss 4 , il a généré plus de 20000 permissions. De plus, il a un peu de mal pour les MBeanPermission, qu'il faut dans certains cas ajouter manuellement.

Conclusion

jChains est un outil intéressant, mais peu pratique dans le cas d'applications JEE. De plus, il est peu probable de voir arriver une version améliorée, la version actuelle datant de plus de 2 ans. Il nous reste donc la méthode empirique, qui nécessite de nombreux redémarrages.

Sinon, on peut faire confiance aux développeurs et blinder les autres aspects de la sécurité.