mejores prácticas para el permiso de acceso a los usuarios de apache tomcat

Tengo una caja de Linux compartida por varios desarrolladores. Quieren desplegar sus archivos war en apache tomcat que en una ubicación compartida (/ opt / tomcat).

Como no tienen acceso a sudo, tengo que cambiar el permiso de carpeta para el directorio tomcat.

estructura de directorio bajo /opt/tomcates -

bin/

conf/

lib/

logs/

temp/

webapps/

work/

¿Cuáles son las mejores prácticas en la situación anterior: el permiso de acceso más adecuado para el usuario? Por el momento, he cambiado el permiso a 777 para webapps y registros.

Gracias

Lo hago de esta manera:

Ponemos al usuario tomcat como el propietario de la carpeta de tomcat:

# chown -R tomcat:tomcat /opt/tomcat

Los usuarios no pueden modificar la configuración de tomcat:

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

Los usuarios pueden modificar las otras carpetas:

# 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

Active el bit adhesivo para archivos nuevos y mantenga los permisos definidos:

# 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

Finalmente, agregamos el grupo tomcat que queremos usuarios que puedan usar el tomcat:

# usermod -a -G tomcat MIUSER

La Non-Tomcat settingssección del tutorial de seguridad de Tomcat proporciona información útil sobre este tema. Mira aquí:

• 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 no debe ejecutarse bajo el usuario root. Cree un usuario dedicado para el proceso de Tomcat y proporcione a ese usuario los permisos mínimos necesarios para el sistema operativo. Por ejemplo, no debería ser posible iniciar sesión de forma remota con el usuario de Tomcat.

Los permisos de archivo también deben restringirse adecuadamente. Tomando las instancias de Tomcat en el ASF como ejemplo (donde la implementación automática está deshabilitada y las aplicaciones web se implementan como directorios desglosados), la configuración estándar es tener todos los archivos Tomcat propiedad de root con el grupo Tomcat y mientras el propietario tiene privilegios de lectura / escritura , el grupo solo tiene lectura y el mundo no tiene permisos. Las excepciones son los registros, temp y directorio de trabajo que son propiedad del usuario de Tomcat en lugar de root . Esto significa que incluso si un atacante compromete el proceso de Tomcat, no puede cambiar la configuración de Tomcat, implementar nuevas aplicaciones web o modificar aplicaciones web existentes. El proceso de Tomcat se ejecuta con una máscara de 007 para mantener estos permisos.

Debe seguir el principio del menor privilegio . El servidor (probablemente www-data, pero deberá verificarlo) debe poder leer la mayoría de los archivos (digamos todos) y escribir solo en los registros. Los desarrolladores web pueden escribir donde lo necesiten. Establezca el bit adhesivo en los directorios para que solo el propietario de un archivo pueda eliminarlo.

En la práctica, debe crear un grupo (por ejemplo webdev) y agregarle todos los desarrolladores y el servidor ( usermod -aG webdev <user>o usermod -A webdev <user>según su sabor de Linux). chowntodos los archivos y directorios para el usuario del servidor web, chmod todos los directorios a 500 y todos los archivos a 400 (excepto en bindonde los ejecutables también deben ser 500).

Otorgue permisos de escritura /opt/tomcatal grupo (que sería 570) y establezca el bit fijo para que puedan eliminar solo los archivos que poseen (chmod 1570). Otorgue al servidor permiso de escritura para los registros y lea los permisos para los desarrolladores (0740 para la carpeta, 0640 para los archivos, el bit adhesivo probablemente no sea necesario, y nunca lo otorgue a un archivo, solo a las carpetas, ya que tiene un significado diferente (ejecutar con los permisos del propietario cuando el archivo es ejecutable)).

Luego deberá otorgar permisos de escritura (1570) webdeven algunos de los directorios. Necesitará alguna prueba y error aquí, y podría depender de la aplicación. Esas carpetas deben ser 1570, mientras que otras pueden ser 0500).

Los desarrolladores deberán otorgar acceso de lectura en sus archivos al grupo para que el servidor pueda leerlos (eso es 640) y también ejecutarlos en los directorios (eso es 750).

Creo que la respuesta aceptada de @ intropedro es buena. Vale la pena señalar que usar un instalador de paquetes puede ahorrar muchos dolores de cabeza, al menos para Tomcat 7 en Ubuntu apt-get install tomcat7produce un conjunto de directorios de instalación más "estándar":

• /etc/tomcat7 para archivos de configuración,
• /var/lib/tomcat7 para bibliotecas centrales, y
• /usr/share/tomcat7 por recursos compartidos.

Todos los permisos están configurados correctamente con el principio de privilegio mínimo, de modo que agregar usuarios al grupo tomcat7es suficiente para permitir la implementación. Además, el servidor Tomcat está configurado como un servicio que se puede iniciar y detener como otros (por ejemplo, sudo service tomcat starto alternativamente /etc/init.d/tomcat start). Tomcat se reinicia automáticamente y hay un comando "reiniciar". Estoy seguro de que hay un paquete yum equivalente para usuarios de RHEL / CentOS. (Y sí, hay un instalador homebrew para instalaciones locales de OSX).

Si tiene problemas, hay una buena utilidad /usr/share/binllamada configtest.shque informa si hay permisos u otros errores. Tenga en cuenta que hay un error abierto que sugiere agregar algunos enlaces simbólicos .

Todavía estamos ejecutando Ubuntu trusty(14.04); Para aquellos que ejecutan versiones más recientes, creo que hay un Tomcat 8 apt-get repo.