java - por - su configuracion de seguridad ha bloqueado la ejecucion de una aplicacion que no es de confianza

Aviso sobre el atributo Permisos al ejecutar un applet con JRE 7u45 (12)

Acabo de actualizar JRE a 7u45, y mi applet recibe un mensaje de advertencia en el inicio que dice "Esta aplicación se bloqueará en una futura actualización de seguridad de Java porque el manifiesto del archivo JAR no contiene el atributo Permisos". Luego agregué los siguientes dos atributos al manifiesto de mi archivo Jar applet (autofirmado):

Permissions: all-permissions Codebase: *

Sin embargo, el mensaje de advertencia no desapareció. Dudo que me esté perdiendo algunas otras cosas, pero no puedo encontrarlas después de horas de investigación. ¿Alguien más sabe la solución?

Actualizar

El applet de confianza firmado con un certificado válido tampoco puede ejecutarse. El mensaje de advertencia amarillo no aparece, pero se muestra otro cuadro de diálogo de error que indica que la configuración de seguridad bloquea el applet, mientras que cambiar el nivel de seguridad o cualquier otra cosa en el Panel de Control de Java no ayuda.

Agregue la url base a la lista de sitios seguros (exceptuados de cheques) en la pestaña de seguridad del panel de control de Java, que hizo que mi vpn se inicie nuevamente:

Coloqué mi Seguridad Java en Medio, y ahora puedo acceder al programa.

De los nuevos requisitos de seguridad para RIA en 7u51 (enero de 2014) en el "Grupo de plataforma Java, blog de administración de productos":

A partir del 7u51, (14 de enero de 2014), sus RIA deben actualizarse. [...]
Los RIA deben contener dos cosas:
Código de firmas de una autoridad de confianza. [...]

Por lo tanto, parece que el problema es utilizar un certificado autofirmado.

Creo que está claro que un certificado autofirmado no es de mucha utilidad como introducción para un usuario final.

Después de dedicar algo de tiempo a analizar mi manifiesto de edición (vea cómo configurar el manifiesto con Maven) y todas esas configuraciones Java, he descubierto cómo funciona:

Para otorgar todos los permisos con java 1.7+ necesita editar el archivo java.policy .

Utilice la herramienta de política para hacer eso. En la línea de comando del sistema:

policytool

consulte el tutorial de Oracle: http://docs.oracle.com/javase/tutorial/security/tour1/wstep2.html

Abra el archivo de políticas correcto donde se está ejecutando su navegador vm. Para mi esta en

C: / Archivos de programa (x86) / Java / jre7 / lib / security / java.policy

Debe cargar alguna lista de CodeBase. Haga clic en él para editar o:

Añadir entrada

Deje CodBase en blanco para cada ubicación donde se esté ejecutando el código, pero puede poner localhost o su sitio si lo desea y firmado en blanco para los jars / applets no firmados. Haga clic en Agregar permiso , luego elija Todos los permisos
Tengo CodeBase <ALL> y java.security.AllPermission

¡Entonces salva ! java.policy y debería recibir un mensaje de éxito.

Listo puedes ejecutar applets y archivos de disco de acceso no firmados.

Ejecute el applet de desinstalación de Java para eliminar versiones antiguas de Java. http://java.com/en/download/uninstallapplet.jsp

En 1.7.0_u45 probablemente necesitará tener establecidos tanto los permisos como los atributos de base de código permitidos por la persona que llama:

Caller-Allowable-Codebase: * localhost 127.0.0.1 Permissions: all-permissions

Vea este diagrama que explica las ventanas emergentes de seguridad.

Estoy configurando mis atributos manifiestos de esta manera:

Application-Name: MyAppName Implementation-version: %VERSION% Permissions: all-permissions Caller-Allowable-Codebase: * localhost 127.0.0.1 Application-Library-Allowable-Codebase: *

En su panel de control de Java, cambie el nivel de seguridad a Muy alto, de esa manera bloqueará la ejecución del applet porque le falta el atributo de permisos requerido. Ejecute su aplicación, se lanzará una excepción que le indicará a qué tarro le falta el atributo.

Tenía la impresión de que agregar el atributo Permisos al frasco principal del applet sería suficiente, pero acabo de descubrir que incluso un frasco auxiliar puede causar el problema. Ahora agregaré el atributo Permisos a todos mis archivos jar.

Espero que esto ayude a alguien.

No sé que mi respuesta original (eliminada) fue incorrecta. El atributo Permisos en el manifiesto no debe ignorarse en un applet local, por lo tanto, es un error.

Hay problemas conocidos similares descritos en las notas de la versión 7u45. Esto debe estar relacionado.

En cuanto a la pregunta original: Codebase: *?

Codebase: localhost

Funciona para http://localhost y no contradice file://localhost/C:/folder , que (en Windows) es la sintaxis de base de código JNLP correcta. El atributo Codebase en el manifiesto permite múltiples entradas. Añadir localhost seguramente no tendrá efectos adversos.

Actualizar:

