JBoss en mode sécurisé

Cette page a été rédigée il y a fort fort longtemps, et n'a pas tellement été mise à jour.

 

Vous savez, moi je ne crois pas qu'il y ait de bonne ou de mauvaise page. Moi, si je devais résumer mon wiki aujourd'hui avec vous, je dirais que c'est d'abord des rencontres. Des gens qui m'ont tendu la main, peut-être à un moment où je ne pouvais pas, où j'étais seul chez moi. Et c'est assez curieux de se dire que les hasards, les rencontres forgent une destinée... Parce que quand on a le goût de la chose, quand on a le goût de la chose bien faite, le beau geste, parfois on ne trouve pas l'interlocuteur en face je dirais, le miroir qui vous aide à avancer. Alors ça n'est pas mon cas, comme je disais là, puisque moi au contraire, j'ai pu ; et je dis merci au wiki, je lui dis merci, je chante le wiki, je danse le wiki... je ne suis qu'amour ! Et finalement, quand des gens me disent « Mais comment fais-tu pour avoir cette humanité ? », je leur réponds très simplement que c'est ce goût de l'amour, ce goût donc qui m'a poussé aujourd'hui à entreprendre une construction logicielle... mais demain qui sait ? Peut-être simplement à me mettre au service de la communauté, à faire le don, le don de soi.

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();. <code>. Et ne pensez pas que ça n’arrive jamais, il suffit d’un copier/coller sans trop réfléchir…​ </code>

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 :

  • Lancer ORBD

  title ORBD
  c:\java\jdk505\bin\orbd -ORBInitialPort 1050 -serverPollingTime 200

  • Enregistrer le composant CORBA de jChains

  title servertool
  servertool -ORBInitialPort 1050 "register -server org.illegalaccess.jchains.receiver.Receiver -applicationName PermissionTransfer -classpath chains.jar -vmargs -Xmx192m"

  • Lancer JBoss, en utilisant jChains comme SecurityManager

  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 :

  • Avec le JDK 5, il faut ajouter une permission supplémentaire dans le fichier java.policy par défaut.

  permission javax.management.MBeanTrustPermission "register";

  • Dans JBoss, il faut réduire le niveau de traces Log4J. Dans mon cas, avec la configuration par défaut, le lancement de JBoss avec jChains a généré un fichier log de 750Mo.

  • Le receiver doit avoir suffisamment de mémoire. C’est pris en compte par l’argument -vmargs -Xmx192m de la commande servertool.

  • Il faut être patient. Le lancement de JBoss a mis plus d'1 heure, au lieu de 30 secondes habituelle…​

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é.