Segurança do Java 2
A segurança do Java™ 2 fornece um mecanismo de controle de acesso de baixa granularidade com base em política que aumenta a integridade geral do sistema verificando as permissões antes de permitir o acesso a determinados recursos protegidos do sistema. A segurança do Java 2 protege o acesso aos recursos do sistema, como E/S de arquivos, soquetes e propriedades. A segurança do Java 2 Platform, Enterprise Edition (J2EE) protege acesso aos recursos da Web, como servlets, arquivos JavaServer Pages (JSP) e métodos Enterprise JavaBeans (EJB).
Como a segurança do Java 2 é relativamente nova, muitos aplicativos existentes ou até mesmo novos podem não estar preparados para o modelo de programação de controle de acesso que a segurança do Java 2 é capaz de impingir. Os administradores precisam compreender as possíveis consequências da ativação da segurança do Java 2 se os aplicativos não estiverem preparados para a segurança do Java 2. A segurança do Java 2 aplica alguns requisitos novos nos desenvolvedores e administradores de aplicativos.
![[IBM i]](../images/iseries.gif)

Segurança do Java 2 para Implementadores e Administradores
Embora a segurança do Java 2 seja suportada, ela está desativada por padrão. É possível configurar a segurança do Java 2 e a segurança administrativa independentemente uma da outra. A desativação da segurança administrativa não desativa a segurança do Java 2 automaticamente. É necessário desativá-la explicitamente.
Se seus aplicativos ou bibliotecas de terceiros não estiverem prontos, a ativação da segurança do Java 2 poderá causar problemas. É possível identificar esses problemas como AccessControlExceptions da segurança do Java 2 no log do sistema ou nos arquivos de rastreio. Se não tiver certeza sobre a prontidão da segurança do Java 2 em seus aplicativos, desative a segurança do Java 2 inicialmente até instalar o aplicativo e verificar se ele está funcionando corretamente.
A política incorporada por esses arquivos de política não pode ser tornada mais restritiva, pois o produto pode não ter as APIs doPrivileged da segurança do Java 2 necessárias no lugar. A política restritiva é a política padrão. É possível conceder permissões adicionais, mas não pode tornar o padrão mais restritivo, pois as exceções AccessControlExceptions são geradas de dentro do WebSphere Application Server. O produto não suporta uma política mais restritiva do que a padrão definida nos arquivos de políticas previamente mencionados.
Vários arquivos de política são utilizados para definir a política de segurança do processo Java. Esses arquivos de política são estáticos (o código base é definido no arquivo de política) e no formato de política padrão fornecido pelo IBM® Developer Kit, Java Technology Edition. Para recursos do aplicativo corporativo e bibliotecas do utilitário, o WebSphere Application Server fornece suporte de política dinâmica. O código base é calculado dinamicamente com base nas informações de implementação e nas permissões concedidas com base em arquivos de política do modelo durante o tempo de execução. Consulte o Arquivos de Política de Segurança Java 2 para obter informações adicionais.
Erros de sintaxe nos arquivos de políticas fazem com que o processo do servidor de aplicativos falhe, portanto, edite esses arquivos de políticas cuidadosamente.
![[IBM i]](../images/iseries.gif)
Se um aplicativo não estiver preparado para a segurança do Java 2, se o provedor de aplicativos não fornecer um arquivo was.policy como parte do aplicativo, ou se o provedor de aplicativos não comunicar as permissões esperadas, provavelmente o aplicativo causara exceções de controle de acesso da segurança do Java 2 no tempo de execução. Pode não parecer óbvio que um aplicativo não esteja preparado para a segurança do Java 2. Vários auxílios de depuração do tempo de execução ajudam a solucionar problemas de aplicativos que possam ter exceções de controle de acesso. Consulte os auxílios de depuração da segurança do Java 2 para obter mais detalhes. Consulte Tratando Aplicativos Cuja Segurança do Java 2 Não Está Pronta para obter informações e estratégias sobre como lidar com tais aplicativos.
É importante observar quando a segurança do Java Security está ativada nas configurações da segurança administrativa, pois o gerenciador de segurança instalado não verifica atualmente as permissões modifyThread e modifyThreadGroup de encadeamentos que não são do sistema. Permitir que o código do aplicativo da Web e Enterprise JavaBeans (EJB) crie ou modifique um encadeamento pode ter um impacto negativo sobre outros componentes do contêiner e pode afetar a capacidade do contêiner em gerenciar ciclos de vida e transações do enterprise bean.
Segurança do Java 2 para Desenvolvedores de Aplicativos
Os desenvolvedores de aplicativos devem compreender as permissões que são concedidas na política padrão do WebSphere e os requisitos de permissão das APIs do SDK que os aplicativos chamam para saber se permissões adicionais são necessárias. A seção Permissões da Referência SDK do Java 2 dos Recursos descreve quais APIs necessitam de qual permissão.
Os provedores de aplicativos podem considerar que as permissões são concedidas aos aplicativos no critério padrão anteriormente mencionado. Os aplicativos que acessam recursos não cobertos pela política padrão do WebSphere são necessários para conceder as permissões de segurança do Java 2 ao aplicativo.
Enquanto é possível conceder as permissões adicionais do aplicativo em um dos outros arquivos de política dinâmica do WebSphere ou em um dos arquivos de política estática java.policy mais tradicionais, o arquivo was.policy, que está incorporado no arquivo EAR garante que permissões adicionais tenham escopo definido no aplicativo exato que os exige. Estender a permissão além do código do aplicativo que a requer pode permitir que código que normalmente não tem permissão acesse recursos específicos.
Se um componente do aplicativo estiver sendo desenvolvido, como uma biblioteca que pode realmente ser incluída em mais de um arquivo .ear, então o desenvolvedor de bibliotecas precisará documentar as permissões necessárias do Java 2 que são exigidas pelo assembler de aplicativos. Não há nenhum arquivo was.policy para componentes do tipo biblioteca. O desenvolvedor deve comunicar as permissões requeridas por meio da documentação da API (Application Programming Interface) ou de alguma outra documentação externa.
Se a permissão for utilizada somente internamente pela biblioteca de componentes e o aplicativo não tiver acesso concedido a recursos protegidos pela permissão, pode ser necessário marcar o código como privilegiado. Consulte o tópico AccessControlException para obter detalhes adicionais. No entanto, inserir de forma imprópria uma chamada doPrivileged pode abrir brechas na segurança. Entenda a implicação da chamada doPrivileged para fazer um julgamento correto.
A seção sobre Arquivos de Política Dinâmica em Arquivos de Política de Segurança Java 2 descreve como as permissões nos arquivos was.policy são concedidas no tempo de execução.
O desenvolvimento de um aplicativo para uso com a segurança do Java 2 pode ser uma nova qualificação e impor um reconhecimento de segurança de desenvolvedores de aplicativos não necessário anteriormente. A descrição do modelo de segurança do Java 2 e as implicações no desenvolvimento do aplicativo estão além do escopo desta seção. A URL a seguir pode ajudá-lo a iniciar: http://java.sun.com/j2se/1.5.0/docs/guide/security/index.html.
Auxílios de Depuração
O arquivo SYSOUT do WebSphere Application Server e a propriedade com.ibm.websphere.java2secman.norethrow são os dois auxílios principais para depuração.Arquivos de Rastreio ou Log do Sistema do WebSphere
A exceção AccessControl registrada no registro do sistema ou nos arquivos de rastreio contém a violação de permissão que causa a exceção, a pilha de chamada de exceção e as permissões concedidas a cada quadro temporário. Essas informações geralmente são suficientes para determinar a permissão que está faltando e o código que requer a permissão.A Propriedade com.ibm.websphere.java2secman.norethrow
Quando a segurança do Java 2 estiver ativada no WebSphere Application Server, o componente do gerenciador de segurança criará uma exceção java.security.AccessControl quando ocorrer uma violação de permissão. Esta exceção, se não tratada, geralmente causa uma falha de tempo de execução. Esta exceção também é registrada no arquivo SYSOUT.Entretanto, quando a propriedade com.ibm.websphere.java2secman.norethrow do Java virtual machine estiver definida e tiver um valor igual a true, o gerenciador de segurança não criará a exceção AccessControl. Essas informações são registradas.
Essa propriedade é direcionada a um ambiente de modo seguro ou de depuração, pois instrui o gerenciador de segurança a não criar a exceção AccessControl. A segurança do Java 2 não é impingida. Não utilize essa propriedade em um ambiente de produção em que um ambiente relaxado de segurança do Java 2 enfraquece a integridade que a segurança do Java 2 deve produzir.
Esta propriedade é valiosa em modo seguro ou ambiente de teste, onde o aplicativo pode ser completamente testado e onde os arquivos de registro ou rastreio do sistema podem ser verificados em busca de exceções AccessControl. Como essa propriedade não cria a exceção AccessControl, ela não propaga a pilha de chamada e não causa uma falha. Sem essa propriedade você precisa encontrar e corrigir exceções AccessControl uma de cada vez.
Tratando Aplicativos Cuja Segurança do Java 2 Não Está Pronta
Se a integridade ampliada do sistema que a segurança do Java 2 fornece for importante, então entre em contato com o provedor de aplicativos para obter o suporte do aplicativo da segurança do Java 2 ou pelo menos comunicar as permissões adicionais necessárias além da política padrão do WebSphere Application Server que deve ser concedida.A maneira mais fácil de lidar com tais aplicativos é desativar a segurança do Java 2 em WebSphere Application Server. O lado negativo é que essa solução será aplicada a todo o sistema e a integridade do sistema não será tão forte quanto poderia ser. A desativação da segurança do Java 2 pode não ser aceitável, dependendo das políticas de segurança da organização ou das tolerâncias a riscos.
grant codeBase "file:${application}" {
permission java.security.AllPermission;
};
O Arquivo server.policy
O arquivo server.policy está localizado no diretório app_server_root/properties/.
O arquivo server.policy está localizado no diretório profile_root/properties.
Esta política define a política para as classes do WebSphere Application Server. No momento, todos os processos do servidor da mesma instalação compartilham o mesmo arquivo server.policy. No entanto, é possível configurar esse arquivo para que cada processo do servidor possa ter um arquivo server.policy separado. Defina o arquivo de política como o valor das propriedades de sistema java.security.policy Java. Para obter detalhes sobre como definir propriedades de sistema Java, consulte a seção Definição de Processo de Gerenciar Arquivo de Servidores de Aplicativos.
O Arquivo java.policy
O arquivo representa as permissões padrão concedidas a todas as classes. A política desse arquivo se aplica a todos os processos ativados pelo Java Virtual Machine no WebSphere Application Server.
O arquivo java.policy está localizado no diretório app_server_root/java/lib/security.
O arquivo java.policy está localizado no diretório ${java.home}/lib/security/ em que ${java.home} é o caminho para o SDK (Software Development Kit) que você está utilizando.
O arquivo de políticas é utilizado em todo o sistema operacional. Não edite o arquivo java.policy.
Resolução de Problemas
- Mensagem de erro CWSCJ0314E
Sintoma:
Mensagem de erro CWSCJ0314E: A política de segurança Atual Java 2 reportou uma violação potencial de permissão de segurança Java 2. Consulte o Guia de Determinação de Problemas para obter informações adicionais.{0}Permissão\:{1}Código\:{2}{3}Rastreio de Pilha\:{4}Local do Código Base\:{5} A política de segurança do Java 2 atual relatou uma possível violação de Permissão de Segurança do Java 2. Consulte o Problem Determination Guide para obter informações adicionais. {0}Permissão\:{1}Código\:{2}{3}Rastreio da Pilha\:{4}Localização da Base do Código\:{5}
Problema:
O método checkPermission do gerenciador de segurança do Java relatou uma exceção de segurança na permissão do objeto com informações de depuração. As informações relatadas podem ser diferentes em relação à configuração do sistema. Esse relatório é ativado configurando um rastreio RAS (Reliability Availability Service Ability) no modo de depuração ou especificando uma propriedade Java.
Consulte Ativando o Rastreio para obter informações sobre como configurar o rastreio RAS no modo de depuração.
Especifique a propriedade a seguir no painel Definições da JVM no Console Administrativo: java.security.debug. Os valores válidos incluem:- accessar
- Imprime todas as informações de depuração, incluindo: permissão requerida, código, pilha e localização da base do código.
- stack
- Imprime informações de depuração, incluindo: permissão requerida, código e pilha.
- failure
- Imprime informações de depuração, incluindo: permissão requerida e código.
Resposta recomendada:
A exceção relatada pode ser crítica para o sistema seguro. Ative o rastreio de segurança para determinar o código em potencial que pode ter violado o critério de segurança. Depois que o código de violação for determinado, verifique se a operação tentada é permitida com relação à segurança do Java 2, examinando todos os arquivos de política de segurança e o código do aplicativo do Java 2 aplicáveis.
Se o aplicativo estiver executando com Java Mail, essa mensagem poderá ser benigna. É possível atualizar o arquivo was.policy para conceder as seguintes permissões ao aplicativo:permission java.io.FilePermission "${user.home}${/}.mailcap", "read";
permission java.io.FilePermission "${user.home}${/}.mime.types", "read";
permission java.io.FilePermission "${java.home}${/}lib${/}mailcap", "read";
permission java.io.FilePermission "${java.home}${/}lib${/}mime.types", "read";- SecurityException - Acesso negado
Sintoma:
Se a segurança Java estiver ativada e não forem concedidas permissões para leitura do arquivo jaxm.properties, quando uma instância SOAPFactory for criada por meio de uma chamada para javax.xml.soap.SOAPFactory.newInstance(), ou uma instância MessageFactory for criada por meio de uma chamada para MessageFactory.newInstance(), uma exceção SecurityException ocorrerá e a seguinte exceção será gravada no log do sistema:Permissão: /opt/IBM/WebSphere/AppServer/java/jre/lib/jaxm.properties : access denied (java.io.FilePermission /opt/IBM/WebSphere/AppServer/java/jre/lib/jaxm.properties read) Código: com.ibm.ws.wsfvt.test.binding.addr1.binder.AddressBinder in {file:/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/installedApps/ ahp6405Node01Cell/DataBinding.ear/address1.war/WEB-INF/lib /addressbinder1.jar} Rastreio de Pilha: java.security.AccessControlException: acesso negado (java.io.FilePermission /opt/IBM/WebSphere/AppServer/java/jre/lib/jaxm.properties read) .
Problema:
A política de segurança Java 2 reporta uma violação potencial de permissão de segurança Java 2.
Resposta Recomendada:
O SOAPFactory ignora a exceção e continua com os próximos meios de determinar qual implementação carregar. Portanto, é possível ignorar a entrada de log dessa exceção de segurança.
Como este produto utiliza o SOAPFactory para suporte de outras tecnologias de serviços da Web, como WS-Addressing (WS-A), WS-Atomic Transaction (WS-AT) e WS-Notification, é possível ignorar essa SecurityException em qualquer aplicativo de serviços da Web onde a segurança Java está ativada.
Mensagens
Mensagem: CWSCJ0313E: Os sinalizadores da mensagem de depuração do gerenciador de segurança Java 2 são inicializados\: TrDebug: {0}, Acesso: {1}, Pilha: {2}, Falha: {3}
Problema: Configurados os valores dos sinalizadores da mensagem de depuração válida para o gerenciador de segurança.
Mensagem: CWSCJ0307E: Uma exceção inesperada é capturada ao tentar determinar o local de base do código. Exceção: {0}
Problema: Uma exceção inesperada é capturada quando o local de base do código é determinado.