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.

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
Arquivo de políticas | Location |
---|---|
java.policy |
|
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ó. |
Arquivos de Critério Dinâmicos
Arquivo de políticas | Location |
---|---|
spi.policy | profile_root/config/cells/cell_name 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 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 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 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. |
Sintaxe do Arquivo 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: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 |
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";
};
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í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. |
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
- 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.