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

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-alvo: se esse UID fornecer acesso somente leitura a esse arquivo e você também tiver um descritor de arquivo, se perder o UID , ainda poderá obter permissão para ler esse arquivo?

Professor: sim, pois ele aparecerá em catálogos. Porque assim que você adiciona o recurso ao arquivo, é isso. Está aberto para você com privilégios especiais e assim por diante. Mas o problema é que eles têm esse design híbrido.

Ou seja, eles dizem - você realmente pode adicionar recursos aos diretórios e pode abrir um novo arquivo enquanto trabalha em paralelo. Pode ser que você adicione o recurso a um diretório, como / etc , mas você não tem acesso obrigatório a todos os arquivos no diretório / etc. Mas assim que você entra no modo de recursos, pode tentar abrir esses arquivos, sabendo que tem acesso ao diretório / etc. Afinal, ele já está aberto. Por que você não me fornece um arquivo chamado "senha" localizado neste diretório?



E então o kernel precisa decidir se você deseja abrir o arquivo neste diretório no modo de leitura ou gravação ou o que você possui. Então, acho que este é o único lugar em que você ainda precisa desse privilégio externo, porque eles tentaram criar um design compatível, onde usavam semânticas não muito naturais para descrever a operação de diretórios. Este parece ser o único local onde permanecem os princípios para a configuração de um sistema de arquivos Unix .

Público: existem outros lugares?

Professor: boa pergunta. Acho que terei que obter o código-fonte anterior para descobrir o que está acontecendo, mas a maioria das outras situações realmente não exige verificação de UID . Porque, por exemplo, não é usado para redes. Essas são provavelmente as operações usuais do sistema de arquivos - se você possui um segmento de memória compartilhada, basta abri-lo e pronto.

Público: poderia explicar novamente qual é exatamente o ID do usuário, se você tiver o recurso de capacidade ?

Professor: isso é importante quando você tem a oportunidade de catalogar. A questão é: o que essa oportunidade apresenta a você? Considere uma interpretação, por exemplo, o estado dos recursos de um sistema limpo, não o Capsicum . Se nesse sistema você tiver a oportunidade de um diretório, terá acesso incondicional a todos os arquivos desse diretório.

No Unix, esse geralmente não é o caso. Você pode abrir o diretório como / etc , mas ele possui muitos arquivos de sistema nos quais as informações confidenciais podem ser armazenadas, por exemplo, a chave privada do servidor. E o fato de poder abrir e rolar por esse diretório não significa que você não pode abrir arquivos nesse diretório. Ou seja, tendo acesso ao diretório, você tem acesso aos arquivos.

No Capsicum , se você abrir o diretório / etc e entrar no modo de recurso, acontece o seguinte. Você diz: “Não sei o que é esse diretório. Acabei de adicionar um descritor de arquivo. " Há um arquivo chamado "chave". Por que você não abre este arquivo "chave" ? Só porque naquele momento, você provavelmente não deseja que esse processo baseado em recursos abra esse arquivo, porque você não precisa dele. Embora isso permita que você ignore as permissões do Unix para o arquivo.

Portanto, acho que os autores deste artigo abordaram cuidadosamente o desenvolvimento de um sistema que não violaria os mecanismos de segurança existentes.

Público: ou seja, você diz que, em alguns casos, pode usar uma combinação desses dois fatores de segurança? Ou seja, embora o usuário possa alterar o arquivo no diretório, quais arquivos ele acessa depende de seu ID de usuário?

Professor: sim, exatamente. Na prática, no Capsicum , antes de entrar no modo de recursos, você precisa adivinhar quais arquivos podem ser necessários posteriormente. Você pode precisar de bibliotecas compartilhadas, arquivos de texto, modelos, conexões de rede e assim por diante. Portanto, você abre tudo isso com antecedência. E nem sempre é necessário saber qual arquivo você precisa. Então esses caras fizeram isso para que você possa simplesmente abrir o descritor de arquivo do diretório e visualizar os arquivos necessários mais tarde. No entanto, pode ser que esses arquivos não tenham as mesmas permissões que você possui. É precisamente por esse motivo que uma combinação de dois fatores de segurança é usada - verificando os recursos e o uid do usuário. Portanto, isso faz parte do mecanismo do kernel.



Por que eles precisam de uma biblioteca como libcapsicum ? Eu acho que há duas coisas principais que eles apóiam nesta biblioteca.

