Curso MIT "Segurança de sistemas de computadores". Palestra 6: Oportunidades, Parte 2

Instituto de Tecnologia de Massachusetts. Curso de Aula nº 6.858. "Segurança de sistemas de computador". Nikolai Zeldovich, James Mickens. 2014 ano

Computer Systems Security é um curso sobre o desenvolvimento e implementação de sistemas de computador seguros. As palestras abrangem modelos de ameaças, ataques que comprometem a segurança e técnicas de segurança baseadas em trabalhos científicos recentes. Os tópicos incluem segurança do sistema operacional (SO), recursos, gerenciamento de fluxo de informações, segurança de idiomas, protocolos de rede, segurança de hardware e segurança de aplicativos da web.

Palestra 1: “Introdução: modelos de ameaças” Parte 1 / Parte 2 / Parte 3
Palestra 2: “Controle de ataques de hackers” Parte 1 / Parte 2 / Parte 3
Aula 3: “Estouros de Buffer: Explorações e Proteção” Parte 1 / Parte 2 / Parte 3
Palestra 4: “Separação de Privilégios” Parte 1 / Parte 2 / Parte 3
Palestra 5: “De onde vêm os sistemas de segurança?” Parte 1 / Parte 2
Palestra 6: “Oportunidades” Parte 1 / Parte 2 / Parte 3

Público: podemos concluir que cada oportunidade tem um processo?

Professor: Eu duvido. Você pode ter quantos processos quiser, pois uma possibilidade pode existir vários processos. Simplificando, você não precisa necessariamente de um processo separado para cada oportunidade. Porque existe um processo fort1 que pode abrir muitos arquivos e passar muitos recursos ao componente privilegiado do fort .



A razão pela qual você acha que precisa de um processo separado para cada oportunidade com a qual lidamos diz respeito a essa estranha interação entre recursos e privilégios externos.

Porque fort1 tem um privilégio externo. E o que estamos fazendo é basicamente transformar esse privilégio externo em capacidade neste forte processo. Portanto, se você tiver vários tipos diferentes de privilégios externos ou vários privilégios diferentes que deseja usar com cautela, provavelmente desejará um processo separado que tenha esse privilégio. E sempre que desejar usar um conjunto específico de privilégios, você solicitará o processo apropriado para realizar a separação e, se isso for bem-sucedido, solicitará que o processo devolva o recurso a você.

De fato, havia um design do sistema operacional completamente baseado em recursos e sem privilégios externos. E isso é legal, mas não muito prático para uso em um sistema real. Acontece que, na realidade, você não deseja privilégios externos, mas oportunidades para nomear um objeto e contar a alguém sobre esse objeto sem transferir os direitos para esse objeto sem falha.

Talvez eu não saiba quais privilégios você pode ter em relação a algum documento geral, mas quero informar que temos esse documento geral. Se você pode ler, leia. Se você escrever, tudo bem, escreva. Mas não quero transferir nenhum direito a ele. Eu só quero lhe dizer: "Ei, essa coisa, tente!" Portanto, isso é um inconveniente no mundo das oportunidades, porque realmente obriga a nunca falar sobre objetos sem transferir direitos para esse objeto.

Portanto, é importante saber sobre isso e usar esse recurso em algumas partes do sistema, mas não confiar nisso para ser a solução para a segurança do sistema.



Público: suponha que o processo possua os recursos atribuídos a ele por algum outro processo, mas acontece que ele já possui ótimos recursos em relação a algum objeto. Um processo pode compará-los para garantir que eles estejam tocando o mesmo objeto? Ou ele usará as grandes oportunidades?

Professor: o fato é que o processo não utiliza recursos de maneira implícita, portanto, essa é uma propriedade muito útil dos recursos. Você deve definitivamente indicar qual das opções que está usando. Então pense nisso em termos de um descritor de arquivo. Suponha que eu lhe forneça um descritor de arquivo aberto para algum arquivo, e ele é somente leitura. Depois, outra pessoa oferece outra oportunidade para outros arquivos, que podem incluir esse arquivo. E um novo recurso permite que você leia e grave em arquivos.

