meilleure pratique pour l'autorisation d'accès aux utilisateurs pour apache tomcat

22

J'ai une boîte Linux partagée par divers développeurs. Ils veulent déployer leurs fichiers de guerre dans apache tomcat qui dans un emplacement partagé (/ opt / tomcat).

Puisqu'ils n'ont pas d'accès sudo, je dois changer l'autorisation de dossier pour le répertoire tomcat.

la structure du répertoire sous /opt/tomcatest -

bin/

conf/

lib/

logs/

temp/

webapps/

work/

Quelles sont les meilleures pratiques dans la situation ci-dessus - Autorisation d'accès la plus appropriée à l'utilisateur? Pour le moment, j'ai changé l'autorisation de 777 en applications Web et journaux.

Merci

linux tomcat

— Kunal
source

32

Je le fais de cette façon:

Nous plaçons l'utilisateur tomcat comme propriétaire du dossier de tomcat:

# chown -R tomcat:tomcat /opt/tomcat

Les utilisateurs ne peuvent pas modifier la configuration de tomcat:

# chmod -R g+r /opt/tomcat/conf

Les utilisateurs peuvent modifier les autres dossiers:

# chmod -R g+w /opt/tomcat/logs
# chmod -R g+w /opt/tomcat/temp
# chmod -R g+w /opt/tomcat/webapps
# chmod -R g+w /opt/tomcat/work

Activez le sticky-bit pour les nouveaux fichiers, gardez les autorisations définies:

# chmod -R g+s /opt/tomcat/conf
# chmod -R g+s /opt/tomcat/logs
# chmod -R g+s /opt/tomcat/temp
# chmod -R g+s /opt/tomcat/webapps
# chmod -R g+s /opt/tomcat/work

Enfin, nous ajoutons le groupe tomcat dont nous voulons que les utilisateurs puissent utiliser le tomcat:

# usermod -a -G tomcat MIUSER

— intropedro
source

4

Si cela est fait sans la balise -a, vous ajouterez l'utilisateur au groupe tomcat, mais supprimez MIUSER de tous les autres groupes auxquels il appartient (cela signifie plus de groupe sudo). Je devais juste agir rapidement pour récupérer mes groupes sur le compte principal sur l'un de mes serveurs, en les récupérant d'une ancienne session où je détenais encore ces groupes. Un mot d'avertissement aux autres utilisateurs lisant cette réponse.

— Axoren

J'ai ajouté l'option à la réponse. Merci

— intropedro

Comment faire démarrer Tomcat en tant qu'utilisateur Tomcat? Le mien est démarré en tant que démon et à partir de maintenant il s'exécute en tant que root.

— Stephane

1

Bonjour Stéphane, Dans Ubuntu, Tomcat s'exécute avec un utilisateur tomcat et il se trouve dans le fichier / etc / default / tomcat8 avec les variables TOMCAT8_USER et TOMCAT8_GROUP. Dans d'autres Linux, je ne sais pas.

— intropedro

N'est pas +sdéfini l'ID utilisateur / groupe? La page de manuel indique que +tc'est un peu collant.

— bmaupin

13

La Non-Tomcat settingssection du guide de sécurité de Tomcat fournit des informations utiles sur ce sujet. Vois ici:

Tomcat 7: https://tomcat.apache.org/tomcat-7.0-doc/security-howto.html
Tomcat 8: https://tomcat.apache.org/tomcat-8.0-doc/security-howto.html
Tomcat 9: https://tomcat.apache.org/tomcat-9.0-doc/security-howto.html

Tomcat ne doit pas être exécuté sous l'utilisateur root. Créez un utilisateur dédié pour le processus Tomcat et fournissez à cet utilisateur les autorisations minimales nécessaires pour le système d'exploitation. Par exemple, il ne devrait pas être possible de se connecter à distance à l'aide de l'utilisateur Tomcat.

