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

Question

Estoy usando Tomcat 6.0.24, como está 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 una política predeterminada.

A tener en cuenta en el inicio:

• no ha cambiado el archivo tomcat instalar en todos - no hay nuevos frascos en su directorio lib común (IES), no hay server.xml cambios, etc. Poner el. 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 según esta política predeterminada (como se informa al registro gracias a la propiedad del sistema -Djava.security.debug="access,stack,failure").
• apagar el gerente de seguridad completo que no resulta en errores de ningún tipo, y la funcionalidad de la aplicación adecuada

Lo que me gustaría hacer es añadir un archivo de política de seguridad específica de la aplicación al directorio policy.d, que parece ser la práctica recomendada. He añadido esto a policy.d/100myapp.policy (como punto de partida - Me gustaría volver el tiempo recortar los permisos concedidos a sólo 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; 
}; 

Nota del retorcía tratando de encontrar la derecha codeBase declaración. 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) funciona casi: los miles de denegaciones de acceso se han ido, y me queda solo una. Correspondiente seguimiento de la pila:

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á provocando la negación es irrelevante - es presentar sólo algunas propiedades que comprobamos para los parámetros de configuración opcionales. Lo que es interesante es que:

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

Otra solución (además de sólo deshabilitar el administrador de seguridad en Tomcat) es añadir un permiso indefinido a mi archivo de política:

grant { 
    permission java.security.AllPermission; 
}; 

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

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

Answer 1

Tomcat se ejecuta con su propio usuario de tomcat. Los archivos de guerra deben estar visibles para ese usuario, probablemente valga la pena verificarlo primero.

Answer 2

¿Está implementando directamente en el directorio ROOT?

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

Answer 3

Es posible que deba otorgar permisos de acceso a archivos por separado. Intente cambiar la subvención para su 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 los archivos de propiedades (por ejemplo, servlets u otro código de la biblioteca) .

Como solución, y para confirmar si este es el caso, se podría hacer una subvención directa en los .properties 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"; 
} 

En efecto, parece que el ú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 .properties funciona, es posible que desee bloquear la concesión en org.apache.naming.resources.FileDirContext.

¿Obtiene algún rastro de pila específico de su propio código?

Answer 4

¿Estás usando la versión administrada por paquetes de Ubuntu? Tuvimos una pesadilla recientemente con cuestiones de seguridad, pero descubrimos que al descargar Tomcat por separado y al usarlo, los problemas de seguridad desaparecieron.

corroboración:

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

Si está ejecutando Ubuntu y desea utilizar el contenedor de servlets Tomcat, no se debe utilizar la versión de los repositorios, ya que simplemente no funciona correctamente. En cambio, necesitarás usar el proceso de instalación manual que estoy delineando aquí.