Uma delas é que eles implementam uma função chamada lch_start , que você deve usar em vez da função cap_enter . Outra função que libcapsicum fornece é o conceito de listas fd, que é usado para passar descritores de arquivo por números. O objetivo desta lista fd é fácil de explicar. Isso é basicamente uma generalização de como o Unix gerencia e passa descritores de arquivos entre processos. No Unix e Linux tradicional, que você usa hoje, alguns descritores de arquivo são passados ​​para ele quando o processo é iniciado. Você simplesmente abre alguns descritores de arquivo com valores inteiros nesta tabela e inicia o processo filho de que precisa. Ou você executa um binário específico e ele herda todos esses slots abertos na tabela fd . No entanto, não há outra maneira boa de nomear essas coisas além de usar números como nomes.

Considere um exemplo no qual o slot 0 será usado para entrada, slot 1 para saída e slot 2 para impressão de mensagens de erro. É assim que funciona no Unix . E funciona bem se você apenas transferir esses três arquivos ou três fluxos de dados para o processo.



Mas no Capsicum, acontece que você “passa por” muito mais descritores de arquivos no seu caminho. Portanto, quando você passa um descritor de arquivo para alguns arquivos, passa por um descritor de arquivo para uma conexão de rede, um descritor para uma biblioteca compartilhada que você possui e assim por diante. Gerenciar todos esses números é bastante tedioso. Portanto, de fato, libcapsicum fornece a capacidade de abstrair o nome desses descritores de arquivo anteriores entre processos usando um nome hierárquico usado em vez desses números inteiros obscuros.
Essa é uma das coisas simples que eles fornecem em sua biblioteca. Para que eu possa passar o descritor de arquivo para o processo e dar um nome, não importa qual número seja indicado. Este método é muito mais simples.

Eles ainda têm outro mecanismo de inicialização de sandbox mais complexo. Isso é lch , a API do host da sandbox usada em vez de apenas entrar no modo de recursos de capacidade . Por que eles precisavam de algo mais do que uma simples entrada no modo de oportunidade? O que geralmente incomoda você ao criar uma sandbox?

Público: provavelmente, lch apaga todas as coisas herdadas para garantir um início "limpo" do sistema.

Professor: sim. Eu acho que eles estão preocupados em tentar levar em conta tudo o que a sandbox tem acesso. O problema é que, se você simplesmente chamar cap_enter , tecnicamente, no nível do mecanismo do kernel, ele funcionará. Certo? Isso apenas impede que você descubra novas oportunidades.

Mas o problema é que pode haver muitas coisas existentes às quais o processo já tem acesso.

Portanto, acho que o exemplo mais simples é a presença de descritores de arquivos abertos lá que você esqueceu, e eles simplesmente serão herdados por esse processo.



Por exemplo, eles consideraram tcpdump . Primeiro, eles mudaram o tcpdump simplesmente chamando cap_enter antes mesmo de analisar todas as conexões de rede recebidas. De certa forma, isso funciona bem porque você não pode obter mais recursos de capacidade . Mas então, olhando para o descritor de arquivo aberto, eles perceberam que você tem acesso total ao terminal do usuário, porque você possui um descritor de arquivo aberto. Para que você possa interceptar todas as teclas digitadas pelo usuário e assim por diante. Portanto, este provavelmente não é um bom plano para o tcpdump . Porque você não deseja que alguém intercepte sua atividade no teclado.

Portanto, no caso do tcpdump, eles alteraram manualmente os descritores de arquivo e adicionaram alguns bits de recursos a eles para limitar os tipos de operações que você pode executar. Se você se lembra, no Capsicum, o recurso também possui esses bits extras, indicando a classe de operações que podem ser executadas para um determinado descritor de arquivo. Assim, eles assumem basicamente que o descritor de arquivo é 0. Aponta para o terminal do usuário tty. Inicialmente, era apenas um ponteiro direto para a estrutura tty no kernel. Para limitar o tipo de operações que podem ser executadas para esse descritor, eles introduziram alguma estrutura beta intermediária de recursos no meio. Portanto, o descritor de arquivo aponta para essa estrutura de recursos e já aponta para o arquivo real que você está tentando acessar. E essa estrutura de recursos contém alguns bits ou permissões restritivos para um objeto descritor de arquivo que pode ser implementado.

Assim, com a entrada de dados padrão no tcpdump, você não pode fazer nada com ele. Você pode apenas ver que existe, e é isso. Para o descritor do arquivo de saída, eles forneceram uma oportunidade quando você pode gravar algo nele, mas não pode alterar o registro, ou seja, não é possível cancelar as alterações feitas.