Les autorisations de fichiers doivent également être convenablement restreintes. Prenons l'exemple des instances Tomcat de l'ASF (où le déploiement automatique est désactivé et les applications Web sont déployées en tant que répertoires éclatés), la configuration standard consiste à faire en sorte que tous les fichiers Tomcat appartiennent à root avec le groupe Tomcat et que le propriétaire ait des privilèges de lecture / écriture , le groupe a uniquement lu et le monde n'a aucune autorisation. Les exceptions sont les journaux, temp et le répertoire de travail qui appartiennent à l'utilisateur Tomcat plutôt qu'à root . Cela signifie que même si un attaquant compromet le processus Tomcat, il ne peut pas modifier la configuration de Tomcat, déployer de nouvelles applications Web ou modifier des applications Web existantes. Le processus Tomcat s'exécute avec un umask de 007 pour conserver ces autorisations.

— Jack
source

Je me demande si l'approche décrite peut être adoptée non seulement dans Tomcat mais également avec d'autres services (base de données, proxy inverse, etc.). Pensez-vous que c'est faisable / sage?

— Paolo

1

Vous devez suivre le principe du moindre privilège . Le serveur (probablement www-data, mais vous devrez vérifier) doit pouvoir lire la plupart des fichiers (disons tous) et écrire uniquement dans les journaux. Les développeurs Web sont autorisés à écrire où ils en ont besoin. Définissez le bit collant sur les répertoires afin que seul le propriétaire d'un fichier puisse le supprimer.

En pratique, vous devez créer un groupe (par exemple webdev) et y ajouter tous les développeurs et le serveur ( usermod -aG webdev <user>ou en usermod -A webdev <user>fonction de votre saveur Linux). chowntous les fichiers et répertoires à l'utilisateur du serveur Web, chmod tous les répertoires à 500 et tous les fichiers à 400 (sauf dans les bincas où les exécutables doivent également être 500).

Accordez des autorisations d'écriture /opt/tomcatau groupe (ce serait 570) et définissez le bit collant de sorte qu'il ne puisse supprimer que les fichiers qu'il possède (chmod 1570). Accordez au serveur l'autorisation d'écriture sur les journaux et les autorisations de lecture aux développeurs (0740 pour le dossier, 0640 pour les fichiers, le bit collant n'est probablement pas nécessaire, et ne l'accordez jamais à un fichier, uniquement aux dossiers, car il a un signification différente (exécuter avec les autorisations du propriétaire lorsque le fichier est exécutable)).

Ensuite, vous devrez accorder des autorisations d'écriture (1570) webdevsur certains répertoires. Vous aurez besoin d'essais et d'erreurs ici, et cela pourrait dépendre de l'application. Ces dossiers doivent être 1570, tandis que d'autres peuvent être 0500).

Les développeurs devront accorder un accès en lecture sur leurs fichiers au groupe afin que le serveur puisse les lire (c'est 640), et également exécuter sur les répertoires (c'est 750).

— Calimo
source

1

Je pense que la réponse acceptée de @ intropedro est bonne. Il vaut la peine de souligner que l'utilisation d'un programme d'installation de package peut économiser beaucoup de maux de tête - au moins pour Tomcat 7 sur Ubuntu, apt-get install tomcat7un ensemble de répertoires d'installation plus "standard" est:

/etc/tomcat7 pour les fichiers de configuration,
/var/lib/tomcat7 pour les bibliothèques principales, et
/usr/share/tomcat7 pour les ressources partagées.

Toutes les autorisations sont correctement configurées avec le principe du moindre privilège, de sorte que l'ajout d'utilisateurs au groupe tomcat7est suffisant pour permettre le déploiement. De plus, le serveur tomcat est configuré comme un service qui peut être démarré et arrêté comme d'autres (par exemple sudo service tomcat startou alternativement /etc/init.d/tomcat start). Tomcat démarre automatiquement au redémarrage et il existe une commande "redémarrer". Je suis sûr qu'il existe un package yum équivalent pour les utilisateurs de RHEL / CentOS. (Et oui, il existe un programme d'installation homebrew pour les installations OSX locales).

Si vous rencontrez des problèmes, il existe un bon utilitaire /usr/share/binappelé configtest.shqui signale les autorisations ou autres erreurs. Remarque, il existe un bogue ouvert qui suggère d'ajouter des liens symboliques .

Nous utilisons toujours Ubuntu trusty(14.04); pour ceux qui exécutent des versions plus récentes, je pense qu'il y a un repo apt-get Tomcat 8.

— Tom Harrison Jr
source