Segurança em Java sandbox modelo

Desde sua introdução, a tecnologia Java tem dado um importante papel em questões de segurança. Embora com resultados mistos, os designers têm tentado fornecer uma plataforma de sistemas de segurança implementados diretamente em termos de linguagem, disponível para os desenvolvedores.

Em um processo contínuo de evolução e refinamento da JVM tornou-se uma das infra-estruturas mais importantes para aplicações stand-alone, web, celulares e muito mais, neste artigo vamos concentrar-nos sobre a evolução do modelo de segurança, comumente chamado de sandbox, comentando sobre o erros de projeto e da situação atual.

Pré-requisitos

Este artigo é destinado a todos, sejam eles experientes programadores Java que totalmente em jejum leitores do tópico. Algumas considerações podem ser mais compreensível para aqueles que já possuem alguma experiência com essa linguagem, mas a leitura deste trabalho é adequado para qualquer leitor.

O sandbox

O modelo original

O modelo original, conhecido como uma caixa de areia, foi projetada para confinar códigos potencialmente maliciosos em um ambiente isolado e altamente restritiva. Java desde a sua criação, foi fortemente orientado para a rede e esta consideração levou a conceber um modelo de execução em que o código foi baixado diretamente do controle remoto, expondo o cliente a questões de segurança significativas.

Na sua primeira implementação, mostrado esquematicamente na figura, o sandbox apenas cerca de distinguir entre o código de código local e remota: a primeira foi a desfrutar o pleno acesso a todos os recursos do sistema "crítico", como, por exemplo, sistemas de arquivos e vários dispositivos, a remota de código pelo contrário, tinha limitado acesso aos recursos é mediada pela mesma caixa de proteção: applets, agora praticamente desapareceu a partir da web, eu tenho sido o exemplo mais conhecido.

Este modelo inclui uma série de mecanismos de segurança em diferentes níveis. Primeiro de tudo, Java é type-safe, ou seja, há uma relação explícita entre uma variável e controlado e seu tipo (inteiro, ponto flutuante, string, etc ..).
Aqueles que têm programados em linguagens com nível baixo / médio, tais como C e C + + sabe quantos problemas pode evitar esta verificação: esse conjunto de conversões implícitas entre tipos, como números inteiros ou ponteiros booleans vazio para outros ponteiros, que são características de dessas línguas, ao mesmo tempo tornar-se a principal fonte de erros de programação, igualmente comprometidos com novatos e especialistas. Para minimizar a possibilidade de que a evolução fez asneiras, os projetistas da Sun introduziu alguns aspectos até então encontrado apenas em nichos ou línguas nível universitário, como, por exemplo, o gerenciamento automático de memória (coleta de lixo) e controles em tempo de execução memória de acesso (ponteiros, elementos da matriz, etc ...).

O segundo nível de proteção é garantida pelo compilador e tempo de execução, pela máquina virtual. Isso garante que o código de bytes, o montador da VM Java é executado com as permissões de execução apropriadas. Em particular, dois componentes-chave, o SecurityManager e ClassLoader, definir um espaço de nome local para evitar a interferência entre diferentes instâncias da VM e gerenciar os controles de acesso a recursos críticos.

JDK 1.1 - código assinado

O modelo apresentado é muito flexível na primeira atualização do JDK (versão 1.1) foi introduzido o conceito de código confiável para permitir que aplicações remotas, se acompanhadas de uma assinatura eletrônica reconhecida pelo cliente, o acesso aos recursos do sistema. A solução descrita na figura a seguir, é pouco mais do que um hack da arquitetura anterior e, portanto, exigem uma reescrita completa em próximos lançamentos.

• <<
• 1
• 2
• 3
• >>