Arquivos de Política de Segurança Java 2

O J2EE (Java™ 2 Platform, Enterprise Edition) Versão 1.3 e especificações posteriores possuem um modelo de programação bem-definido de responsabilidades entre os provedores de contêineres e o código do aplicativo. É recomendável utilizar o gerenciador de segurança Java 2 para ajudar a aplicar esse modelo de programação. Determinadas operações não são suportadas no código do aplicativo, pois tais operações interferem com o comportamento e operação dos contêineres. O gerenciador de segurança Java 2 é utilizado no produto para aplicar responsabilidades do contêiner e do código do aplicativo.

Evitar Problemas Evitar Problemas: O servidor de aplicativos não suporta uma implementação customizada do gerenciador de segurança Java.gotcha

Este produto fornece suporte para o gerenciamento de arquivos de critério. Vários arquivos de política no produto são estáticos ou dinâmicos. Política Dinâmica é um gabarito de permissões para um determinado tipo de recurso. Nenhuma base de código relativa é definida no gabarito de política dinâmico. A base de código é calculada dinamicamente dos dados de implementação e tempo de execução.

Arquivos de Critério Estáticos

Tabela 1. Arquivos de Critério Estáticos.

Essa tabela lista o local dos arquivos de política estática.

Arquivo de políticas Location
java.policy

[AIX Solaris HP-UX Linux Windows][z/OS]app_server_root/java/jre/lib/security/java.policy. Permissões padrão são concedidas a todas as classes. A política desse arquivo se aplica a todos os processos ativados por WebSphere Application Server.

server.policy profile_root/properties/server.policy. Permissões padrão são concedidas a todos os servidores do produto.
client.policy profile_root/properties/client.policy. Permissões padrão são concedidas a todos os contêineres de cliente e applets do produto em um nó.
Os arquivos de critério estáticos não são gerenciados por serviços de replicação de configuração e de arquivos. As alterações feitas nesses arquivos são locais e não são replicadas para outros nós na célula do WebSphere Application Server, Network Deployment.

Arquivos de Critério Dinâmicos

Tabela 2. Arquivos de Critério Dinâmicos.

Esta tabela lista o local dos arquivos de políticas dinâmicos.

Arquivo de políticas Location
spi.policy

profile_root/config/cells/cell_name
/nodes/node_name/spi.policy

Esse modelo é para a SPI (Service Provider Interface) ou recursos de terceiros incorporados no produto. Os exemplos de SPI são JMS (Java Message Service) no MQ Series e drivers JDBC (Java Database Connectivity). A base de código para os recursos incorporados é determinada dinamicamente a partir dos dados de configuração (arquivo resources.xml) e de tempo de execução e as permissões definidas nos arquivos spi.policy são aplicadas automaticamente nesses recursos e arquivos JAR especificados no caminho de classe de um adaptador de recursos. A permissão padrão do arquivo spi.policy é java.security.AllPermissions.

library.policy

profile_root/config/cells/cell_name/nodes
/node_name/library.policy

Esse modelo destina-se para a biblioteca (classes de biblioteca Java). É possível definir uma biblioteca compartilhada para utilização em vários aplicativos do produto. A permissão padrão do arquivo library.policy é empty.

app.policy

profile_root/config/cells/cell_name
/nodes/node_name/app.policy

O arquivo app.policy define as permissões padrão que são concedidas a todos os aplicativos corporativos em execução no node_name em cell_name.
Nota: Atualizações no arquivo app.policy só se aplicam aos aplicativos corporativos no nó ao qual pertence o arquivo app.policy.
was.policy

profile_root/config/cells/cell_name
/applications/ear_file_name/deployments/
application_name/META-INF/was.policy

Este gabarito é para permissões específicas do aplicativo. O arquivo was.policy é incorporado no arquivo EAR (Enterprise Archive).

ra.xml rar_file_name/META-INF/was.policy.RAR.

Esse arquivo pode ter uma especificação de permissão, definida no arquivo ra.xml. O arquivo ra.xml é incorporado no arquivo RAR.

