Capítulo 6: Conceitos Básicos de Análise de Malware6.1 Introdução
Há muitas maneiras de estudar o comportamento de um programa. Com a análise estática, estudamos um programa sem realmente executá-lo. Ferramentas do comércio são disassemblers, descompiladores, analisadores de código fonte, e até mesmo serviços básicos, tais como cordas e grep . Análise estática tem a vantagem de que pode revelar como um programa se comportaria em condições incomuns, porque podemos analisar partes de um programa que normalmente não executam. Na vida real, a análise estática dá uma imagem aproximada melhor das hipóteses. É impossível prever totalmente o comportamento de todos, mas o menor programas. Vamos ilustrar a análise estática com um exemplo da vida real no final do capítulo.
Com a análise dinâmica, estudamos um programa que é executado. Aqui, ferramentas do comércio são depuradores, traçadores chamada de função, emuladores máquina, analisadores lógicos, e sniffers de rede. A vantagem da análise dinâmica é que ela pode ser rápida e precisa. No entanto, a análise dinâmica tem a desvantagem de que "o que você vê é tudo que você começa". Pela mesma razão que não é possível prever o comportamento de um programa não-trivial, também não é possível fazer um programa não-trivial percorrer todos os caminhos através de seu código. Vamos aprofundar a análise dinâmica no início deste capítulo.
Um caso especial é a "caixa preta" análise dinâmica, onde um sistema é estudado sem o conhecimento sobre suas estruturas internas. Os observáveis são apenas as entradas externas, saídas e as suas relações de timing. Em alguns casos, as entradas e saídas incluem o consumo de energia e radiação eletromagnética também. Como vamos mostrar em um exemplo, software de análise de caixa-preta pode produzir resultados extremamente úteis apesar de suas limitações aparentes.
Finalmente, há a análise post-mortem, o estudo do comportamento do programa, olhando para os efeitos depois da execução. Exemplos incluem o registro local ou remoto, as alterações ao ficheiro de conteúdo ou arquivo de padrões de tempo de acesso, informações de arquivos excluídos, dados que foi escrito para swap, dados que ainda perdura na memória, e as informações que foi gravado fora da máquina. Post-mortem análise é muitas vezes a única ferramenta disponível depois de um incidente. Sua desvantagem é que a informação desaparece ao longo do tempo como um comportamento normal do sistema corrói a distância da prova. No entanto, baseado em memória pós-efeitos podem persistir por horas ou dias, e baseado em disco pós-efeitos podem persistir por dias ou semanas, como discutido nos capítulos 7 e 8. Não iremos cobrir post-mortem de análise neste capítulo, uma vez que aparece em tantos outros lugares neste livro, e mencioná-lo aqui apenas para ser completo.
Após uma introdução das medidas de segurança importantes, vamos olhar para várias técnicas para executar um programa desconhecido em um ambiente controlado. Usando exemplos de invasões reais que mostram que técnicas simples muitas vezes pode ser suficiente para determinar a finalidade de código malicioso. Programa de desmontagem e descompilação são apenas para os dedicados, como mostramos no final do capítulo.
6,2 Perigos do programa de análise dinâmica
Uma maneira de descobrir o propósito de um programa desconhecido é simplesmente executá-lo e ver o que acontece. Há lotes de potenciais problemas com esta abordagem. O programa poderia funcionar amuck e destruir todas as informações sobre a máquina. Ou o programa pode enviar e-mail ameaçando outras pessoas que você não quer perturbar. Tudo isto não faria uma boa impressão.
Ao invés de executar um programa desconhecido em um ambiente onde possa causar danos, é mais seguro para executar o programa em um sandbox. O termo "sandbox" é roubado de balística, onde as pessoas armas teste por balas tiro dentro de uma caixa cheia de areia, de modo que as balas não pode fazer mal. Uma caixa de areia software é um ambiente controlado para a execução de software.
Caixas de areia para o software pode ser implementado de várias maneiras. A abordagem mais simples é o cordeiro sacrificial: a real, mas a máquina, descartáveis, com acesso limitado à rede ou sem acesso à rede em tudo. Esta é a abordagem mais realista, mas pode ser inconveniente se você quiser fazer medições reproduzíveis.
Em vez de dar o programa desconhecido uma máquina inteira de sacrifícios, você pode usar técnicas mais sutis. Estes vão desde passivamente acompanhamento de um programa como ele executa a fazer o programa funcionar como uma marionete, pendurado fios que são inteiramente sob controle pelo investigador.
Nas seções seguintes, vamos rever as técnicas para implementar um ambiente controlado para execução de software não confiável, bem como técnicas para monitorar ou manipular software enquanto ele executa.
Programa com 6,3 confinamento rígido máquinas virtuais
Muitas técnicas existem para dividir um sistema de computador em múltiplos compartimentos mais ou menos independentes. Eles variam de técnicas que são implementados inteiramente em hardware, a técnicas de compartilhamento de recursos que implementam inteiramente em software. Como veremos que eles não diferem apenas em termos de funcionalidade e desempenho, mas também no grau de separação entre os compartimentos.
Mais sofisticados sistemas multi-processador tem o suporte de hardware para dividir uma máquina em um pequeno número de hardware em nível de partições, como mostrado na figura 6.1. Quando cada partição executa seu próprio sistema operacional e seus próprios processos em cima de sua própria CPU (s) e disco (s), nível de hardware partições são equivalentes a ter múltiplos sistemas de computadores independentes no mesmo recinto físico.
Por causa do hardware especializado envolvidos, os sistemas com hardware de nível de apoio partição estão atualmente fora do orçamento do analista de malwares típico. Podemos citar as máquinas rígido virtual para a completude, para que possamos evitar a confusão com as técnicas baseadas em software que discutimos nas próximas seções.
Host 1 programa
Host 1 biblioteca
Host 1 do kernel
Host 2 programa
Host 2 biblioteca
Host 2 do kernel
Interface de hardware
Host 1 hardware
Host 2 hardware
Figura 6.1: arquitetura da máquina tíNão poste palavrões rígido virtual.
6,4 Programa de confinamento com suaves máquinas virtuais
Máquinas virtuais implementadas em software fornecem uma maneira flexível para compartilhar hardware entre vários sistemas operacionais simultaneamente em execução. Como ilustrado na figura 6.2, um ou mais sistemas operacionais convidados correr em cima de uma interface de hardware virtual, enquanto um programa monitor de máquina virtual (às vezes chamado de hypervisor) media o acesso ao hardware real. Cada convidado executa na velocidade normal, exceto quando se tenta acessar hardware, ou quando se tenta executar instruções da CPU certos. Estas operações são tratadas pelo monitor de máquina virtual, de uma forma que é feito para ser invisível para o hóspede.
Programa um convidado
Biblioteca 1 visitante
Kernel de convidado um
Programa de hóspedes de 2
Convidado biblioteca 2
Kernel de convidado 2
Interface de hardware virtual
Monitor de máquina virtual
Kernel host
Equipamento
Figura 6.2: arquitetura da máquina tíNão poste palavrões macio virtual. Algumas implementações monitor de máquina virtual rodar em hardware nua [Karger, 1991], algumas implementações executado como um aplicativo no topo de um sistema operacional hospedeiro implementações [VMware], e muitos usam um protocolo entre os convidados ea máquina virtual monitor [Dunlap, 2002] para mediar o acesso ao hardware subjacente e / ou para melhorar o desempenho.
A flexibilidade de soft máquinas virtuais vem ao custo de alguma sobrecarga de software no monitor de máquina virtual. Em troca, eles podem oferecer recursos que não estão disponíveis em hardware real ou em sistemas operacionais convidados. Por exemplo, monitores de máquinas virtuais pode implementar o suporte para mudanças no sistema de arquivos que podem ser desfeitas, redirecionando as operações de gravação de disco para um arquivo de log fora da máquina virtual. Esta característica torna mais fácil repetir um experimento várias vezes com a mesma condições iniciais. Contamos com isso por alguns experimentos que são descritos em outra parte deste livro quando foi utilizado o sistema VMware para a família de processadores i386 [VMware].
Como outro exemplo de uma funcionalidade melhorada, o sistema Revirt [Dunlap, 2002] permite que um investigador para reproduzir um "incidente", e para voltar, pausar ou fast-forward a máquina virtual em qualquer ponto do tempo. Isto é possível porque o Revirt virtuais monitorar registros de todas as interrupções e insumos externos, incluindo as teclas digitadas e conteúdo pacote de rede. Esta informação, combinada com um registro completo do estado inicial do sistema de arquivos, permite que um investigador para reproduzir cada instrução de máquina e ver dados antes, durante e após ela é modificada. É possível até mesmo entrar em uma máquina virtual enquanto ela estiver repetindo um "incidente", embora a partir desse ponto a reconstrução é, naturalmente, já não precisa. Revirt é baseado em modo de usuário Linux e, portanto, específicos para aplicações Linux. Embora possa reconstruir a cada ciclo de CPU da execução do programa passado, a quantidade de armazenamento necessário é limitada porque Revirt armazena somente as interrupções e as entradas externas.
6,5 Perigos de confinamento com suaves máquinas virtuais
Quando uma máquina virtual é usado para análise de código hostil, não deve permitir que o software não confiável para escapar. Manter o malware confinado com uma máquina virtual requer moles não só a aplicação correta dos recursos de proteção do hardware do processador, mas também exige a implementação correta do monitor de máquina virtual, o software que medeia todas as solicitações de acesso a hardware real a partir de software rodando em uma máquina virtual . Se o software hostil pode reconhecer seu ambiente virtual, então ele pode ser capaz de explorar bugs monitor virtual implementação e confinamento escape.
Em alguns casos, detalhes sutis podem dar que o software é executado em uma máquina virtual. Por exemplo, um convidado com acesso a hora exata pode notar que algumas instruções de máquina são comparativamente lento. E quando um disco virtual se estende faixa em várias faixas do disco físico, blocos de disco que são adjacentes na mídia virtual pode ser não-adjacentes no meio físico, resultando em propriedades incomuns tempo de acesso.
Por outro lado, a VMware ambiente de hardware virtual é realmente fácil de reconhecer; listagem 6.1 mostra um exemplo. Alguns detalhes, como seqüências de identificação do dispositivo pode ser reconhecido por qualquer processo que corre na máquina virtual, enquanto outros detalhes podem até ser reconhecido à distância. Em particular, o endereço de hardware ethernet 00:50:56 prefixo, que é reservado para VMware, pode ser reconhecido remotamente em IP versão 6 endereços de rede [RFC 2373].
$ dmesg
. . . lnc0: PCnet-PCI endereço II 00:50:56:10: bd: 03 ad0: 1999MB <VMware Virtual rígidos IDE Drive> [4334/15/63] em ata0-master UDMA33 acd0: CDROM <VMware Virtual IDE CDROM Drive> em ata1-master PIO4. . . $ ifconfig lnc0
lnc0: flags = 8843 mtu 1500 <UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> endereço: 00:50:56:10: bd: 03. . . inet6 fe80:: 250 : 56 ff: fe 10: bd03 % le0 prefixlen 64 ScopeId 0x1 inet6 2001:240:587:0: 250 : 56 ff: fe 10 : bd03 prefixlen 64
Listagem 6.1: Sinais de um ambiente VMware em mensagens de inicialização do sistema e em endereços de rede IPv6. A informação do endereço ethernet nos endereços IPv6 é indicado em negrito. O octeto primeiro endereço ethernet é transformado conforme RFC 2373.
No caso do VMware, você também tem que estar ciente da existência de um canal de indocumentados que permite ao sistema operacional convidado para enviar pedidos para o monitor de máquina virtual. Estes incluem os pedidos para obter a versão do monitor de máquina virtual, para conectar ou desconectar os dispositivos virtuais, e para obter ou definir as preferências do usuário [Kato, 2004].
Implementação de um programa de monitoramento virtual seguro da máquina é um exercício não-trivial, mas é possível combinar um alto nível de segurança com bom desempenho [Karger, 1991]. Surgem complicações adicionais no caso da família de processadores i386, onde algumas instruções CPU falta de apoio da máquina virtual. É o trabalho do monitor de máquina virtual para identificar corretamente, interceptar e emular todas as instruções em software [Robin, 2000], para que o software dentro da máquina virtual vê o resultado correto.
Devido a sua flexibilidade estendida e complexidade, macio máquinas virtuais não oferecem mais do que difícil separação máquinas virtuais, e muito menos máquinas fisicamente separadas. Aconselhamos o leitor a exercer cautela, e para conduzir experimentos máquina virtual em uma máquina servidor dedicado que não contém informações confidenciais.
6,6 confinamento Programa com prisões, e chroot
Enquanto as máquinas virtuais instâncias separadas de todo o sistema operacional, há também uma série de soluções que proporcionam a separação no nível de processo só. Sob o capô é apenas uma instância do kernel. As abordagens diferem na adequação para confinamento malware.
Um recurso de segurança tradicionais do UNIX é o chroot () chamada de sistema. Esta característica restringe o acesso ao sistema de arquivos, mudando o diretório raiz de um processo. Que limita a exposição de um sistema e é frequentemente utilizado para endurecer FTP e servidores WWW contra compromisso.
Uma limitação óbvia de chroot () é que limita o acesso ao sistema de arquivos somente. Em particular, não fornece o isolamento de processos ou de outras organizações não-file objetos que existem no mesmo sistema. Devido a essas limitações, um intruso privilegiada pode escapar com relativa facilidade através de qualquer número de chamadas do sistema. Nós definitivamente não recomendo chroot () para o confinamento de processos não confiáveis que devem ser executados em um ambiente completo sistema UNIX.
Ao longo do tempo, as pessoas têm expandido as idéias de chroot () a abranger também o âmbito das chamadas do sistema. Conhecido como prisões em FreeBSD versão 4, zonas ou recipientes do Solaris 10 [SUN, 2004], eo patch VServer para Linux [VServer, 2004], estas características mudar não só a idéia de um processo de seu diretório raiz do sistema de arquivos, mas também o que processos de seu vizinho são, qual o endereço IP do sistema é, e assim por diante. Com essa arquitetura, mostrado na figura 6.4, um processo que é executado dentro de uma prisão de software não tem acesso a processos, arquivos, etc, fora de sua prisão. A fim de manter essa separação, um processo de super-usuário dentro de uma jaula não é permitido executar operações que poderiam interferir com o funcionamento de outros presídios ou com o ambiente de prisão não. Por exemplo, o ambiente de prisão não tem / dev / mem ou / dev / kmem dispositivos de memória, e um processo preso não tem permissão para atualizar os parâmetros de configuração do kernel ou de manipular os módulos do kernel.
Não-prisão do programa
Não-prisão biblioteca
Programa de uma prisão
Biblioteca de uma prisão
Interface de chamada de sistema
Núcleo
Equipamento
Figura 6.3: arquitetura tíNão poste palavrões prisão software.
Estas propriedades fazem prisões adequadas para receber ambientes de sistema completo com seus próprios usuários, processos e arquivos. Eles contêm tudo, exceto o kernel do sistema operacional, que é compartilhado entre prisões e no ambiente de prisão não. A vantagem de prisões mais máquinas virtuais é o custo: elas sofrem nem sobrecarga do software de um monitor de máquina virtual, nem sofrer as custas de hardware especializado. O inconveniente das prisões é que tudo é executado no mesmo kernel, e que este kernel deve sempre impor a separação através de uma cadeia muito complexa interface do kernel processo. Por esta razão, as prisões não são mais seguras do que macia máquinas virtuais.
6,7 A análise dinâmica com monitores chamada de sistema
Tendo introduzido máquina virtual e técnicas de prisão que nos permitem encapsular um ambiente de sistema completo para análise de código hostil, agora nos voltamos para as técnicas que os processos alvo individual. Vamos proceder a partir de técnicas de observação passiva para técnicas mais poderosas para a manipulação ativa.
Com as chamadas de sistema olharmos para a informação que atravessa o processo de limite de kernel: nomes de chamada de função, argumentos e valores de resultado. Entre chamadas de sistema que ignoram completamente o que acontece dentro de um processo. Efetivamente, todo o processo é tratado como uma caixa preta. Essa abordagem faz sentido em ambientes operacionais onde cada acesso ao arquivo, cada acesso à rede, e até mesmo algo tão simples como a obtenção da hora do dia requer uma chamada de sistema de assistência pelo kernel do sistema operacional.
Em muitos programas, sistema de chamadas acontecem com uma freqüência relativamente baixa, e observá-los produz informações mais úteis do que assistir instruções de máquina individual. Informações chamada de sistema é particularmente adequado para a filtragem no nome chamada de função, os valores dos argumentos ou valores resultado. Isso pode ajudar a diminuir a busca antes de descer para o nível de instrução de máquina para maiores detalhes.
Modernos sistemas UNIX fornecem ferramentas para chamadas de sistema de monitoramento em tempo real. Os comandos são chamados strace (Linux, FreeBSD, Solaris e outros) ou truss (Solaris). Como mostrado na figura 6.4, essas ferramentas são executadas como um processo de monitoramento que controla ativamente de um processo monitorado. O mecanismo subjacente é baseado no / proc sistema de arquivos ou o ptrace () chamada de sistema. O 4.4BSD ktrace comando é um pouco diferente. Em vez de ativamente controlar um processo monitorado, ele usa o ktrace () chamada de sistema que o sistema acrescenta informações ligue para um arquivo regular. Uma vez que o mecanismo por trás ktrace está limitada a vigilância passiva, não será discutida neste capítulo.
Figura 6.4: Fluxo de controle com um típico aplicativo de monitoramento de sistema de chamada.
O quadro abaixo resume como o sistema típico de trabalho chamada aplicações de monitoramento.
O processo monitorado invoca uma chamada de sistema.
O kernel do sistema operacional dá o controle ao processo de acompanhamento para que ele possa inspecionar o processo monitorado. Isto inclui a memória do processo, registradores do processador, o número de chamada do sistema que identifica a operação solicitada, e os argumentos de chamada do sistema.
O kernel do sistema operacional executa a chamada de sistema.
Após a conclusão da chamada de sistema, o processo de monitoramento pode inspecionar o processo monitorado novamente, incluindo a memória, registradores do processador, e os resultados das chamadas de sistema.
O kernel passa o controle de volta para o processo monitorado.
Tipicamente, sistema de chamada de programas de rastreamento produzir uma linha de saída por chamada, com o nome de chamada do sistema, os seus argumentos, e seu valor de resultado. Por exemplo, aqui estão todos os I / O chamadas de sistema relacionado que são feitas pelo Solaris data de comando, após a inicialização do processo é concluído:
$ truss-t abrir, ler, escrever, perto data> / dev / null
. . . Sistema de inicialização do processo chama ignorado ... open ("/ usr / share / lib / zoneinfo / US / Eastern", O_RDONLY) = 3 leitura (3, "\ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 ".., 8192) = fechar 1250 (3) = 0 write (1," M em A pr 2 4 1 ".., 29) = 29
No exemplo que pular o processo de chamadas de inicialização do sistema que se ligam várias bibliotecas do sistema no espaço de endereço do processo. Uma vez que a inicialização processo estiver concluído, o processo abre, lê e fecha o arquivo que descreve as regras de tempo de conversão para o fuso horário US / Eastern, que corresponde à localização do sistema. O programa usa as informações de fuso horário para converter a hora do sistema (sistemas UNIX manter o tempo em Coordenadas Tempo Universal, ou UTC) para a representação local, tendo em conta de luz etc economia de tempo e, finalmente, escreve o resultado. No exemplo, a saída do data comando em si foi descartada para evitar interferência com a saída de rastreamento de chamada do sistema.
Além de iniciar um processo sob controle de um rastreador de chamadas de sistema, como mostrado acima, também é possível anexar um rastreador de chamadas de sistema a um processo já em execução. Como ilustração do poder do sistema de rastreamento de chamadas, o comando a seguir coloca grampos crocodilo software em um ssh processo do servidor com o ID 3733 e revela o conteúdo em texto puro de sessões de login; figura 6.5 mostra os fluxos de informação com mais detalhes.
# strace-f-p 3733-e trace = ler, escrever e-write = 3-e ler = 5
O strace comando atribui ao processo com o id 3733, e para qualquer processo filho que nasce após o strace comando é iniciado. O comando exibe todos os dados que são gravados em arquivo descritor de 3 e que é lido para arquivo descritor de 5. Estes descritores de arquivos estão ligados aos processos que são executados em nome do usuário remoto. Os números dos descritores do arquivo real são específicos do sistema e versão, e é provável que diferem para o seu ambiente.
Assim, o strace comando exibe o texto puro de tudo o que um usuário remoto digita no teclado, incluindo senhas que são usadas para entrar em outros sistemas, incluindo tudo o que é enviada de volta para o usuário remoto. No entanto, strace é incapaz de mostrar a informação que é enviada quando um usuário se autentica para o ssh próprio servidor, porque essa informação nunca é enviado através dos descritores de arquivos monitorados.
Figura 6.5: escutas telefónicas num processo servidor ssh.
O strace comando é um rastreador de chamadas de sistema genérico. Quando ele é usado para escutas telefônicas ler e escrever sistema chama o produto ainda contém uma grande quantidade de ruído que precisa ser filtrada. Se você pretende adotar essa abordagem que vale a pena para preparar uma versão modificada strace comando que produz menos ruído. Se você não tem tempo para planejar, então você simplesmente tomar qualquer ferramenta está disponível.
Claro, sessões de login pode ser grampeado de forma mais conveniente com utilitários que se ligam diretamente à porta de um usuário de terminal como o ttywatch (Linux), assistir (4.4BSD), ttywatcher (Solaris) [Neuman, 2000], Sebek (Linux, OpenBSD, Solaris , Win32) [Balas, 2004] e, por último mas não menos importante, sessões de login pode ser grampeado fazendo pequenas alterações para o ssh código do servidor em si.
Há um lado importante até chamada de sistema de rastreamento - só pode haver um processo de rastreamento por processo rastreado. Portanto, é possível para um atacante determinado a fazer um processo untraceable, anexando ao processo antes que alguém tem a chance de fazê-lo. A mera existência de um processo tão untraceable pode, é claro, levantar a suspeita extrema.
6,8 Programa de confinamento com os censores chamada de sistema
Além de monitorar passiva, ganchos sistema de monitoramento de chamadas pode ser usado para restringir as ações por um processo monitorado. Ferramentas de sistema censura chamada pode ser útil para executar software desconhecido através dos seus ritmos, sem permitir que ele para infligir danos a seu meio ambiente. As restrições são impostas, quer por um processo de nível de usuário que os censores chamadas de sistema não desejadas, ou pelo nível de kernel de código que faz o mesmo. Vamos apresentar um exemplo de cada abordagem.
O sistema Janus [Goldberg, 1996] é um exemplo de nível de usuário chamada de sistema censor. Figura 6.6 mostra a arquitetura geral. O propósito de Janus é limitar os danos que as aplicações de buggy pode fazer quando executado por usuários normais. Janus sistema intercepta chamadas por um processo monitorado e examina seus valores de argumento. Chamadas de sistema aceitável são autorizados a prosseguir sem interferência, e chama inaceitáveis são abortadas para que o processo monitorado recebe um resultado de erro. Uma alternativa para abortar uma chamada é simplesmente encerrar um processo monitorado, mas esta é reservada para os casos problemáticos, os usuários se oporia a gatilho software de segurança. Janus utiliza políticas estáticos que devem ser definidos com antecedência. Os seguintes são exemplos de entradas em um arquivo de política de Janus:
# O starting_dir diretório inicial / algum / lugar # Permitir arquivo de senhas de caminho de acesso de leitura permitem ler / etc / passwd # Permitir conexões para hospedar 128.36.31.50 porta 80 net permitem conectar tcp 128.36.31.50 80
O original Janus sandbox foi implementado com um processo de censura a nível de usuário. Devido a esta arquitetura Janus estava sujeito a condições de corrida e poderia deixar de acompanhar o estado do processo monitorado [Garfinkel, 2003]. O sistema Janus atual usa uma arquitetura diferente: ele é implementado como um módulo do kernel Linux que fala a um processo de monitor de nível de usuário, bem como systrace que será descrito a seguir.
Figura 6.6: Initial sistema Janus implementação sandbox chamada com um processo de monitoramento de nível de usuário.
Como um exemplo de um kernel baseado em chamada de sistema censor, intercepta as chamadas de sistema systrace feita por um processo monitorado, e se comunica com um processo no nível do usuário que faz com que as decisões de política [Provos, 2003]. Figura 6.7 mostra a arquitetura geral. Systrace atualmente roda em vários sabores de BSD, em Linux, e de Políticas Mac OS X. são expressas como regras, com o nome de chamada do sistema (por exemplo, linux-connect para o modo de emulação Linux do connect () chamada de sistema), o argumentos (por exemplo, o endereço remoto IP e porta de rede), ea ação ( permitir , negar ou perguntar ). Estas regras são mantidas em arquivos de política que são nomeados após o arquivo de programa executável. Por padrão, systrace procura por arquivos política sob o diretório home do usuário e um diretório de sistema compartilhado. Os seguintes são exemplos de regras de política systrace:
# Permitir stat (), lstat (), readlink (), acesso (), open () para a leitura. nativo fsread: filename eq "$ HOME", então permitam-natal fsread: match filename "$ HOME / *", então permitam # Permitir conexões para qualquer servidor WWW. nativo-connect: match sockaddr "inet *: 80", em seguida, permitir
Systrace pode ser executado em três modos principais: o modo gerador de políticas, de modo a política de execução, e modo interativo.
Política de geração de modo ", systrace-A de comando ", executa o comando especificado, examina o sistema de chamadas que o programa é executado durante esse executar particular, e gera um arquivo de política com regras que permite apenas às chamadas do sistema específico. Este modo é usado para gerar uma base de arquivo de política de linha com o comportamento do programa permitido.
Política de modo imposição, " systrace-a de comando ", executa o comando especificado, aplica as regras no arquivo de diretiva para o comando, e nega e registra cada chamada do sistema que não é acompanhada por uma regra existente. Este modo é utilizado para o confinamento de rotina de software não confiável ou usuários.
Modo interativo, " systrace comando ", executa o comando especificado, aplica as regras no arquivo de diretiva para o comando se o arquivo existe, e pede permissão para executar cada chamada do sistema que não é acompanhada por uma regra existente. Interação com o usuário pode usar uma janela pop-up gráfico ou modo texto puro. O usuário pode então decidir permitir ou não a chamada, para encerrar o processo, ou para introduzir uma regra systrace permanente que trata automaticamente as ocorrências futuras dessa chamada de sistema. Modo interativo dá o máximo controle para o usuário, e pode ser usado para executar softwares conhecidos e desconhecidos, com extremo preconceito.
Como um exemplo de implantação em larga escala, OpenBSD adotou systrace aplicação de políticas para a construção de software de origem externa (em que é chamado de "portas" de recolha). Isso aconteceu após um incidente em que um procedimento ligado subvertida construir um processo shell local para um invasor remoto [Bugtraq, 2002]. Quando o procedimento de construir mesmo executa sob o controle do systrace, a tentativa de conectar-se o intruso é negado e um registro é registrada no mensagens de arquivo:
04 de setembro 18:50:58 openbsd34 systrace: deny usuário: Wietse, [...] syscall: nativo de conexão (98), sockaddr: inet [204.120.36.206]: 6667
Censores sistema de chamada que são executados dentro do kernel têm a vantagem de acesso ao estado completo do processo monitorado. Isso significa que eles podem ser mais precisos do que a nível de usuário implementações. No entanto, mesmo baseado em kernel censores chamada de sistema pode ter limitações como discutiremos na seção 6.10, "Perigos do confinamento com as chamadas de sistema".
Figura 6.7: systrace sandbox chamada de sistema implementado com um módulo de kernel política.
EM BREVE MAIS INFORMACOES
