java - configurar - tomcat 9 ssl

Cómo configurar correctamente la política de seguridad en Tomcat 6

Question

Estoy usando Tomcat 6.0.24, empaquetado para Ubuntu Karmic. La política de seguridad predeterminada del paquete Tomcat de Ubuntu es bastante estricta, pero parece sencilla. En /var/lib/tomcat6/conf/policy.d , hay una variedad de archivos que establecen la política predeterminada.

Vale la pena señalar al principio:

• No he cambiado la instalación de tomcat original en absoluto: no hay nuevos archivos server.xml en su (s) directorio (s) de server.xml comunes, no server.xml cambios en server.xml , etc. Poner el archivo .war en el directorio webapps es la única acción de implementación.
• la aplicación web que estoy implementando falla con miles de denegaciones de acceso bajo esta política predeterminada (según se informa al registro gracias a la -Djava.security.debug="access,stack,failure" del sistema -Djava.security.debug="access,stack,failure" ).
• apagar el administrador de seguridad no genera ningún error y la funcionalidad de la aplicación es adecuada.

Lo que me gustaría hacer es agregar un archivo de política de seguridad específico de la policy.d directorio policy.d , que parece ser la práctica recomendada. policy.d/100myapp.policy esto a policy.d/100myapp.policy (como punto de partida, me gustaría recortar los permisos concedidos a lo que realmente necesita la aplicación):

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;
};

Tenga en cuenta los intentos de encontrar la base de codeBase correcta. Creo que ese es probablemente mi problema fundamental.

De todos modos, lo anterior (en realidad solo las dos primeras subvenciones parecen tener algún efecto) casi funciona: los miles de denegaciones de acceso han desaparecido, y solo me queda una. Rastreo de pila relevante:

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)

Estoy bastante convencido de que el archivo real que está desencadenando la denegación es irrelevante: solo comprobamos los parámetros de configuración opcionales en algunos archivos de propiedades. Lo que es interesante es que:

1. no existe en este contexto
2. el hecho de que el archivo no exista termina lanzando una excepción de seguridad, en lugar de java.io.File.exists() simplemente devolviendo falso (aunque supongo que eso es solo una cuestión de la semántica del permiso de lectura).

Otra solución (además de simplemente deshabilitar el administrador de seguridad en Tomcat) es agregar un permiso abierto a mi archivo de política:

grant {
permission java.security.AllPermission;
};

Supongo que esto es funcionalmente equivalente a apagar el administrador de seguridad.

Supongo que debo estar obteniendo la declaración codeBase en mis subvenciones sutilmente equivocadas, pero no la estoy viendo en este momento.

Answer 1

¿Está implementando directamente en el directorio ROOT?

Por lo general, cuando pones una guerra en la carpeta webapps, digamos 100myapp.war , se desempaqueta en una carpeta llamada 100myapp . ¿No deberían hacerse las subvenciones en esta nueva carpeta en lugar de la carpeta ROOT?

Answer 2

¿Está utilizando la versión gestionada por paquetes de Ubuntu? Recientemente tuvimos una pesadilla con cosas de seguridad, pero descubrimos que al descargar Tomcat por separado y usar eso, los problemas de seguridad desaparecieron.

Corroboración:

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

Si está ejecutando Ubuntu y desea usar el contenedor de servlets de Tomcat, no debe usar la versión de los repositorios ya que simplemente no funciona correctamente. En su lugar, deberá utilizar el proceso de instalación manual que describo aquí.

Answer 3

Es posible que tenga que otorgar permisos de acceso a archivos por separado. Intenta cambiar la subvención para tu aplicación a:

grant codeBase "file:${catalina.base}/webapps/ROOT.war" {
permission java.security.AllPermission;
permission java.io.FilePermission "file:${catalina.base}/webapps/ROOT/-", "read, write";
}

Si eso no funciona, entonces podría ser que algún código fuera de lo que cubren sus subvenciones existentes esté accediendo a esos archivos de propiedades (por ejemplo, servlet u otro código de biblioteca).

Como solución alternativa, y para confirmar si este es el caso, puede hacer una concesión directa a las propiedades que le están causando el problema:

grant {
permission java.io.FilePermission "file:${catalina.base}/webapps/ROOT/WEB-INF/classes/com/foo/some-file-here.txt", "read, write";
}

De hecho, parece que este último podría ser el caso, ya que el seguimiento de la pila muestra el código en el cargador de contexto de Tomcat. Si la concesión directa en el .properties funciona, es posible que desee bloquear la concesión a org.apache.naming.resources.FileDirContext.

¿Obtienes algún rastro de pila específico para tu propio código?

Answer 4

Tomcat corre con su propio usuario tomcat. Los archivos war deben ser visibles para ese usuario, ¿probablemente vale la pena revisar eso primero?