As entradas concedidas, especificadas nos arquivos app.policy e was.policy, devem possuir uma base de código definida. Se as entradas concedidas forem especificadas sem um código base, os arquivos de políticas não são carregados apropriadamente e o aplicativo pode falhar. Se a intenção for conceder as permissões a todos os aplicativos, utilize file:${application} como uma base de código na entrada concedida.

Sintaxe do Arquivo de Critério

Um arquivo de critério contém várias entradas de critério. O exemplo a seguir ilustra o formato de cada entrada de critério:
grant [codebase <Codebase>] {
permission <Permission>;
 permission <Permission>;
permission <Permission>;
};

<CodeBase>: 	Uma URL.
			Por exemplo,  "file:${java.home}/lib/tools.jar"
						When [codebase <Codebase>] is not specified, listed 
               listadas são aplicadas a tudo.
						Se o URL terminar com o nome de um arquivo JAR, somente as classes no 
               arquivo JAR pertencem à base de código.
               Se o URL terminar com "/", somente os arquivos de classe no diretório
               especificado pertencem à base de código.
               Se o URL terminar com "*", todos os arquivos JAR e de classe no diretório
               especificado pertencem à base de código.
               Se o URL terminar com "-", todos os arquivos JAR e de classe no diretório 
               especificado e seus subdiretórios pertencem à base de código.
<Permissões>: Consiste em
							Tipo de Permissões  	: nome da classe da permissão
     					Nome de Destino  	: nome especificando o destino
     					Ações            	: ações permitidas no destino
			Por exemplo,
      			java.io.FilePermission "/tmp/xxx", "read,write"
Consulte as especificações do Developer Kit para obter detalhes de cada permissão.

Sintaxe de Critério Dinâmico

É possível definir permissões para tipos específicos de recursos em arquivos de critério dinâmico para um aplicativo corporativo. Esta ação é alcançada utilizando símbolos reservados do produto. O escopo do símbolo reservado depende de onde ele é definido. Se você definir as permissões no arquivo app.policy, o símbolo aplica-se a todos os recursos em todos os aplicativos corporativos que são executados no node_name. Se você definir as permissões no arquivo META-INF/was.policy, o símbolo aplica-se apenas ao aplicativo corporativo específico. Os símbolos válidos para a base de código são listados na seguinte tabela:
Tabela 3. Sintaxe de Política Dinâmica.

Esta tabela descreve os símbolos válidos para o código base para arquivos de políticas dinâmicos.

Símbolo Significado
file:${application} As permissões aplicam-se a todos os recursos do aplicativo
file:${jars} As permissões aplicam-se a todos os arquivos JAR (Java archive) do utilitário no aplicativo
file:${ejbComponent} As permissões aplicam-se aos recursos EJB (Enterprise JavaBeans) no aplicativo
file:${webComponent} Permissões se aplicam a recursos da web dentro do aplicativo
file:${connectorComponent} As permissões aplicam-se aos recursos do conector do aplicativo
É possível especificar o nome do módulo para uma configuração granular, exceto pelas entradas especificadas pelos símbolos da base de código. Exemplo:
grant codeBase "file:DefaultWebApplication.war" {
   permission java.security.SecurityPermission "printIdentity";
 };

grant codeBase "file:IncCMP11.jar" {
permission java.io.FilePermission 
"${user.install.root}${/}bin${/}DefaultDB${/}-", 
"read,write,delete";
};
A sexta e a sétima linhas na amostra de código anterior são uma linha contínua. É possível utilizar uma base de código relativa apenas no arquivo META-INF/was.policy. Vários símbolos reservados do produto são definidos para associar as listas de permissões a um tipo específico de recurso.
Tabela 4. Sintaxe de Política Dinâmica.

Esta tabela descreve vários símbolos reservados do produto que são definidos para associar as listas de permissões a um tipo de recurso específico.

Símbolo Significado
file:${application} As permissões aplicam-se a todos os recursos do aplicativo
file:${jars} As permissões aplicam-se a todos os arquivos JAR utilitários do aplicativo
file:${ejbComponent} As permissões aplicam-se aos recursos dos enterprise beans do aplicativo
file:${webComponent} Permissões se aplicam a recursos da web dentro do aplicativo
file:${connectorComponent} As permissões aplicam-se aos recursos do conector tanto no aplicativo quanto nos recursos de conector independente.
São fornecidos cinco símbolos incorporados para especificar o caminho e o nome para a permissão java.io.FilePermission. Esses símbolos permitem ativar as especificações das permissões flexíveis. O caminho do arquivo absoluto é fixo depois da instalação do aplicativo.
Tabela 5. Sintaxe de Política Dinâmica.