Nesse caso, se você tentar gravar no primeiro arquivo, sem dúvida terá êxito, porque um descritor de arquivo adicional será aberto para ele, o que permite não apenas a leitura, mas também a gravação. Portanto, isso é uma coisa interessante quando você não precisa de privilégios externos extras. Você simplesmente tem todas essas possibilidades, porque as pessoas realmente criaram essas bibliotecas e, em princípio, elas gerenciam seus recursos para você. Eles meio que os colecionam. E quando tentam executar uma operação, procuram oportunidades e encontram aquelas que a fazem funcionar.

Isso retorna ao controle externo da autoridade ambiental que você estava tentando evitar. Uma característica positiva das possibilidades é que é um design de software que simplifica sua vida. Isso é incomum em soluções de segurança. Essa propriedade facilita a gravação de um código que aponta para os privilégios que você deseja usar do ponto de vista da segurança. E isso é muito fácil de escrever código.
No entanto, o recurso pode resolver outros problemas. Portanto, problemas de gerenciamento de privilégios geralmente surgem quando você precisa executar algum código não confiável. Porque você realmente deseja controlar quais privilégios você concede, caso contrário, existe o risco de uso indevido de todos os privilégios que você concede. E esse é um ponto de vista ligeiramente diferente do qual os autores do artigo sobre Capsicum abordam oportunidades. É claro que eles estão cientes do problema da autoridade externa, mas esse é um problema ligeiramente diferente que você pode ou não pode resolver. Mas, basicamente, eles se preocupam com o fato de terem um aplicativo privilegiado muito grande e se preocupam com a ocorrência de erros em diferentes partes do código-fonte desse aplicativo. Portanto, eles gostariam de reduzir os privilégios dos vários componentes deste aplicativo.

Nesse sentido, a história é muito semelhante à OKWS . Portanto, você tem um aplicativo grande, divide-o em componentes e restringe os privilégios para cada componente. Isso certamente faz sentido no OKWS . Existem outras situações em que você pode se preocupar em compartilhar privilégios? Eu acho que no artigo deles eles descrevem exemplos que eu deveria tentar executar, por exemplo, tcpdump e outros aplicativos que analisam dados de rede. Por que eles estão tão preocupados com aplicativos que analisam entradas de rede? O que acontece no tcpdump ? Qual é o motivo de sua paranóia?

Público: um invasor pode controlar o que é enviado e o que é chamado para executar, por exemplo, pacotes.

Professor: sim, eles realmente se preocupam com ataques desse tipo e se o invasor pode realmente controlar os dados de entrada? Porque é bastante problemático se você escrever código C que deve lidar com estruturas de dados. Obviamente, você fará muita manipulação de ponteiros copiando bytes para matrizes que alocam memória. Ao mesmo tempo, é fácil cometer um erro no gerenciamento de memória, o que levará a consequências bastante desastrosas.

Portanto, essa é a razão pela qual eles decidiram fazer o trabalho de seu protocolo de rede e outras coisas na sandbox.



Outro exemplo do mundo real onde o compartilhamento de privilégios é necessário é o seu navegador. Você provavelmente desejará isolar seu plug-in Flash, sua extensão Java ou qualquer outra coisa. Porque eles representam um amplo campo para ataques que são usados ​​de forma bastante agressiva.

Portanto, este parece ser um plano inteligente. Por exemplo, se você escreve algum software, deseja verificar o comportamento de seus componentes na caixa de areia. Geralmente, isso se refere ao que você baixou da Internet e pretende executar com menos privilégios. O estilo de isolamento oferecido pela Capsicum combina com isso ? Eu poderia baixar algum protetor de tela aleatório ou algum jogo da Internet. E eu quero executá-los no meu computador, mas primeiro verifique se eles não estragam tudo o que tenho. Você usaria Capsicum para isso?

