Java Security

1. Java Security Fernando Leal Brayner Marcellus de Castro Tavares

2. Roteiro • Introdução • Java Security • High-Level • Low-Level • API • Falhas de Segurança • Guidelines para desenvolvedores

3. Introdução

4. A Linguagem Java • Desenvolvida pela Sun Microsystems • Primeiro release público na década de 90 • Independente de plataforma • Interpretada • Type-safe • Garbage Collection

5. Níveis de Segurança • Segurança separada em dois níveis • Low-level : JVM • Gabage collection • bytecode verifier • High-level: aplicações • Sandbox • Security policies • Security APIs

6. Java Security – High-Level

7. JDK 1.0 Security Model • Modelo “sandbox”. • Código local com acesso total aos recursos do ambiente. • Applets não são confiáveis, acesso limitado. • Security manager responsável para determinar que recursos são permitidos.

8. JDK 1.0 Security Model

9. Restrições ao código não confiável • Ler/Escrever arquivos no sistema. • Deletar/Renomer arquivos. • Criar conexões • Escutar/Aceitar conexões em qualquer porta no sistema cliente. • Carregar bibliotecas.

10. JDK1.1 Security Model • Applet assinado (signed applets). • Signed applet é tratado como código local. • Unsigned applets continuam rodando no sandbox.

11. JDK 2 Security Model • Todo código, local ou não, sujeito a políticas de segurança. • Políticas definem um conjunto de permissões. • Cada permissão especifica um acesso a um recurso em particular. • Sistema organiza códigos em domínios, que agrupam conjunto de classes cujas instâncias são dadas o mesmo conjunto de permissões.

12. JDK 1.2 Security Model

13. Ferramentas relacionadas a segurança JDK • Keytool • Criação de pares de chave pública/privada. • Jarsigner • Ferramenta para assinar jars e verificar a autenticidade das assinaturas no jar assinado • PolicyTool • Ferramenta para criação e modificação de arquivos de políticas de sgurança.

14. Java Security – Low Level

15. JVM • Responsável pela “independência de plataforma” • Interpreta Java bytecodes • Bytecodes são armazenados nos arquivos .class

16. Arquitetura da JVM • Stack based machine • Instruções puxam argumentos da pilha e empurram resultados na mesma • Registradores são acessados via fuções de load/store • Pilha e registradores são preservados entre as chamadas dos métodos

17. JVM: Bytecode • JVM provê umas 200 funções, maioria delas são tipadas • Exemplo publicint add(int i, int j) { int res; res = i + j; return res; } public add(int,int):int 0: iload_1 1: iload_2 2: iadd 3: istore_3 4: iload_3 5: ireturn

18. Segurança na linguagem Java • O compilador e o sistema run-time de java implementa várias camadas de defesa contra códigos potencialmente incorretos. • O ambiente Java de execução assume que nada é confiável. • Desenhada para ter tipagem segura • Gerenciamento automático de memória • Checagem automática dos limites do array.

19. Verificação do .class • Certifica que as restrições da linguagem são cumpridas • Classes finais não podem ser estendidas • Toda classe tem uma super classe, exceto a classe Object • Assegura que o arquivo possui a estrutura adequada • Verificação do Bytecode

20. Byte Code Verifier • Bytecode verifier não faz suposições sobre a origem do código • Uma vez que a verificação é feita um número de propriedades são garantidas • Nenhum stack overflow/uderflow foi causado • Tipagem correta • Todos os registradores foram inicializados • Inicialiazação dos objetos.

21. Bytecode verification – estágio 1 • Bytes são quebrados em seqüências de instruções • Endereço de cada instrução é mantido em uma tabela

22. Bytecode verification – estágio 2 • Interpretador abstrato • Executa instruções JVM, mas opera sobre tipos • Para cada instrução i, uma regra de transação descreve a modificação da pilha e dos registradores i: (S,R) (S‘,R‘) • Verificador procede método por método

23. Verificação do Bytecode: interpretador abstrato • Exemplos • Erros são verificados pela falta de transações • Erro de tipo, stack underflow/overflow

24. Verificação do Bytecode: interpretador abstrato • Tipos primitivos (int, long, float, double) • Objetos e referências a arrays • Null: referência nula • T: registrador não inicializado

25. Bytecode verification: simple example Stack/Registers Source Bytecode ([ ], [ C, T, T ] ) (float, [ C, T, T ] ) ([ ], [ C, float, T ] ) (C, [ C, float, T ] ) ([ ], [ C, float, C ] ) fconst 1.0 fstore 1 aload 0 astore 2 float f; Object o; f = 1.0 o = this; ([ ], [ C, T, T ] ) (float, [ C, T, T ] ) ([ ], [ C, float, T ] ) (float, [ C, float, T ] ) ERROR • Bytecode correto • Introduzindo um erro Astore precisa de um objeto no topo da pilha! float f; Object o; f = 1.0; o = f; fconst 1.0 fstore 1 fload 1 astore 2

