Exceção de Controle de Acesso para Segurança de Java 2

O comportamento da segurança Java™ 2 é especificado por sua política de segurança. O critério de segurança é uma matriz de controle de acesso que especifica quais recursos do sistema certas bases de código podem acessar e quem deve assiná-los. A política de segurança Java 2 é declarativa e imposta pelo método java.security.AccessController.checkPermission.

O exemplo a seguir demonstra o algoritmo para o método java.security.AccessController.checkPermission. Para obter o algoritmo completo, consulte o algoritmo de permissão de verificação de segurança do Java 2 no artigo Segurança: Recursos para aprendizagem.

i = m;
while (i > 0) {
if (caller i's domain does not have the permission)
throw AccessControlException;
else if (responsável pela chamada i está marcado como privilegiado)
return;
i = i - 1;
};

O algoritmo requer que todas as classes ou responsáveis pela chamada na pilha de chamada possuam permissões quando um método java.security.AccessController.checkPermission é executado ou o pedido é negado e uma exceção java.security.AccessControlException é criada. Entretanto, se o responsável pela chamada for marcado como privilegiado e a classe (responsável pela chamada) tiver essas permissões concedidas, o algoritmo retornará e não atravessará a pilha de chamada inteira. As classes (responsáveis por chamadas) subsequentes não necessitam ter concedida a permissão exigida.

Uma exceção java.security.AccessControlException é criada quando determinadas classes na pilha de chamadas não possuem as permissões requeridas durante um método java.security.AccessController.checkPermission. Duas resoluções possíveis para a exceção java.security.AccessControlException são as seguintes:
  • Se o aplicativo estiver chamando uma API (interface de programação de aplicativo) protegida pela segurança Java 2, conceda a permissão necessária à política de segurança Java 2 do aplicativo. Se o aplicativo não estiver chamando uma API protegida pela segurança Java 2 diretamente, a permissão necessária resultará do efeito colateral das APIs de terceiros que acessam recursos protegidos pela segurança Java 2.
  • Se for concedida ao aplicativo a permissão requerida, ela obtém mais acesso do que o necessário. Nesse caso, é provável que o código de terceiros que acessa o recurso protegido pela segurança Java 2 não esteja marcado corretamente como privilegiado.

Exemplo de Pilha de Chamadas

Este exemplo de uma pilha de chamadas indica onde o código do aplicativo está utilizando uma biblioteca de utilitários de API de terceiros para atualizar a senha. O exemplo a seguir é apresentado para ilustrar o ponto. A decisão de onde marcar o código como privilegiado é específica ao aplicativo e é exclusiva em qualquer situação. Essa decisão exige grande profundidade de conhecimento do domínio e de segurança para fazer o julgamento correto. Várias publicações e manuais bem escritos estão disponíveis sobre este tópico. Recomenda-se consultar esses materiais para obter informações mais detalhadas.
Este exemplo de uma pilha de chamada indica onde o código do aplicativo está usando uma biblioteca do utilitário API de terceiro para atualizar a senha. O exemplo a seguir é apresentado para ilustração. A decisão de onde marcar o código como privilegiado é específica do aplicativo e é exclusiva em cada situação. Esta decisão requer profundo conhecimento de domínio e experiência com segurança para fazer o julgamento correto.

É possível usar o utilitário PasswordUtil para alterar a senha de um usuário. O utilitário digita a senha antiga e a senha nova duas vezes para assegurar que a senha correta foi digitada. Se a senha antiga corresponder à armazenada no arquivo de senhas, a nova senha será armazenada e o arquivo de senhas será atualizado. Assuma que nenhum quadro de pilha está marcado como privilegiado. De acordo com o algoritmo java.security.AccessController.checkPermission, o aplicativo falha, a menos que seja concedida a todas as classes na pilha de chamadas permissão de gravação para o arquivo de senha. O aplicativo cliente não possui permissão para gravar no arquivo de senha diretamente e atualizar o arquivo de senha quando desejar.

Entretanto, se o método PasswordUtil.updatePasswordFile marcar o código que acessa o arquivo de senha como privilegiado, o algoritmo de permissão de verificação não verificará a permissão necessária das classes que chamam o método thePasswordUtil.updatePasswordFile para a permissão necessária, contanto que a classe PasswordUtil tenha a permissão concedida. O aplicativo cliente pode atualizar com êxito uma senha, sem conceder a permissão para gravar ao arquivo de senha.

A capacidade de marcar código privilegiado é muito flexível e poderosa. Se essa capacidade for utilizada incorretamente, a segurança geral do sistema pode ser comprometida e falhas na segurança podem ser expostas. Utilize a capacidade para marcar código privilegiado com cuidado.

Resolução para a Exceção java.security.AccessControlException

Como descrito anteriormente, há duas abordagens para resolver uma exceção java.security.AccessControlException. Julgue essas exceções individualmente para decidir qual das seguintes resoluções é melhor:
  1. Conceder a permissão ausente ao aplicativo.
  2. Marcar algum código como privilegiado, após considerar os problemas e riscos.

Ícone que indica o tipo de tópico Tópico de Conceito



Ícone de registro de data e hora Última atualização: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=csec_access
Nome do arquivo: csec_access.html