Público: você pode escrever um programa sandbox no qual usará o Capsicum .

Professor: certo. Como você o usaria? Bem, você entra no modo sandbox com o comando cap_enter e executa o programa. Você espera que isso funcione? Eu acho que haverá um problema. Ele estará conectado ao fato de que, se o programa não esperar que seja isolado pelo Capsicum , ele poderá tentar abrir a biblioteca compartilhada, mas não poderá fazer isso, porque não poderá abrir algo como / lib / ... , porque não permitido no modo de capacidade .

Portanto, esses métodos de sandbox devem ser usados ​​para as coisas pelas quais o desenvolvedor previu que eles podem ser executados nesse modo. Provavelmente, existem outros métodos de sandbox que podem ser usados ​​para código não modificado, mas os requisitos podem mudar um pouco. Portanto, os criadores de Capsicum não estão muito preocupados com a compatibilidade com versões anteriores. Se tivermos que abrir arquivos de maneira diferente, nós os abriremos de maneira diferente. Mas se você quiser deixar o código existente, precisará de algo mais, por exemplo, uma máquina virtual completa para poder executar o código nela. Isso levanta a questão - devemos usar máquinas virtuais para a caixa de proteção Capsicum ?

Público: neste caso, a saturação de memória é possível.

Professor: sim, é. Mas e se não nos importarmos com a memória? Portanto, as máquinas virtuais provavelmente são muito boas e não usam muita memória. Então, por que outro motivo não devemos usar VM no Capsicum ?

Público: É difícil controlar a atividade da rede.

Professor: Isso mesmo! É difícil controlar o que está acontecendo na rede porque você não está dando acesso à máquina virtual à rede ou está se conectando à rede através do modo NAT ou usando o Preview ou o VMWare . Mas então sua caixa de areia pode acessar toda a Internet. Portanto, você precisará gerenciar a rede com mais detalhes, talvez definindo regras de firewall para a máquina virtual e assim por diante. Isso não é muito bom.

Mas e se você não se importa com a rede? Suponha que você tenha algum tipo de vídeo, e se você processar um vídeo simples ou analisar o tcpdump . Nesse caso, você simplesmente inicia a máquina virtual, ela começa a analisar seus pacotes tcpdump e faz com que você retorne após a apresentação que o tcpdump deseja gravar para o usuário, porque não há E / S de rede real. Então, existe algum outro motivo?



Público: porque a sobrecarga da inicialização ainda é alta.

Professor: sim, isso pode ser a sobrecarga inicial de iniciar uma máquina virtual, o que reduz o desempenho. Então é verdade.

Público: Bem, você ainda pode querer ter direitos sobre um banco de dados e similares.

Professor: sim. Mas, de maneira geral, isso significa que você tem dados reais com os quais está trabalhando e é realmente difícil separá-los. Assim, as máquinas virtuais são realmente um mecanismo de compartilhamento muito maior, pelo qual você não pode compartilhar coisas facilmente. Portanto, isso é bom para situações em que você tem um programa completamente isolado que deseja executar e, ao mesmo tempo, não deseja compartilhar arquivos, diretórios, processos e apenas deixá-los trabalhar separadamente.

Então isso é ótimo. Provavelmente, isso é, de alguma forma, um isolamento mais forte do que o fornecido pelo Capsicum , porque há menos opções para que as coisas dêem errado. No entanto, esse isolamento não é aplicável em muitas situações quando você deseja usar o Capsicum . Como no Capsicum, você pode trocar arquivos com grande precisão, usando os recursos da sandbox.