Então, o que mais você poderia se preocupar em lançar a sandbox ? Penso no estado do descritor de arquivo. Mais alguma coisa importa? Eu acho que no Unix são descritores de arquivos e memória.

Outra coisa é que esses caras estão preocupados com o fato de que no seu espaço de endereço possa haver dados confidenciais alocados anteriormente. E o processo que você vai isolar na caixa de areia pode ler toda a memória disponível. Portanto, se houver algum tipo de senha que você verificou anteriormente, quando o usuário efetuar login e você ainda não tiver limpado a memória, esse processo poderá lê-la e fazer algo "interessante".

Eles resolveram esse problema da seguinte maneira: no lch_start, você precisa executar um programa "novo". Você pega o programa e empacota todos os argumentos nele, todos os descritores de arquivos que deseja fornecer. Em seguida, você inicia um novo processo ou inicia a operação de reinicialização de todo o espaço de memória virtual. E não há dúvida de que esse processo não receberá privilégios adicionais para afetar o conjunto de dados confidenciais. Isso é exatamente o que você passou para a função lch_start , em termos de nomes binários, argumentos e recursos do programa.

Público: o que acontece se o processo iniciado contiver setuid binário = 0 ?

Professor: Eu acho que esses caras não usam "binários" setuid no modo de recurso para evitar algumas interações estranhas que possam aparecer. Eles implementam esta regra: você pode ter um programa setuid que obtém seus privilégios do binário setuid e, em seguida, pode chamar cap_enter ou lch_start . Mas depois que você entra no modo de recursos, não pode restaurar preferências adicionais.

Em princípio, isso poderia funcionar, mas seria muito estranho. Porque, se você se lembrar, a única coisa em que o UID importa quando você está no modo de recurso é abrir arquivos dentro de um diretório. Portanto, não está claro se esse é realmente um excelente plano para obter privilégios adicionais ou se há falhas nele.

Público: Anteriormente, falamos sobre por que a biblioteca não suporta realmente uma separação estrita entre os dois fatores de segurança. Mas não precisamos usar lch_start ?

Professor: isso mesmo. Suponha que você tenha algo como tcpdump ou gzip - essa é outra coisa com a qual eles trabalham. Você supõe que o aplicativo provavelmente não esteja comprometido, e há alguma função básica do aplicativo e se preocupa com o modo como ele se comporta na caixa de proteção. No caso do tcpdump, é uma análise de pacotes provenientes da rede; no caso do gzip , está descompactando arquivos. E até certo ponto, você assume que o processo está fazendo tudo certo e que não haverá vulnerabilidades. Portanto, você confia nele para executar lch_start e acredita que ele criará a imagem corretamente, configurará corretamente todos os recursos e se limitará a qualquer outra chamada de sistema fora do modo de recursos.

E então você lança coisas perigosas. Mas até então a instalação estava correta e você não tem como sair dessa sandbox. Então, acho que você precisa ver como realmente pode usar o modo de recurso para aplicativos sandbox.

Então conversamos um pouco sobre o tcpdump . Como você isola esse processo? Outro exemplo interessante é o programa gzip , que compacta e descompacta arquivos. Então, por que eles estão preocupados com a caixa de areia? Acho que eles estão preocupados com o fato de o código de descompactação poder ser potencialmente defeituoso ou com erros no gerenciamento de memória, gerenciamento de buffer durante a descompactação etc.



Outra questão interessante é por que as alterações no gzip parecem muito mais complicadas do que no tcpdump ? Eu acho que isso se deve à forma como o aplicativo é estruturado internamente, certo? Portanto, se você tiver um aplicativo que simplesmente compactou ou descompactou um arquivo, é normal iniciá-lo sem alterá-lo no modo de recursos. Você simplesmente atribui um novo padrão para descompactar algo, e o padrão fornece dados descompactados na saída, e isso funcionará bem.

O problema, como quase sempre acontece com esses métodos de sandbox, é que o aplicativo realmente tem uma lógica de processo muito mais complexa. Por exemplo, o gzip pode compactar vários arquivos de uma vez e assim por diante. E, nesse caso, você tem algum tipo de processo de liderança no início do aplicativo, que na verdade possui direitos adicionais para abrir vários arquivos, compactá-los e assim por diante. E a lógica principal geralmente precisa ser outro processo de suporte. No caso do gzip, o aplicativo não foi estruturado para que a compactação e descompactação atuassem como processos separados. Portanto, eles tiveram que mudar a implementação do kernel gzip e alguma estrutura do próprio aplicativo, para que, além de apenas passar dados para a função de descompressão, eles fossem enviados por uma chamada RPC ou realmente gravados em algum tipo de descritor de arquivo. Isso foi para evitar problemas de terceiros e descompactar praticamente sem privilégios. A única coisa que o gzip poderia fazer ao mesmo tempo era retornar os dados descompactados ou compactados para o processo que o chamou.

