Excepción de control de acceso para la seguridad de Java 2

El comportamiento de la seguridad de Java™ 2 viene especificado por la política de seguridad. La política de seguridad es una matriz de control de acceso que especifica a qué recursos del sistema pueden acceder determinadas bases de códigos y quién debe firmarlos. La política de seguridad de Java 2 es declarativa y obligatoria por el método java.security.AccessController.checkPermission.

El siguiente ejemplo muestra el algoritmo del método java.security.AccessController.checkPermission. Para ver el algoritmo completo, consulte el algoritmo de permiso de comprobación de seguridad de Java 2 en el artículo de Seguridad: Recursos de aprendizaje.

i = m;
while (i > 0) {
if (caller i's domain does not have the permission)
throw AccessControlException;
else if (caller i is marked as privileged)
return;
i = i - 1;
};

El algoritmo requiere que todas las clases o llamantes de la pila de llamadas tengan los permisos cuando se ejecute un método java.security.AccessController.checkPermission, o se deniegue la solicitud y se genere la excepción java.security.AccessControlException. No obstante, si el llamante se marca como privilegiado y se le otorgan estos permisos a la clase (llamante), el algoritmo se devuelve y no pasa por toda la pila de llamadas. Las siguientes clases (llamantes) no necesitan tener el permiso necesario.

Se genera una excepción java.security.AccessControlException cuando determinadas clases de la pila de llamadas no tienen los permisos necesarios durante un método java.security.AccessController.checkPermission. Éstas son las dos soluciones posibles a la excepción java.security.AccessControlException:
  • Si la aplicación llama a una interfaz de programas de aplicación (API) protegida de seguridad de Java 2, otorgue el permiso necesario a la política de seguridad de Java 2 de la aplicación. Si la aplicación no llama directamente a una API protegida de seguridad de Java 2, el permiso necesario se debe al efecto colateral de las API de terceros que acceden a los recursos protegidos de seguridad de Java 2.
  • Si se le otorga el permiso necesario a la aplicación, ésta obtiene más acceso del necesario. En este caso, es probable que el código de terceros que accede al recurso protegido de seguridad de Java 2 no esté marcado correctamente como privilegiado.

Pila de llamadas de ejemplo

Este ejemplo de una pila de llamadas indica dónde utiliza el código de aplicación una biblioteca de programa de utilidad de API de terceros para actualizar la contraseña. El siguiente ejemplo permite ilustrar este concepto. La decisión sobre dónde marcar el código como privilegiado depende de cada aplicación y es exclusiva en cada situación. Esta decisión requiere un gran conocimiento del dominio y experiencia en seguridad. Hay disponibles excelentes publicaciones y manuales sobre este tema. Se recomienda que consulte estos materiales para obtener información más detallada.
Este ejemplo de pila de llamadas indica dónde está utilizando el código de aplicación una biblioteca de programas de utilidad de API de otras empresas para actualizar la contraseña. Se presenta el ejemplo siguiente para ilustrar el punto. La decisión de dónde se debe marcar el código como privilegiado es específico de aplicación y es exclusivo en cada situación. Para tomar esta decisión es necesario tener conocimientos profundos del dominio y mucha experiencia en seguridad para tener el criterio correcto.

Puede utilizar el programa de utilidad PasswordUtil para cambiar la contraseña de un usuario. El programa de utilidad escribe la antigua contraseña y la nueva contraseña dos veces para asegurarse de que ha especificado la correcta. Si la antigua contraseña coincide con la almacenada en el archivo de contraseña, se almacena la nueva contraseña y se actualiza el archivo de contraseña. Supongamos que ninguno de los marcos de las pilas está marcado como privilegiado. De acuerdo con el algoritmo java.security.AccessController.checkPermission, la aplicación dará error a menos que todas las clases de la pila de llamadas tengan permiso de escritura en el archivo de contraseña. La aplicación cliente no tiene permiso para escribir directamente en el archivo de contraseña y actualizarlo libremente.

Sin embargo, si el método PasswordUtil.updatePasswordFile marca el código que accede al archivo de contraseña como privilegiado, el algoritmo de comprobación de permisos no comprueba el permiso necesario de las clases que llamen al método PasswordUtil.updatePasswordFile siempre que la clase PasswordUtil tenga el permiso. La aplicación cliente podrá actualizar entonces una contraseña sin otorgar el permiso para escribir en el archivo de contraseña.

La capacidad de marcar el código como privilegiado es muy flexible y potente. Si no se utiliza correctamente, la seguridad general del sistema peligra y pueden aparecer brechas de seguridad. Utilice con precaución la capacidad de marcar código como privilegiado.

Resolución de la excepción java.security.AccessControlException

Como se ha descrito anteriormente, una excepción java.security.AccessControlException se puede resolver de dos formas distintas. Juzgue estas excepciones individualmente para decidir cuál de las soluciones siguientes es la mejor:
  1. Otorgar el permiso que falta a la aplicación.
  2. Marcar parte del código como privilegiado, después de tener en cuenta los riesgos que supone.

Icon that indicates the type of topic Concept topic



Timestamp icon Last updated: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=csec_access
File name: csec_access.html