Esta tabela descreve os símbolos integrados que são fornecidos para especificar o caminho e nome para a permissão java.io.FilePermission.

Símbolo Significado
${app.installed.path} O caminho onde o aplicativo está instalado
${was.module.path} O caminho em que o módulo está instalado
${current.cell.name} Nome atual da célula.
${current.node.name} Nome atual do nó.
${current.server.name} Nome atual do servidor.
Atenção: Não utilize ${was.module.path} na entrada ${application}.

Determine com cuidado onde incluir uma nova permissão. Uma permissão especificada incorretamente causa uma exceção AccessControlException. Como a política dinâmica resolve o código base no tempo de execução, determinar qual arquivo de políticas apresenta um problema é difícil. Inclua uma permissão somente para os recursos necessários. Por exemplo, utilize ${ejbcomponent} e etc em vez de ${application}, e atualize o arquivo was.policy em vez do arquivo app.policy, se possível.

Filtragem de Critério Estático

Existe suporte limitado a filtragem de critério estático. Se os arquivos app.policy e was.policy tiverem permissões definidas no arquivo filter.policy com a palavra-chave filterMask, o tempo de execução removerá as permissões dos aplicativos e uma mensagem de auditoria será registrada. No entanto, se as permissões definidas nos arquivos app.policy e was.policy forem permissões compostas, por exemplo, java.security.AllPermission, a permissão não será removida, mas uma mensagem de aviso será gravada no arquivo de log. A filtragem de política suporta somente permissões do Developer Kit; o nome do pacote de permissões começa com java ou javax.

O suporte à filtragem da política de tempo de execução é fornecido para forçar uma filtragem mais restrita. Se os arquivos app.policy e was.policy tiverem as permissões definidas no arquivo filter.policy com a palavra-chave runtimeFilterMask, o tempo de execução removerá as permissões dos aplicativos, sem levar em consideração se elas foram concedidas ao aplicativo. Por exemplo, mesmo se um arquivo was.policy tiver a permissão java.security.AllPermission concedida a um de seus módulos, as permissões especificadas, como a runtimeFilterMask, serão removidas da concedida durante o tempo de execução.

Edição de Arquivo de Critério

Recomenda-se utilizar a ferramenta de política fornecida pelo Developer Kit (app_server_root/java/jre/bin/policytool) para editar os arquivos de política anteriores. Para WebSphere Application Server, Network Deployment, extraia os arquivos de políticas do repositório antes de editar. Depois de extrair o arquivo de critério, utilize a ferramenta de critério para editá-lo. Verifique os arquivos de política modificados no repositório e sincronize-os com outros nós.

Resolução de problemas

Para depurar a política dinâmica, escolha uma das três maneiras para gerar o relatório de detalhes da exceção AccessControlException.
  • Rastreio (Configurado pelo rastreio de RAS). Ativa rastreios com a especificação de rastreio:
    Atenção: O comando a seguir é uma linha contínua
    com.ibm.ws.security.policy.*=all=enabled:
    com.ibm.ws.security.core.SecurityManager=all=enabled
  • Rastreio (Configurado por propriedade). Especifica uma propriedade java.security.debug Java. Os valores válidos para a propriedade java.security.debug são os seguintes:
    • Accesso. Imprime todas as informações de depuração, incluindo permissão requerida, código, pilha e local da base de código.
    • Pilha. Imprime informações de depuração, incluindo permissão, código e pilha.
    • Falha. Imprime informações de depuração, incluindo a permissão requerida e o código.
  • ffdc. Ativa ffdc, modifica o arquivo ffdcRun.properties alterando Level=4 e LAE=true. Procure uma palavra-chave de Violação de Acesso no arquivo de registro.

Ícone que indica o tipo de tópico Tópico de Referência



Í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=rsec_rpolicydir
Nome do arquivo: rsec_rpolicydir.html