Curso MIT "Segurança de sistemas de computadores". Palestra 4: “Compartilhando Privilégios”, Parte 1

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

Hoje falaremos sobre o compartilhamento de privilégios, pois acabamos com estouros de buffer em um determinado nível, mas voltamos a ele. Não falaremos sobre os detalhes de como usar estouros de buffer, mas mudaremos para reduzir esse problema e falaremos sobre como desenvolver um sistema no qual estouros de buffer não serão um grande problema para você, como outras vulnerabilidades.



Hoje, falaremos sobre o compartilhamento de privilégios como um método que permite criar um sistema mais seguro. Nos materiais das palestras, mencionamos um servidor da Web chamado OKWS . Este não é o exemplo mais revelador da separação de direitos, mas o sistema é bem descrito aqui para entender como todas as suas partes funcionam. Mas isso não significa que você deve ir agora, baixar o OKWS e iniciar o seu site.

Portanto, antes de nos aprofundarmos nos detalhes das permissões do OKWS e do Unix, vamos ver o que é o compartilhamento de privilégios e por que é uma boa idéia? Na semana passada, James mostrou que se você escrever um programa em C, quase inevitavelmente terá algo ruim ou errado. Além disso, o problema é que, se você tem um aplicativo grande o suficiente e existe algum tipo de vulnerabilidade, os invasores podem se conectar ao programa, enviar solicitações para esse aplicativo, enganá-lo e fazer coisas "ruins".

Qualquer aplicativo tem privilégios de acesso. Isso significa que inclui muitos dados que podem ser obtidos com o acesso. Você pode até excluir esses arquivos, como fizeram no laboratório número 1. O problema é que uma vulnerabilidade nesse aplicativo grande pode permitir que um invasor modifique qualquer um desses dados ou obtenha privilégios suficientes para gerenciar o programa, se você não tomar cuidado.
Nesta palestra, veremos o que o compartilhamento de privilégios está tentando fazer. Vale a pena pegar o programa, dividi-lo em partes e garantir que cada um dos elementos individuais possua apenas os privilégios necessários para executar seu trabalho corretamente.



À esquerda, temos um programa de três partes e, à direita, dados, também constituídos por três partes. Privilégios atribuídos corretamente significam que cada parte do aplicativo tem acesso apenas à sua parte dos dados. E se tivermos uma vulnerabilidade no programa X, ele nos permitirá assumir o controle de apenas uma parte dos dados e não poderá afetar os dados nas outras duas partes.
Portanto, essa ideia de compartilhar privilégios é extremamente forte. Ele não serve para afetar especificamente o problema de estouros de buffer ou outras vulnerabilidades; eles são simplesmente requisitos gerais para a arquitetura de produtos de software para garantir que as vulnerabilidades em um local do sistema não afetem suas outras partes. A separação de privilégios é usada amplamente. Portanto, para garantir o isolamento dos componentes em um programa, as máquinas virtuais são frequentemente usadas.

Você pode pegar seu sistema grande e dividi-lo em várias VMs para isolar partes individuais, mas também pode usar o Unix para realmente executar esse isolamento com "fatia". O Unix fornece alguns mecanismos que o OKWS realmente usa para separar privilégios.

Muitos aplicativos realmente usam práticas de compartilhamento de privilégios. Vocês provavelmente usaram SSH, ou "shell seguro", com bastante frequência. Este é um protocolo de rede usado para controlar remotamente o sistema operacional e transferir arquivos. Ele usa o compartilhamento de privilégios em muitos de seus componentes para garantir que suas chaves de criptografia não sejam desvendadas e que o servidor não seja comprometido. O navegador da web Chrome é mais relevante para você, no qual o compartilhamento de privilégios também é implementado amplamente. Portanto, se houver algum tipo de "bug" no Chrome, o adversário não poderá obter controle total sobre o seu computador.

Este é um resumo muito breve do que é o compartilhamento de privilégios e por que o OKWS é um exemplo interessante. No entanto, ele é mais um exemplo vívido do que um software importante.

Portanto, o OKWS , como mencionei, usará permissões Unix e algum tipo de mecanismo Unix para separar os vários componentes. É importante para nós entender como funcionam os mecanismos de segurança Unix. O Unix, como uma ferramenta para compartilhar privilégios, é importante não apenas para entender o OKWS , como qualquer outra ferramenta de isolamento, como UID , VM , contêineres ou qualquer tecnologia similar, permite entender os detalhes do processo. Como existem muitas partes complexas do processo de obtenção de direitos de acesso, é possível lidar com um invasor que aproveitará a vulnerabilidade de qualquer uma dessas partes. Portanto, veremos o Unix em detalhes suficientes para entender o que é e como deve ser em um mecanismo de segurança específico.