Outra coisa de lição de casa é como você realmente usa Capsicum no OKWS ? O que você acha disso? Seria útil? O pessoal do OKWS ficaria feliz em atualizar para o FreeBSD porque é muito mais fácil de usar? Como você usaria Capsicum no FreeBSD ?

Público: Pode-se livrar-se de algumas restrições estritas.

Professor: sim, podemos substituí-los completamente pela presença de um diretório de descritores e recursos de arquivos. Você não precisaria configurar um chroot confuso. Em vez de usar o chroot com muitas pequenas coisas, você pode definir permissões com cuidado. Você pode simplesmente abrir os arquivos exatos que precisa. Então isso parece uma grande vantagem.

Em seguida, no OKWS , você tem o serviço de inicialização OK , que deve iniciar todos os processos pai. Assim que eles morrem, o sinal volta ao okld para reiniciar o processo "morto". E isso teria que ser executado como root , porque ele tinha que isolar os processos na caixa de areia. Mas há várias coisas no OKWS que podem ser melhoradas com Capsicum .

Por exemplo, você pode fornecer ao okld muito menos privilégios. Porque, por exemplo, para obter a porta 80, você precisa de privilégios de root. Mas depois disso, você pode colocar com segurança todo o resto na sandbox, porque os direitos de root não são mais necessários. Então é bem legal. Talvez você possa até delegar ao processo o direito de responder às solicitações de outra pessoa, por exemplo, um processo de monitoramento do sistema que apenas possui esse descritor de processo ou descritor de processo para o processo filho e, sempre que esse processo falha, ele inicia um novo. Portanto, acho que a capacidade de criar uma caixa de proteção sem privilégios de root é muito útil.

Público-alvo: você pode atribuir a cada processo um descritor de arquivo que permita adicionar apenas entradas ao log.

Professor: sim, e isso é muito legal. Como dissemos na última vez, o oklogd pode "bagunçar" o arquivo de log. E quem sabe o que o kernel permitirá que ele faça quando tiver o descritor de arquivo do próprio arquivo de log. No entanto, podemos determinar com mais precisão os recursos do descritor de arquivo, fornecendo um arquivo de log e indicando que ele pode apenas gravar, mas não procurar nada. Assim, obtemos a função somente acréscimo se você é apenas um "escritor" para este arquivo. É muito conveniente Você pode conceder ao processo permissões para gravar no arquivo, mas não lê-lo, o que é muito difícil de fazer usando apenas as permissões do Unix .

Capsicum ?

: , , , . , , , .

: , . Capsicum , , . .

: , , okld . , .

: , . . , , Capability , . , , , , , .
, OKWS . . , , , . .

, , «». , . , , , , . .
: «» , , ?

: , FreeBSD . , - , . FreeBSD Casper , , Capability . , «».

- , , , - , , Casper .



, «» . . , , , Casper - .

, , - . , Unix FD . , . , , .

, FreeBSD , DNS . DNS -, «». , tcpdump . tcpdump , IP-. , , DNS -.

, , DNS- DNS-, . Casper , DNS-.

, , , Capsicum? ? ? , , . Capsicum , ?

tcpdump GZIP , , . ?



: , , , . , Capability .

: , . Capsicum , , . , , . , , , , Capsicum , .

, «». , TCP — helper , , , , . , , , .

: , .

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

, , Capsicum . , , , . Unix - , .

, . , . , , . , .

, Chrome . , , , Unix, -, Unix .

, ?

: .

: . . , . , , , , .

Unix , . , . , . . , .

. Linux , setcall , , . , Capsicum , , Capsicum , . Linux setcall , . , , Linux .

, — , , , , . , - , «//», . Capsicum onde você pode iniciar o processo para um arquivo específico e não para o diretório pessoal inteiro.


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).

3 meses de graça ao pagar por um novo Dell R630 por um período de seis meses - 2 x HDD Intel Deca-Core Xeon E5-2630 v4 / 128GB DDR4 / 4x1TB ou SSD 2x240GB / 1Gbps 10 TB - de US $ 99,33 por mês , apenas até o final de agosto, faça o pedido pode estar aqui .

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?