Comment sainement configurer la stratégie de sécurité dans Tomcat 6

Je suis en utilisant Tomcat 6.0.24, tel que conditionné pour Ubuntu Karmic. La stratégie de sécurité par défaut de Ubuntu Tomcat paquet est assez strictes, mais semble simple. Dans /var/lib/tomcat6/conf/policy.d, il existe une variété de fichiers que d'établir une stratégie par défaut.

Intéressant de noter au début:

Je n'ai pas changé le stock d'installation tomcat à tous-pas de nouveaux bocaux dans sa commune lib(s), pas de server.xml changements, etc. Mettre la .fichier war dans le webapps répertoire est la seule action de déploiement.
l'application web, je suis le déploiement échoue avec des milliers de refus d'accès en vertu de la présente politique par défaut (tel que rapporté dans le journal grâce à la -Djava.security.debug="access,stack,failure" système de la propriété).
de désactiver le gestionnaire de sécurité entièrement résultats dans les pas d'erreurs que ce soit, et de la bonne application de la fonctionnalité

Ce que je voudrais faire est d'ajouter une application spécifique de la politique de sécurité du fichier à la policy.d annuaire, ce qui semble être une pratique recommandée. J'ai ajouté ceci à policy.d/100myapp.policy (comme un point de départ -- je voudrais, éventuellement, d'en simplifier les autorisations accordées uniquement à ce que l'application a réellement besoin):

grant codeBase "file:${catalina.base}/webapps/ROOT.war" {
  permission java.security.AllPermission;
};

grant codeBase "file:${catalina.base}/webapps/ROOT/-" {
  permission java.security.AllPermission;
};

grant codeBase "file:${catalina.base}/webapps/ROOT/WEB-INF/-" {
  permission java.security.AllPermission;
};

grant codeBase "file:${catalina.base}/webapps/ROOT/WEB-INF/lib/-" {
  permission java.security.AllPermission;
};

grant codeBase "file:${catalina.base}/webapps/ROOT/WEB-INF/classes/-" {
  permission java.security.AllPermission;
};

Note la dérouillée autour d'essayer de trouver le bon codeBase déclaration. Je pense que c'est probablement mon problème fondamental.

De toute façon, le ci-dessus (en réalité que les deux premières subventions semblent avoir aucun effet) presque œuvres: les milliers de refus d'accès sont allés, et je suis à gauche avec un seul. Pertinentes de la trace de la pile:

java.security.AccessControlException: access denied (java.io.FilePermission /var/lib/tomcat6/webapps/ROOT/WEB-INF/classes/com/foo/some-file-here.txt read)
  java.security.AccessControlContext.checkPermission(AccessControlContext.java:323)
  java.security.AccessController.checkPermission(AccessController.java:546)
  java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
  java.lang.SecurityManager.checkRead(SecurityManager.java:871)
  java.io.File.exists(File.java:731)
  org.apache.naming.resources.FileDirContext.file(FileDirContext.java:785)
  org.apache.naming.resources.FileDirContext.lookup(FileDirContext.java:206)
  org.apache.naming.resources.ProxyDirContext.lookup(ProxyDirContext.java:299)
  org.apache.catalina.loader.WebappClassLoader.findResourceInternal(WebappClassLoader.java:1937)
  org.apache.catalina.loader.WebappClassLoader.findResource(WebappClassLoader.java:973)
  org.apache.catalina.loader.WebappClassLoader.getResource(WebappClassLoader.java:1108)
  java.lang.ClassLoader.getResource(ClassLoader.java:973)

Je suis assez convaincu que le fichier réel de déclenchement de la négation n'est pas pertinent; il est juste un fichier de propriétés que l'on vérifie pour l'option paramètres de configuration. Ce qui est intéressant, c'est que:

il n'existe pas dans ce contexte
le fait que le fichier n'existe pas, finit par lancer une exception de sécurité, plutôt que de java.io.File.exists() simplement retourner false (bien que je suppose que c'est juste une question de sémantique de l'autorisation de lecture).

Une autre solution (en plus il suffit de désactiver le gestionnaire de sécurité dans tomcat) est d'ajouter un ouvert la permission de mon fichier de stratégie:

grant {
  permission java.security.AllPermission;
};

Je suppose que cela est fonctionnellement équivalent à désactiver le gestionnaire de sécurité.

Je suppose que je dois être le codeBase déclaration dans ma subventions subtilement mal, mais je ne vois pas pour le moment.

InformationsquelleAutor cemerick | 2010-04-15

2

Vous utilisez Ubuntu package géré version? Nous avons eu un cauchemar récemment avec la sécurité des trucs avec elle, mais a constaté que par téléchargement Tomcat séparément et en l'utilisant, les questions de sécurité s'en alla.