O Unix tem sido historicamente o melhor exemplo de como criar um mecanismo de segurança. Seu mecanismo de segurança surgiu no processo de satisfazer a necessidade de separar usuários um do outro no mesmo sistema Unix. Ao mesmo tempo, acreditava-se que existem muitos usuários que usam o mesmo computador e você precisa mantê-los separados um do outro. Portanto, este não é necessariamente um mecanismo de uso geral, mas ainda é um dos mais comuns e amplamente utilizados. Portanto, o Chrome está tentando usar muitos mecanismos de compartilhamento de privilégios do Unix.

Quando você pensa em um mecanismo de proteção, deve pensar em seus princípios, o que significa que existe alguém com privilégios ou direitos, e o Unix inicia ou apóia esses direitos. Portanto, acho que o assunto ou assunto do Unix é um processo, já que um processo é suportado, porque toda operação ou solicitação que consideramos do ponto de vista de segurança deve permitir ou negar algo. Essa provavelmente será a operação chamada pelo processo, fazendo a chamada do sistema syscall . O que importa aqui é como descrevemos quais privilégios esse processo possui.

Em seguida, há um objeto em que nosso processo atua como sujeito. Ele pode modificar objetos, lê-los, observá-los. Existem muitos objetos no sistema operacional que você deve se preocupar em proteger. Com quais objetos você acha que devemos nos preocupar?

Público: sobre arquivos!

Professor: certo, sobre arquivos e diretórios. O que mais?



Público: Sobre os soquetes de rede!

Professor: sim, ótimo sobre soquetes de rede. Há mais alguma coisa acontecendo em nosso sistema?

Público: outros processos.

Professor: Isso mesmo. De fato, isso é semelhante ao que o aplicativo ou usuário deve cuidar, mas existem vários componentes internos do sistema que você também deve proteger. Portanto, o processo em si não é o assunto que faz a chamada do sistema, também é algo em que outro processo pode atuar. Ele pode matá-lo ou criar um novo. Portanto, você deve descobrir quais são as regras para perceber um processo como um objeto que pode ser manipulado. Que outras coisas podem nos preocupar?

Público: variáveis ​​de ambiente.

Professor: Eu acho que eles provavelmente não são um assunto que você possa mudar no sentido de gerenciar o OC e ter algum tipo de política de segurança. Eu acho que as variáveis ​​de ambiente são apenas algum tipo de estado de um processo contido na memória. Mas acho que, de maneira geral, nos preocupamos com essa parte do processo, que está contida na memória - variáveis ​​de ambiente, pilhas, argumentos, isso também é muito importante. Provavelmente, na memória do processo, existem muitas coisas sensíveis à interferência externa. O que mais?

Público: descritores de arquivos em geral.

Professor: há outra circunstância interna de grande importância. Os arquivos que estão no disco devem nos preocupar. Mas ainda existe uma ferramenta operacional como um descritor de arquivo, que o OKWS tenta usar amplamente, e veremos o que são. Que outras coisas você gostaria de proteger no sistema operacional?



Público: hardware ou hardware.

Professor: sim, o hardware requer proteção não menos do que as coisas abstratas que o sistema operacional nos fornece, porque não queremos que o nosso processador "congele" por algum motivo.

Público: Você também deve pensar em proteger periféricos!

Professor: Ah sim! Então, dispositivos adicionais, você está certo, especialmente em um computador de mesa, há muitas coisas desnecessárias: uma unidade USB, uma webcam, provavelmente a própria tela - você desejará proteger parte disso, porque os aplicativos relacionados a elas não devem estar “andando” »Em toda a sua tela.

Eu acho que, de fato, todos esses objetos não estão do lado do servidor, eles estão bem próximos. No seu telefone, o microfone provavelmente também é um objeto muito importante, que você também deseja proteger.

Mas deixarei esta lista, porque a seguir, falaremos principalmente sobre aplicativos de servidor, mas você está absolutamente certo sobre a lista de objetos. Acho que, para o OKWS, essa é provavelmente uma lista mais ou menos exaustiva de coisas que poderíamos cuidar de proteger, ou pelo menos que usa o OKWS .