Então, vamos pegar o tcpdump e ver por que é difícil isolá-lo usando o mecanismo Unix . Se você se lembra, no Capsicum, o funcionamento do tcpdump é que ele abre alguns soquetes especiais e executa a lógica de análise nos pacotes de rede, após o que é impresso nos terminais do usuário. Então, o que é necessário para uma sandbox tcpdump baseada em Unix ? Seus privilégios são limitados? O problema com o Unix é que a única maneira de realmente alterar privilégios é alterar a entrada na função de decisão, que decide se você pode realmente acessar algum objeto ou não. E a única coisa que você pode realmente mudar é os privilégios do processo. Isso significa que o processo poderá enviar o UID para outra pessoa.

Ou você pode alterar as permissões para vários objetos que estão no seu sistema. De fato, você pode usar essas duas soluções.

Se você deseja isolar o tcpdump na sandbox, provavelmente precisará selecionar um ID de usuário adicional e alternar para ele enquanto trabalha. Mas esse não é um plano ideal, pois você não executará várias instâncias do tcpdump com o mesmo ID do usuário. Portanto, se eu comprometer uma instância do tcpdump , isso não significa que desejo que um invasor use esse fator para controlar outras instâncias do tcpdump em execução na minha máquina. Portanto, essa é potencialmente uma má decisão de usar o uid neste caso.

Outro problema é que, no Unix, você deve ter privilégios de root para alterar o ID do usuário, privilégios, processo ou outra coisa, ou alterná-los para outra coisa. Isso também é ruim.

E outro problema é que, independentemente do seu ID , podem existir arquivos de acesso aberto. Portanto, seu sistema pode ter um grupo inteiro de arquivos legíveis ou graváveis, por exemplo, um arquivo de senha. De fato, não importa qual ID você tenha, o processo ainda poderá ler essa senha. Portanto, isso também não é muito bom.

Assim, para organizar uma caixa de proteção no Unix , você provavelmente deve fazer as duas coisas: alterar o UID e revisar cuidadosamente as permissões de todos os objetos para garantir que você não tenha arquivos abertos não isolados sensíveis a serem substituídos ou legíveis por um hacker. Eu acho que, ao fazer isso, você obtém outro mecanismo que pode usar. Se você enviá-lo até o final, poderá ter dificuldade em compartilhar arquivos ou diretórios.

Agora vamos ver como o Capsicum está tentando resolver esse problema. Aqui, assim que entrarmos no modo "sandbox", tudo estará disponível apenas através de oportunidades. Portanto, se você não tiver Capacidade , você simplesmente não poderá acessar nenhum objeto.

Esses caras no artigo fazem uma enorme aposta no espaço para nome global. Então, o que é esse espaço de nome global e por que eles estão tão preocupados com isso?

O próprio sistema de arquivos é um tipo de exemplo brilhante de um espaço para nome global. Você pode escrever uma barra e listar qualquer arquivo que desejar por trás dela. Por exemplo, vá para alguém no diretório inicial, por exemplo, / home / nickolai / ... Por que isso é ruim? Por que eles são contra o espaço para nome global no Capsicum ? O que você acha?



Público: se você tiver as permissões erradas, ao usar a autoridade, poderá ter problemas.

Professor: sim. O problema é que ainda é o Unix . Portanto, ainda existem permissões de arquivo regulares. Portanto, talvez, se você realmente deseja isolar algum processo na caixa de areia, não poderá ler ou escrever nada no sistema. Mas se você conseguir encontrar um arquivo gravável no diretório inicial de algum usuário estúpido, isso será bastante desagradável para o cliente sandbox.

De maneira mais geral, a ideia deles era listar com precisão todos os objetos que o processo possui. Porque você pode simplesmente listar todos os recursos em uma tabela de descritores de arquivos ou em qualquer outro lugar onde os recursos estão armazenados para você. E esta é a única coisa que o processo pode tocar.

Mas se você tiver acesso ao espaço para nome global, isso é potencialmente impossível. Porque, mesmo que você tenha um conjunto limitado de recursos, ainda poderá iniciar a linha com uma barra e escrever um novo arquivo e nunca conhecerá o conjunto de operações ou objetos que esse processo pode acessar.