26. Arquitetura do Class Loader • Class loaders – responsáveis por importar dados binários que definem as classes e interfaces do programa em execução • Principais funcões: • Carregar classes (local,net) • Definir namespaces • Modelo criticado

27. Arquitetura do Class Loader • Primordial class loader • Parte da implementação da JVM, um por vez • Não pode ser sobrescrito • Responsável pelo bootstraping da VM • Classes não passam pelo verificador • Class loader objects • Objetos java que carregam classes de maneira customizável • Tratados como não-confiáveis por default • Extensível • Applet Class loader

28. Arquitetura do Class Loader • Origem distinta classloarder

29. Applet Class Loader

30. Carregando Classes

31. Passos do Class Loader • Determina se a classe foi previamente carregada. Se sim, retorna a mesma. • Consulta o Primordial Class Loader para tentar carregar a classe a partir do CLASSPATH. • Checa se o Class Loader tem permissão para criar a classe que está sendo carregada. • Lê o arquivo num array de bytes. • Constrói um objeto Class e seus métodos • Resolve classes imediatamente referenciadas pela classe antes de seu uso. • Checa o .class com o verificador

32. Java Security Manager • Um objeto java que mantem lista de quem pode fazer operações “perigosas” • Classes da biblioteca java consultam o security manager quando são executadas • Todo security manager estende de • java.lang.SecurityManager • Cada VM com apenas um SM instalado, não podendo haver desinstalação

33. Java Security Manager -Customizável -A SUN fornece um template que deve ser preenchido para alcançar os requisitos de segurança

34. Utilizando o Security Manager Como instalar Como utilizar

35. Default Policy File

36. Inside Security Manager • Identidade – base para decisões de segurança • Origem – De onde vem o código? • Assinatura- De quem é o código? • java.security.CodeSource • Permissão – encapsula o acesso a operações particulares • Incluem um alvo e uma ação • p = new SocketPermission(“www.poly.edu”, “connect”); • p = new FilePermission(“/tmp/file1”, “*”);

37. Inside Security Manager • Proteção de domínio – conjunto de classes cujos objetos são concedidos o mesmo conjunto de permissões com respeito a recursos • Uma política de segurança define a proteção de domínio

38. Inside Security Manager • Access Controller (java.security.AccessController) • Decide que permissões devem ser concedidas ou negadas • Obtém snapshots do contexto de chamadas, dessa forma decisões de controle de acesso podem ser tomadas • Examina todas as classes na pilha de chamadas e garante que todas elas em permissão para realizar uma operação • Cada frame da pilha pode ter tanto o método chamado quanto um rótulo(confiável/não-confiável)

39. Responsabilidades do SM na presença de Applets não-confiáveis • Previnir instalação de novos Class Loaders.(evitar spoofing) • Proteger threads e thread groups • Controlar execução de outros programas • Controlar habilidade de desligar a VM • Controlar acesso a outros processos • Controlar operações de sockets na rede • Controlar operações no sistema de arquivos

40. Java Security API - JAAS Java Authentication & Authorization Service

41. Introdução • Autenticar é determinar a identidade do usuário • Autorizar é determinar que recursos o usuário pode ter acesso • JAAS é um conjunto que APIs que permite que as aplicações Java tenham um controle autenticação e de acesso.

42. JAAS • Primeiro release público foi em maio de 2000 com o JDK 1.4 • Implementa uma versão em Java para o padrão Pluggable Authentication Module (PAM) • Funciona com várias tecnologias de autenticação

43. JAAS – Classes e Interfaces

44. JAAS - Common • Subject • Entidade que deseja se autenticar para se ter acesso a serviços ou recursos. • Principal • Identificadores associados ao Subject • Nome, CPF

45. JAAS - Authentication • Permite a independência entre as aplicações e o mecanismo de autenticação. • Novas Tecnologias de autenticação podem ser plugadadas

46. JAAS

47. JAAS - Authentication • LoginContext • Provê métodos para a autenticação do Subject. • Usa arquivos de configuração para determinar que mecanismo de autenticação (login module) será utilizado. • LoginModule • Provedores de tecnologia de autenticação implementam essa interface para prover autenticação.

48. Mecanismo de autenticação • Aplicação inicia o LoginContext • LoginContext consulta o arquivo de configuração para carregar os módulos para o mecanismo de autenticação • Aplicação invoca o método login() do LoginContext • O método login() invoca dos módulos de autenticação carregados

49. Mecanismo de autenticação • Cada módulo tenta autentica o Subject. Em caso de sucesso os módulos associam Principals ao Subject • LoginContext retorna o status da autenticação para a aplicação.

50. JAAS - Authorization • Permite definir permissões de acesso aos usuários • Mecanismo • Depois do usuário ser autenticado. A API de autorização associa o Subject com seus controles de acesso. • Quando o Subject tenta executar uma operação (ler arquivo, escrever na base de dados) Java Runtime consulta o policy file para determinar quem pode ter acesso a essas operações.