Corroboration:

http://www.howtogeek.com/howto/linux/installing-tomcat-6-on-ubuntu/

Si vous êtes sous Ubuntu et que vous voulez utiliser le conteneur de servlet Tomcat, vous ne devez pas utiliser la version dans les dépôts que ça ne fonctionne pas correctement. Au lieu de cela, vous aurez besoin d'utiliser le manuel processus d'installation et que je suis présente ici.
- Nous n'avons pas eu de problèmes avec tomcat en dehors de ce gestionnaire de sécurité question-et de quelle manière(s) ai "juste ne pas fonctionner correctement" pour vous? FWIW, l'article lié est d'environ 3 ans, et les commentaires se réfèrent à ubuntu 7.x. Néanmoins, je vais vous donner un manuel d'installer un coup et de voir ce qui se passe.
- Il était tout gestionnaire de sécurité liés à, les questions que nous avions. Qui a dit que c'était un collègue de mon équipe qui avait la bataille avec elle, il a maintenant quitté l'entreprise donc je ne peux pas vous donner tous les détails. Voir votre question, et n'ayant jamais entendu parler de tels problèmes à l'extérieur de la emballés-tomcat-sur-ubuntu est ce qui a déclenché le big red sirène pour moi, et à l'aide d'un indépendant installation s'est faite sans problème.
- Par curiosité, comment avez-vous avec votre installation manuelle?
InformationsquelleAutor Brian
0

Tomcat fonctionne avec son propre utilisateur tomcat. La guerre des fichiers ont besoin d'être visible pour que l'utilisateur probablement la peine de vérifier que le premier?
- Oui, tous les fichiers en question (à la fois .la guerre des fichiers et des explosé application répertoires) sont la propriété de tomcat6:tomcat6, le même utilisateur que le serveur tomcat est exécuté.
InformationsquelleAutor anger
0

Êtes-vous directement déploiement dans le répertoire RACINE ?

Habituellement, lorsque vous mettez une guerre dans le répertoire webapps de, dire 100myapp.war, il décompresse les fichiers dans un dossier nommé 100myapp lui-même. Ne pas les subventions ensuite être faite sur ce nouveau dossier, plutôt que de le dossier RACINE ?
- En général, nous sommes le déploiement de notre application comme ROOT.war de sorte qu'il sera décompressé dans le ROOT répertoire. Juste au cas où c'était la source du problème, j'ai essayé aussi un déploiement vers un autre chemin (foo.war), la mise à jour de la subvention comme nécessaire (se référer à foo.war et l'déballé foo répertoire.
InformationsquelleAutor StudioEvoque
0

Il est possible que vous devez accorder des autorisations d'accès au fichier séparément. Essayez de changer la subvention pour votre application:
```
grant codeBase "file:${catalina.base}/webapps/ROOT.war" {
  permission java.security.AllPermission;
  permission java.io.FilePermission "file:${catalina.base}/webapps/ROOT/-", "read, write";
}
```
Si cela ne fonctionne pas, alors il se pourrait que certains de code en dehors de ce que vos subventions existantes, la couverture est l'accès à ces fichiers de propriétés (par exemple de servlet ou une autre bibliothèque de code).

Comme une solution de contournement, et de confirmer si c'est le cas, vous pourriez faire un don direct sur le .les propriétés qui vous causent le problème:
```
grant {
  permission java.io.FilePermission "file:${catalina.base}/webapps/ROOT/WEB-INF/classes/com/foo/some-file-here.txt", "read, write";
}
```
Il semble, en effet, que ce dernier pourrait être le cas puisque la trace de la pile montre le code dans Tomcat contexte du chargeur. Si le droit de la subvention sur le .propriétés de travaux, vous pouvez verrouiller la subvention vers le bas pour org.apache.de nommage.les ressources.FileDirContext.

Avez-vous des traces de pile spécifiques à votre propre code?
- Désolé, pas de dés: l'ajout d'un FilePermission w/ "lire, écrire" options pour toutes les bourses, j'ai eu en place n'a rien changé. Cependant, je pense qu'il y a quelque chose à cette théorie: par défaut, le fichier de stratégie que tomcat charge (situé à /var/lib/tomcat6/work/catalina.policy), il y a déjà des subventions prévues pour le code je l'utilisais, mais incluent AllPermission et FilePermission. Ceci, malgré un rapide test qui montre que la première implique la seconde. Malheureusement, la couverture de la subvention sur le fichier spécifique n'a pas changé de comportement, soit. Et non, je ne vois pas de traces de pile à partir de notre base de code.
InformationsquelleAutor Alan Donnelly

Vous devez vous connecter pour publier un commentaire.