Então, vamos falar sobre como o kernel do sistema operacional decide quando um processo pode fazer algo com qualquer um desses objetos. Portanto, em um nível alto, pensamos principalmente no processo como uma entidade com os privilégios concedidos por esse princípio, e o princípio no sistema Unix é algo bastante complicado.

Há algo chamado ID do usuário , que é um número inteiro de 32 bits. Há uma identificação de grupo , que também é um número inteiro de 32 bits. De fato, não há nenhuma razão particular para que eles sejam diferentes.



Seria bom se eles fizessem um único conjunto de números inteiros de 32 bits, mas, infelizmente, o Unix os divide em duas categorias. Existem números inteiros de ID do usuário e números de identificação do grupo . Quando falamos de um processo que possui certos privilégios, queremos dizer um processo associado a um determinado valor de uid . Normalmente, um processo tem um uid , bem como uma lista de identificadores de grupo gid que o processo possui. Por razões históricas, aconteceu que eles são combinados em um gid e, em seguida, combinados em uma lista de outros identificadores. Grosso modo, um processo pode exercer os privilégios representados por todos esses identificadores. Portanto, se o uid fornece acesso a algo, o processo pode fazer qualquer coisa com ele.

Agora vamos falar sobre arquivos, diretórios e outros tipos de objetos. Então, o que acontece com os arquivos, ou melhor, como criar permissões Unix para trabalhar com arquivos? Tudo é relativamente simples com arquivos; você está preocupado com as operações que podem ser feitas com eles: leitura, gravação, possivelmente execução, bem como a capacidade de alterar as próprias permissões ou outras propriedades de segurança.

Audiência: quebrando laços!

Professor: sim, quebrando links, desvincular - o que você acha que é propriedade do arquivo ou diretório? Na verdade, essa distinção é um pouco pouco clara. Quando o Unix pensa em excluir um arquivo, trata-se mais do diretório, porque no Unix, o arquivo realmente é um inode ou um inode. Portanto, no Unix, você pode ter alguns links físicos para inodes e, ao desconectar um nome de arquivo específico do Unix usando a opção desvincular, na verdade destrói apenas um dos nomes de arquivo, mas pode haver outros nomes e outros links para ele. De fato, é importante se você tem permissão para alterar o diretório apontando para o arquivo e, ao mesmo tempo, não fazer nada com o inode do próprio arquivo. Normalmente, as operações de desvincular , vincular , renomear e criar são operações associadas a um diretório, portanto, a criação afeta o diretório e o novo arquivo. Portanto, devemos descobrir quais regras se aplicam lá.



Para decidir que alguém pode ler ou gravar um arquivo, vamos inserir algumas permissões ou bits no arquivo inode . No Unix, todo inode que é finalmente um arquivo ou diretório possui vários campos interessantes por razões de segurança. Aqui está o ID do usuário e o identificador do grupo, que, como dizemos, possui o arquivo ou o diretório. Assim, você pode gerenciar todos os arquivos em seu diretório pessoal devido ao fato de o Unix ter seu uid .
O Unix também possui um conjunto de bits de permissão que podem ser considerados como parte da matriz; no design básico, eles se parecem com r (leitura), w (gravação) e x (execução). Podemos especificar essas permissões para várias entidades, e no Unix elas são especificadas para o proprietário, ou seja, para o inode uid , para o grupo de grupos ao qual o arquivo fornecido pertence, ou seja, para gid e para todos os outros - outros .

Você pode preencher essa matriz binária de 3 a 3, onde 1 significa permissão para executar uma determinada ação e 0 proíbe sua execução:



É assim que o Unix armazena permissões. Existe uma maneira tradicional de codificar essas coisas que você verá frequentemente e que provavelmente vale a pena mencionar. No Unix, essa matriz é codificada como um número octal; portanto, cada linha aqui deve ser considerada como um número base de 8; portanto, nossa matriz nessa codificação terá a seguinte aparência: r é 4 bits, w é 2 bits, x é 1 bit, respectivamente, proprietário - são 6 bits e o grupo e outro contêm 4 bits.



Você frequentemente verá essas designações nos materiais da aula, para poder dizer que esse arquivo tem uma resolução de 6, 4, 4, ou seja, o proprietário pode ler e escrever o arquivo, e o proprietário do grupo e outras pessoas podem apenas lê-lo.

Essas notações nos dizem quando ler, gravar e executar um arquivo. Que tal alterar permissões para este arquivo? Esta não é uma pergunta justa, mas o que vocês acham disso? Como devemos decidir que alguém possa alterar essas permissões, porque isso também pode ser necessário? Alguma idéia sobre isso?