É por isso que eles estão tão preocupados com o espaço para nome global, porque isso contradiz o objetivo de controlar com precisão tudo o que o processo sandbox deve ter acesso. Dessa forma, eles tentaram eliminar os namespaces globais com muitas alterações no kernel no FreeBSD . No caso deles, o kernel precisava garantir que todas as operações passassem por alguns recursos, a saber, pelo descritor de arquivo.

Vamos verificar se realmente precisamos de alterações no kernel. E se apenas fizermos isso na biblioteca? Afinal, estamos implementando o Capsicum , que já possui uma biblioteca. E tudo o que fazemos é alterar todos esses recursos, como "abrir, ler, escrever", para usar exclusivamente os recursos de capacidade . Todas as operações passarão por alguns recursos, procurá-los na tabela de arquivos e assim por diante. Isso vai funcionar?



Público: você sempre pode fazer a chamada do sistema syscall .

Professor: sim. O problema é que houve um conjunto de chamadas de sistema que o kernel aceita e, mesmo que você implemente uma boa biblioteca, isso não impedirá a possibilidade de que um processo ruim ou comprometido faça uma chamada de sistema diretamente. Portanto, você deve de alguma forma fortalecer o núcleo.

No compilador, o modelo de ameaça não está no processo comprometido do compilador e não no código arbitrário, mas no descuido do programador. Portanto, se o desenvolvedor do programa não estiver enganado e fizer a coisa certa, a biblioteca provavelmente será suficiente.

, , , . - , .

? — , cap_enter . , cap_enter ? , ?

, , . , , , . cap_enter , open () , openat .

Unix- , , open , openat , , , — : openat (dirfd,“name) . openat «name» , .



, Capability open , , , . . - ? -, ? , – . , ?

: , .

: . , , . , , . , . , , . -, .

, , , , , . , , .. , , , . ?

. ? , Unix PID . , kill (25) PID = 25 . , . Capsicum ? ?

: .

: . -, . , Unix , . , PID , , fork , pdfork , « ». , - .

. , . , - : « «» , , , , ». . , , - .

, , , . , . , , .



. , «-» . , openat , «-». , «-», .

? , «-» ?

: , , . , Capability .

: , .

: , , - …

: .

: - .

: , . «-» ? , openat - b/c/../.. ?

, , ? - , . , , , openat (d, “b/c/../..) «c» , - .



. , , , . «-», . , , . , , . , UID - ?

: , .

: , . , , «» UID ? : cap_enter UID . , . ? ?

: , UID , , , , , - .

: , . «» UID . , , UID. Acontece que eu tenho centenas de processos em execução no meu computador e não tenho ideia do que é. Portanto, destruir o UID não é um bom plano para fins de gerenciamento.

54:14 min

Continuação:

Curso MIT "Segurança de sistemas de computadores". Palestra 6: “Oportunidades”, parte 3


A versão completa do curso está disponível aqui .

Obrigado por ficar conosco. Você gosta dos nossos artigos? Deseja ver materiais mais interessantes? Ajude-nos fazendo um pedido ou recomendando a seus amigos, um desconto de 30% para os usuários da Habr em um análogo exclusivo de servidores básicos que inventamos para você: Toda a verdade sobre o VPS (KVM) E5-2650 v4 (6 núcleos) 10GB DDR4 240GB SSD 1Gbps de US $ 20 ou como dividir o servidor? (as opções estão disponíveis com RAID1 e RAID10, até 24 núcleos e até 40GB DDR4).

Dell R730xd 2 vezes mais barato? Somente nós temos 2 TVs Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 a partir de US $ 249 na Holanda e nos EUA! Leia sobre Como criar um prédio de infraestrutura. classe usando servidores Dell R730xd E5-2650 v4 custando 9.000 euros por um centavo?