Manifest-Version: 1.0 Implementation-Title: MyApplet Implementation-Version: applet build Built-By: bnicer Application-Name: Slide Show Created-By: 1.7.0_45-b18 (Oracle Corporation) Caller-Allowable-Codebase: * Implementation-Vendor: MyFirm Ant-Version: Apache Ant 1.9.2 Trusted-Library: true Application-Library-Allowable-Codebase: * Built-On: 8 November, 2013 @ 13:40:10 GMT Trusted-Only: true Permissions: all-permissions Main-Class: jtss Codebase: www.mydomain.co.uk localhost 127.0.0.1 192.168.2.2

Creo que ejecutar un applet fuera de línea en 7u45 hará problemas sin importar lo que pongas en un manifiesto, y eso es muy desafortunado.

Por lo que puedo decir, el método anterior de agregar un archivo .java.policy al directorio local no tiene sentido, y eso también es desafortunado.

Más información:

(¿En relación con el error?)

Si el applet está firmado, tiene la opción de importar el certificado público (.csr, .p12, .cer) en el Panel de control de Java: Security > Manage Certificates > User > Signer CA. La importación del certificado en el pasado aseguró: A) el editor del applet era conocido. B) se eliminaría la ventana emergente de seguridad antes de ejecutar el applet en el navegador.

Aplicaciones web de inicio, ídem.

La diferencia es que ahora (7u45): A) el editor es conocido. B) recibe una advertencia "... el manifiesto no contiene el atributo Permisos".

Sólo applets locales.

Después de la advertencia, según mi experiencia, el applet no se ejecutará.

java.lang.RuntimeException: java.lang.reflect.InvocationTargetException at sun.plugin2.applet.Plugin2ClassLoader.defineClassHelper(Unknown Source) at sun.plugin2.applet.Plugin2ClassLoader.access$100(Unknown Source) at sun.plugin2.applet.Plugin2ClassLoader$2.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at sun.plugin2.applet.Plugin2ClassLoader.findClassHelper(Unknown Source) at sun.plugin2.applet.Applet2ClassLoader.findClass(Unknown Source) at sun.plugin2.applet.Plugin2ClassLoader.loadClass0(Unknown Source) at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source) at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at sun.plugin2.applet.Plugin2ClassLoader.loadCode(Unknown Source) at sun.plugin2.applet.Plugin2Manager.initAppletAdapter(Unknown Source) at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Caused by: java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) ... 14 more Caused by: java.lang.NullPointerException at sun.plugin2.applet.Plugin2ClassLoader.loadAllowedCodebases(Unknown Source) at sun.plugin2.applet.Plugin2ClassLoader.getPermissions(Unknown Source) at sun.plugin2.applet.Applet2ClassLoader.getPermissions(Unknown Source) at java.security.SecureClassLoader.getProtectionDomain(Unknown Source) at java.security.SecureClassLoader.defineClass(Unknown Source) at java.net.URLClassLoader.defineClass(Unknown Source) ... 18 more

Una solución Signer CA , pero de ninguna manera una solución, es eliminar el certificado del almacén de Signer CA del Signer CA . Al eliminar el certificado (en desesperación, como último recurso), el applet local firmado se ejecuta de la siguiente manera: A) Publisher desconocido, etc.

Nada de lo anterior se aplica a los applets en línea.

Siéntete libre de comentar.

Si está usando webstart con un protocolo basado en versión, parece que hay un error con esto que provoca la advertencia del atributo Permisos cuando no debería. Una vez que eliminamos los atributos de la versión de nuestro jnlp, y eliminamos la cadena de la versión de los nombres de archivo jar, desapareció la advertencia del atributo Permisos.

Edición: Encontré este hilo del foro que trata el tema: https://forums.oracle.com/thread/2594060 .

Tengo el mismo problema. Lo pruebo con una base de código explícita, pero la advertencia "Atributo del manifiesto de permisos faltantes" sigue apareciendo.

También se intentó cambiar los permisos a "sandbox", el mensaje sigue apareciendo pero el applet no tiene privilegios para ejecutar algunas funciones.

Editar:

Finalmente he encontrado la solución: manifest.mf

Manifest-Version: 1.0 Codebase: * Permissions: all-permissions Application-Library-Allowable-Codebase: * Caller-Allowable-Codebase: * Application-Name: AppName Created-By: AppCreator

Espero que esto te ayude.

Tuve el mismo error al intentar abrir la consola virtual de Dell iDRAC. Esto no ayuda si desea deshacerse de las advertencias de una manera adecuada. Pero si solo desea ejecutar la aplicación, entonces para mí la solución fue abrir el Panel de control de Java y en la pestaña Seguridad, establecer Nivel de seguridad en Medio .

Después de eso pude ejecutar la aplicación después de aceptar las advertencias.

También estaba enfrentando este problema y resolví este problema en mi aplicación simplemente agregando el certificado como "Sitio seguro" en el centro de control de java.

El mensaje de error ("La aplicación se bloqueará ... el atributo de Permiso") es tan engañoso y actúa más como un mensaje de error genérico y no tiene nada que ver con el atributo de Permisos realmente presente en los archivos jar o no. Esto para mí es un error y espero que Java lo arregle en la próxima versión.

Pasos exactos para eliminar este mensaje de error:
1) javaws -viewer
2) Abrir pestaña de seguridad
3) Haga clic en "Administrar certificados"
4) Seleccione el tipo de certificado como "Sitio seguro"
5) Añadir el certificado de solicitud.