Público: se essa pessoa tiver acesso ao arquivo?

Professor: talvez também dependa dos privilégios de acesso. Por outro lado, você pode criar um arquivo regravável substituível que deseja compartilhar com alguém para que ele possa ler, anexar e modificar seu arquivo, mas isso também significa que você pode alterar repentinamente as permissões para tornar o arquivo não regravável ou atribuir apenas para mim mesmo.

Portanto, os criadores do Unix decidiram que, se você possui um arquivo, ou seja, seu uid corresponde ao uid inserido no arquivo, então, por padrão, você pode alterar as permissões. Caso contrário, você não pode. Portanto, se você tiver apenas gid e esse grupo tiver todas as permissões no arquivo, ainda não poderá alterar as permissões para esse arquivo. Você pode simplesmente ler, reescrever, fazer qualquer coisa com ele, mas sem o uid você não pode alterar as permissões.

Os diretórios Unix seguem as mesmas regras. Portanto, desanexar e vincular as entradas de link em um diretório significa que você tem permissão para gravar neste diretório. Se você deseja renomear um arquivo, provavelmente precisará ter acesso de gravação ao diretório de onde o obtém e acesso de gravação ao diretório em que o colocou. Em alguns casos, os links físicos podem causar problemas, e nos materiais da palestra esses detalhes são destacados.

De fato, há outra operação interessante no catálogo - a pesquisa. Graças a ela, você pode simplesmente encontrar o arquivo no diretório O Unix codifica permissões de execução como a capacidade de implementar uma pesquisa por diretórios, portanto, ter permissão de execução para um diretório significa realmente poder procurar um nome de arquivo específico. Pode ser que você não precise ter permissão para o diretório para procurar o nome do arquivo, mas se você não tiver permissão de leitura, não poderá visualizar o conteúdo do diretório, ou seja, localize o arquivo. Isso é útil em algumas situações em que você precisa restringir ações com alguns arquivos ou ocultá-las do usuário.

Vejamos um exemplo. O que acontece no Unix se eu digitar o comando open ("/ etc / password") ? O que verifica o kernel do sistema em meu nome quando eu o ordeno para fazer uma chamada de sistema?

Público-alvo: Verifica se você tem permissão para executar, etc.?

Professor: Sim, até certo ponto, este é o caso. Eu preciso fazer alguma coisa, etc.

Público: e, em seguida, execute a barra especificada!

Professor: sim, na verdade eu preciso olhar para o que / etc aponta? Portanto, se eu não descobrir as permissões de root - direitos, isso não funcionará.

Público: então você precisa ler / etc / password .



Professor: sim, isso faz sentido. Aqui está um pequeno quebra-cabeça para você. Suponha que o MIT crie um grupo para todas as pessoas associadas ao curso 6.858 e outros grupos para todos os ATs no MIT, que na terminologia Unix são designados como gids , mas eles não são incluídos no grupo dos 6.858 ATs por alguns motivos tolos. Como posso criar um arquivo que estará disponível apenas para o grupo de ATs 6.858?

Suponha que eu tenha 6.858 gid e TAs gid, mas só posso inserir um gid no arquivo.

Público: você não seria capaz de fazer isso, porque aqui você pode ter ATs, não 6.858 ATs.

Professor: sim, é verdade. Embora haja alunos do grupo 6.858 que são ATs de outras turmas, talvez isso não seja realmente bom. Mas, no entanto, vamos tentar fazer de alguma forma as interseções desses grupos. Para fazer isso, podemos usar o mecanismo de permissão.
/foo/bar/grades , foo , gid 6.858 . , , /foo . /bar , gid TAs, . /foo/bar/ , grades . , .



: , , , , 6.858 gid, TA - - 6.858 ?

: , . , , , Unix , , , , , . , MACS — mandatory accesscontrol systems, . , , : , . . , - .

Unix , , , TA - , Unix . , - . - , Unix , , . , , . , , , . , . Unix.

, , , , - , . - , , , .

, , Unix.

, — . OKWS , Unix . Unix , . , «» , .

, : , . , . - , , Unix – , , , , .

– Unix - , .

OKWS , . , , , - , . , , , - . - , .

, . , , .

? ? ? Unix . , , – Unix , ptrace .



. , , , , , . , , web , gid TAs, .

, , . userid . ptrace — uid uid .

ptrace Linux . , , , - , , , . - . , ID.

27:50

:

Curso MIT "Segurança de sistemas de computadores". 4: « », 2


.

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?