So Cap08

Sistemas Operacionais VIII - Aspectos de Segurana
Prof. Carlos Alberto Maziero DAInf UTFPR http://dainf.ct.utfpr.edu.br/maziero 18 de novembro de 2011
Copyright (c) 2009 Carlos Alberto Maziero. garantida a permisso para copiar, distribuir e/ou modicar este documento sob os termos da Licena de Documentao Livre GNU (GNU Free Documentation License), Verso 1.2 ou qualquer verso posterior publicada pela Free Software Foundation. A licena est disponvel em http://www.gnu.org/licenses/gfdl.txt.
c prof. Carlos Maziero
SUMRIO 2
Sumrio
1 2 Introduo Conceitos bsicos 2.1 Propriedades e princpios de segurana 2.2 Ameaas . . . . . . . . . . . . . . . . . . 2.3 Vulnerabilidades . . . . . . . . . . . . . 2.4 Ataques . . . . . . . . . . . . . . . . . . . 2.5 Malwares . . . . . . . . . . . . . . . . . . 2.6 Infraestrutura de segurana . . . . . . . Fundamentos de criptograa 3.1 Cifragem e decifragem . . . . . . . 3.2 Criptograa simtrica e assimtrica 3.3 Resumo criptogrco . . . . . . . . 3.4 Assinatura digital . . . . . . . . . . 3.5 Certicado de chave pblica . . . . Autenticao 4.1 Usurios e grupos . . . . . . . . 4.2 Tcnicas de autenticao . . . . 4.3 Senhas . . . . . . . . . . . . . . 4.4 Senhas descartveis . . . . . . . 4.5 Desao-resposta . . . . . . . . . 4.6 Certicados de autenticao . . 4.7 Tcnicas biomtricas . . . . . . 4.8 Kerberos . . . . . . . . . . . . . 4.9 Infra-estruturas de autenticao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4 5 7 7 9 11 12 14 14 15 18 19 20 22 22 23 24 25 26 27 27 28 31 32 33 34 35 36 36 38 39 39 40 41 41 42 43 43 44 46
Controle de acesso 5.1 Polticas, modelos e mecanismos de controle de acesso 5.2 Polticas discricionrias . . . . . . . . . . . . . . . . . . . 5.2.1 Matriz de controle de acesso . . . . . . . . . . . 5.2.2 Tabela de autorizaes . . . . . . . . . . . . . . . 5.2.3 Listas de controle de acesso . . . . . . . . . . . . 5.2.4 Listas de capacidades . . . . . . . . . . . . . . . 5.3 Polticas obrigatrias . . . . . . . . . . . . . . . . . . . . 5.3.1 Modelo de Bell-LaPadula . . . . . . . . . . . . . 5.3.2 Modelo de Biba . . . . . . . . . . . . . . . . . . . 5.3.3 Categorias . . . . . . . . . . . . . . . . . . . . . . 5.4 Polticas baseadas em domnios . . . . . . . . . . . . . . 5.5 Polticas baseadas em papis . . . . . . . . . . . . . . . 5.6 Mecanismos de controle de acesso . . . . . . . . . . . . 5.6.1 Infra-estrutura bsica . . . . . . . . . . . . . . . . 5.6.2 Controle de acesso em UNIX . . . . . . . . . . . 5.6.3 Controle de acesso em Windows . . . . . . . . .
SUMRIO 3
5.7 6
5.6.4 Outros mecanismos . . . . . . . . . . . . . . . . . . . . . . . . . . Mudana de privilgios . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48 49 52 52 54 55
Auditoria 6.1 Coleta de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Anlise de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3 Auditoria preventiva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Introduo 4
Resumo Este mdulo trata dos principais aspectos de segurana envolvidos na construo e utilizao de um sistema operacional. Inicialmente so apresentados conceitos bsicos de segurana e criptograa; em seguida, so descritos aspectos conceituais e mecanismos relacionados autenticao de usurios, controle de acesso a recursos e servios, integridade e privacidade do sistema operacional, das aplicaes e dos dados armazenados. Grande parte dos tpicos de segurana apresentados neste captulo no so exclusivos de sistemas operacionais, mas se aplicam a sistemas de computao em geral.
Introduo
A segurana de um sistema de computao diz respeito garantia de algumas propriedades fundamentais associadas s informaes e recursos presentes nesse sistema. Por informao, compreende-se todos os recursos disponveis no sistema, como registros de bancos de dados, arquivos, reas de memria, portas de entrada/sada, conexes de rede, conguraes, etc. Em Portugus, a palavra segurana abrange muitos signicados distintos e por vezes conitantes. Em Ingls, as palavras security, safety e reliability permitem denir mais precisamente os diversos aspectos da segurana: a palavra security se relaciona a ameaas intencionais, como intruses, ataques e roubo de informaes; a palavra safety se relaciona a problemas que possam ser causados pelo sistema aos seus usurios ou ao ambiente, como erros de programao que possam provocar acidentes; por m, o termo reliability usado para indicar sistemas conveis, construdos para tolerar erros de software, de hardware ou dos usurios [Avizienis et al., 2004]. Neste captulo sero considerados somente os aspectos de segurana relacionados palavra inglesa security, ou seja, a proteo contra ameaas intencionais. Este captulo trata dos principais aspectos de segurana envolvidos na construo e operao de um sistema operacional. A primeira parte do captulo apresentada conceitos bsicos de segurana, como as propriedades e princpios de segurana, ameaas, vulnerabilidades e ataques tpicos em sistemas operacionais, concluindo com uma descrio da infra-estrutura de segurana tpica de um sistema operacional. A seguir, apresentada uma introduo criptograa. Na seqncia, so descritos aspectos conceituais e mecanismos relacionados autenticao de usurios, controle de acesso a recursos e integridade do sistema. Tambm so apresentados os principais conceitos relativos ao registro de dados de operao para ns de auditoria. Grande parte dos tpicos de segurana apresentados neste captulo no so exclusivos de sistemas operacionais, mas se aplicam a sistemas de computao em geral.
Conceitos bsicos
Nesta seo so apresentados alguns conceitos fundamentais, importantes para o estuda da segurana de sistemas computacionais. Em particular, so enumeradas as propriedades que caracterizam a segurana de um sistema, so denidos os principais
Propriedades e princpios de segurana 5
termos em uso na rea, e so apresentados os principais elementos que compe a arquitetura de segurana de um sistema.
2.1
Propriedades e princpios de segurana
A segurana de um sistema de computao pode ser expressa atravs de algumas propriedades fundamentais [Amoroso, 1994]: Condencialidade : os recursos presentes no sistema s podem ser consultados por usurios devidamente autorizados a isso; Integridade : os recursos do sistema s podem ser modicados ou destrudos pelos usurios autorizados a efetuar tais operaes; Disponibilidade : os recursos devem estar disponveis para os usurios que tiverem direito de us-los, a qualquer momento. Alm destas, outras propriedades importantes esto geralmente associadas segurana de um sistema: Autenticidade : todas as entidades do sistema so autnticas ou genunas; em outras palavras, os dados associados a essas entidades so verdadeiros e correspondem s informaes do mundo real que elas representam, como as identidades dos usurios, a origem dos dados de um arquivo, etc.; Irretratabilidade : Todas as aes realizadas no sistema so conhecidas e no podem ser escondidas ou negadas por seus autores; esta propriedade tambm conhecida como irrefutabilidade ou no-repudiao. funo do sistema operacional garantir a manuteno das propriedades de segurana para todos os recursos sob sua responsabilidade. Essas propriedades podem estar sujeitas a violaes decorrentes de erros de software ou humanos, praticadas por indivduos mal-intencionados (maliciosos), internos ou externos ao sistema. Alm das tcnicas usuais de engenharia de software para a produo de sistemas corretos, a construo de sistemas computacionais seguros pautada por uma srie de princpios especcos, relativos tanto construo do sistema quanto ao comportamento dos usurios e dos atacantes. Alguns dos princpios mais relevantes, compilados a partir de [Saltzer and Schroeder, 1975, Lichtenstein, 1997, Peeger and Peeger, 2006], so indicados a seguir: Privilgio mnimo : todos os usurios e programas devem operar com o mnimo possvel de privilgios ou permisses de acesso. Dessa forma, os danos provocados por erros ou aes maliciosas intencionais sero minimizados. Mediao completa : todos os acessos a recursos, tanto diretos quanto indiretos, devem ser vericados pelos mecanismos de segurana. Eles devem estar dispostos de forma a ser impossvel contorn-los.
Propriedades e princpios de segurana 6
Default seguro : o mecanismo de segurana deve identicar claramente os acessos permitidos; caso um certo acesso no seja explicitamente permitido, ele deve ser negado. Este princpio impede que acessos inicialmente no-previstos no projeto do sistema sejam inadvertidamente autorizados. Economia de mecanismo : o projeto de um sistema de proteo deve ser pequeno e simples, para que possa ser facilmente e profundamente analisado, testado e validado. Separao de privilgios : sistemas de proteo baseados em mais de um controle so mais robustos, pois se o atacante conseguir burlar um dos controles, mesmo assim no ter acesso ao recurso. Um exemplo tpico o uso de mais de uma forma de autenticao para acesso ao sistema (como um carto e uma senha, nos sistemas bancrios). Compartilhamento mnimo : mecanismos compartilhados entre usurios so fontes potenciais de problemas de segurana, devido possibilidade de uxos de informao imprevistos entre usurios. Por isso, o uso de mecanismos compartilhados deve ser minimizado, sobretudo se envolver reas de memria compartilhadas. Por exemplo, caso uma certa funcionalidade do sistema operacional possa ser implementada como chamada ao ncleo ou como funo de biblioteca, deve-se preferir esta ltima forma, pois envolve menos compartilhamento. Projeto aberto : a robustez do mecanismo de proteo no deve depender da ignorncia dos atacantes; ao invs disso, o projeto deve ser pblico e aberto, dependendo somente do segredo de poucos itens, como listas de senhas ou chaves criptogrcas. Um projeto aberto tambm torna possvel a avaliao por terceiros independentes, provendo conrmao adicional da segurana do mecanismo. Proteo adequada : cada recurso computacional deve ter um nvel de proteo coerente com seu valor intrnseco. Por exemplo, o nvel de proteo requerido em um servidor Web de servios bancrio bem distinto daquele de um terminal pblico de acesso Internet. Facilidade de uso : o uso dos mecanismos de segurana deve ser fcil e intuitivo, caso contrrio eles sero evitados pelos usurios. Ecincia : os mecanismos de segurana devem ser ecientes no uso dos recursos computacionais, de forma a no afetar signicativamente o desempenho do sistema ou as atividades de seus usurios. Elo mais fraco : a segurana do sistema limitada pela segurana de seu elemento mais vulnervel, seja ele o sistema operacional, as aplicaes, a conexo de rede ou o prprio usurio. Esses princpios devem pautar a construo, congurao e operao de qualquer sistema computacional com requisitos de segurana. A imensa maioria dos problemas de segurana dos sistemas atuais provm da no-observao desses princpios.
Ameaas 7
2.2
Ameaas
Como ameaa, pode ser considerada qualquer ao que coloque em risco as propriedades de segurana do sistema descritas na seo anterior. Alguns exemplos de ameaas s propriedades bsicas de segurana seriam: Ameaas condencialidade: um processo vasculhar as reas de memria de outros processos, arquivos de outros usurios, trfego de rede nas interfaces locais ou reas do ncleo do sistema, buscando dados sensveis como nmeros de carto de crdito, senhas, e-mails privados, etc; Ameaas integridade: um processo alterar as senhas de outros usurios, instalar programas, drivers ou mdulos de ncleo maliciosos, visando obter o controle do sistema, roubar informaes ou impedir o acesso de outros usurios; Ameaas disponibilidade: um usurio alocar para si todos os recursos do sistema, como a memria, o processador ou o espao em disco, para impedir que outros usurios possam utiliz-lo. Obviamente, para cada ameaa possvel, devem existir estruturas no sistema operacional que impeam sua ocorrncia, como controles de acesso s reas de memria e arquivos, quotas de uso de memria e processador, vericao de autenticidade de drivers e outros softwares, etc. As ameaas podem ou no se concretizar, dependendo da existncia e da correo dos mecanismos construdos para evit-las ou impedi-las. As ameaas podem se tornar realidade medida em que existam vulnerabilidades que permitam sua ocorrncia.
2.3
Vulnerabilidades
Uma vulnerabilidade um defeito ou problema presente na especicao, implementao, congurao ou operao de um software ou sistema, que possa ser explorado para violar as propriedades de segurana do mesmo. Alguns exemplos de vulnerabilidades so descritos a seguir: um erro de programao no servio de compartilhamento de arquivos, que permita a usurios externos o acesso a outros arquivos do computador local, alm daqueles compartilhados; uma conta de usurio sem senha, ou com uma senha pr-denida pelo fabricante, que permita a usurios no-autorizados acessar o sistema; ausncia de quotas de disco, permitindo a um nico usurio alocar todo o espao em disco para si e assim impedir os demais usurios de usar o sistema. A grande maioria das vulnerabilidades ocorre devido a erros de programao, como, por exemplo, no vericar a conformidade dos dados recebidos de um usurio ou da rede. Em um exemplo clssico, o processo servidor de impresso lpd, usado em alguns UNIX, pode ser instrudo a imprimir um arquivo e a seguir apag-lo, o que til para imprimir arquivos temporrios. Esse processo executa com permisses administrativas pois
Vulnerabilidades 8
precisa acessar a porta de entrada/sada da impressora, o que lhe confere acesso a todos os arquivos do sistema. Por um erro de programao, uma verso antiga do processo lpd no vericava corretamente as permisses do usurio sobre o arquivo a imprimir; assim, um usurio malicioso podia pedir a impresso (e o apagamento) de arquivos do sistema. Em outro exemplo clssico, uma verso antiga do servidor HTTP Microsoft IIS no vericava adequadamente os pedidos dos clientes; por exemplo, um cliente que solicitasse a URL http://www.servidor.com/../../../../windows/system.ini, receberia como resultado o contedo do arquivo de sistema system.ini, ao invs de ter seu pedido recusado. Uma classe especial de vulnerabilidades decorrentes de erros de programao so os chamados estouros de buer e de pilha (buer/stack overows). Nesse erro, o programa escreve em reas de memria indevidamente, com resultados imprevisveis, como mostra o exemplo a seguir e o resultado de sua execuo:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
#include <stdio.h> #include <stdlib.h> int i, j, buffer[20], k; // declara buffer[0] a buffer[19] int main() { i = j = k = 0 ; for (i = 0; i<= 20; i++) // usa buffer[0] a buffer[20] <-- erro! buffer[i] = random() ; printf ("i: %d\nj: %d\nk: %d\n", i, j, k) ; return(0); }
A execuo desse cdigo gera o seguinte resultado:

1 2 3 4 5
host:~> cc buffer-overflow.c -o buffer-overflow host:~> buffer-overflow i: 21 j: 35005211 k: 0
Pode-se observar que os valores i = 21 e k = 0 so os previstos, mas o valor da varivel j mudou misteriosamente de 0 para 35005211. Isso ocorreu porque, ao acessar a posio buffer[20], o programa extrapolou o tamanho do vetor e escreveu na rea de memria sucessiva1 , que pertence varivel j. Esse tipo de erro muito frequente em linguagens como C e C++, que no vericam os limites de alocao das variveis durante a execuo. O erro de estouro de pilha similar a este, mas envolve variveis alocadas na pilha usada para o controle de execuo de funes.
As variveis no so alocadas na memria necessariamente na ordem em que so declaradas no cdigo-fonte. A ordem de alocao das variveis varia com o compilador usado e depende de vrios fatores, como a arquitetura do processador, estratgias de otimizao de cdigo, etc.
1
Ataques 9
Se a rea de memria invadida pelo estouro de buer contiver cdigo executvel, o processo pode ter erros de execuo e ser abortado. A pior situao ocorre quando os dados a escrever no buer so lidos do terminal ou recebidos atravs da rede: caso o atacante conhea a organizao da memria do processo, ele pode escrever inserir instrues executveis na rea de memria invadida, mudando o comportamento do processo ou abortando-o. Caso o buer esteja dentro do ncleo, o que ocorre em drivers e no suporte a protocolos de rede como o TCP/IP, um estouro de buer pode travar o sistema ou permitir acessos indevidos a recursos. Um bom exemplo o famoso Ping of Death [Peeger and Peeger, 2006], no qual um pacote de rede no protocolo ICMP, com um contedo especco, podia paralisar computadores na rede local. Alm dos estouros de buer e pilha, h uma srie de outros erros de programao e de congurao que podem constituir vulnerabilidades, como o uso descuidado das strings de formatao de operaes de entrada/sada em linguagens como C e C++ e condies de disputa na manipulao de arquivos compartilhados. Uma explicao mais detalhada desses erros e de suas implicaes pode ser encontrada em [Peeger and Peeger, 2006].
2.4
Ataques
Um ataque o ato de utilizar (ou explorar) uma vulnerabilidade para violar uma propriedade de segurana do sistema. De acordo com [Peeger and Peeger, 2006], existem basicamente quatro tipos de ataques, representados na gura 1: Interrupo : consiste em impedir o uxo normal das informaes ou acessos; um ataque disponibilidade do sistema; Interceptao : consiste em obter acesso indevido a um uxo de informaes, sem necessariamente modic-las; um ataque condencialidade; Modicao : consiste em modicar de forma indevida informaes ou partes do sistema, violando sua integridade; Fabricao : consiste em produzir informaes falsas ou introduzir mdulos ou componentes maliciosos no sistema; um ataque autenticidade. Existem ataques passivos, que visam capturar informaes condenciais, e ataques ativos, que visam introduzir modicaes no sistema para beneciar o atacante ou impedir seu uso pelos usurios vlidos. Alm disso, os ataques a um sistema operacional podem ser locais, quando executados por usurios vlidos do sistema, ou remotos, quando so realizados atravs da rede, sem fazer uso de uma conta de usurio local. Um programa especialmente construdo para explorar uma determinada vulnerabilidade de sistema e realizar um ataque denominado exploit. A maioria dos ataques a sistemas operacionais visa aumentar o poder do atacante dentro do sistema, o que denominado elevao de privilgios (privilege escalation). Esses ataques geralmente exploram vulnerabilidades em programas do sistema (que executam com mais privilgios), ou do prprio ncleo, atravs de chamadas de sistema, para receber os privilgios do administrador. Por outro lado, os ataques de negao de servios (DoS Denial of Service) visam prejudicar a disponibilidade do sistema, impedindo que os usurios vlidos do sistema
Ataques 10
interrupo
interceptao
fonte atacante
destino
fonte atacante
destino
modificao
fabricao
fonte atacante
destino
fonte atacante
destino
Figura 1: Tipos bsicos de ataques (inspirado em [Peeger and Peeger, 2006]). possam utiliz-lo, ou seja, que o sistema execute suas funes. Esse tipo de ataque muito comum em ambientes de rede, com a inteno de impedir o acesso a servidores Web, DNS e de e-mail. Em um sistema operacional, ataques de negao de servio podem ser feitos com o objetivo de consumir todos os recursos locais, como processador, memria, arquivos abertos, sockets de rede ou semforos, dicultando ou mesmo impedindo o uso desses recursos pelos demais usurios. O antigo ataque fork bomb dos sistemas UNIX um exemplo trivial de ataque DoS local: ao executar, o processo atacante se reproduz rapidamente, usando a chamada de sistema fork (vide cdigo a seguir). Cada processo lho continua executando o mesmo cdigo do processo pai, criando novos processos lhos, e assim sucessivamente. Em conseqncia, a tabela de processos do sistema rapidamente preenchida, impedindo a criao de processos pelos demais usurios. Alm disso, o grande nmero de processos solicitando chamadas de sistema mantm o ncleo ocupado, impedindo os a execuo dos demais processos.
1 2 3 4 5 6 7
#include <unistd.h> int main() { while (1) fork() ; }
// lao infinito // reproduz o processo
Ataques similares ao fork bomb podem ser construdos para outros recursos do sistema operacional, como memria, descritores de arquivos abertos, sockets de rede e espao em disco. Cabe ao sistema operacional impor limites mximos (quotas) de uso
Malwares 11
de recursos para cada usurio e denir mecanismos para detectar e conter processos excessivamente gulosos. Recentemente tm ganho ateno os ataques condencialidade, que visam roubar informaes sigilosas dos usurios. Com o aumento do uso da Internet para operaes nanceiras, como acesso a sistemas bancrios e servios de compras online, o sistema operacional e os navegadores manipulam informaes sensveis, como nmeros de cartes de crdito, senhas de acesso a contas bancrias e outras informaes pessoais. Programas construdos com a nalidade especca de realizar esse tipo de ataque so denominados spyware. Deve car clara a distino entre ataques e incidentes de segurana. Um incidente de segurana qualquer fato intencional ou acidental que comprometa uma das propriedades de segurana do sistema. A intruso de um sistema ou um ataque de negao de servios so considerados incidentes de segurana, assim como o vazamento acidental de informaes condenciais.
2.5
Malwares
Denomina-se genericamente malware todo programa cuja inteno realizar atividades ilcitas, como realizar ataques, roubar informaes ou dissimular a presena de intrusos em um sistema. Existe uma grande diversidade de malwares, destinados s mais diversas nalidades [Shirey, 2000, Peeger and Peeger, 2006], como: Vrus : um vrus de computador um trecho de cdigo que se inltra em programas executveis existentes no sistema operacional, usando-os como suporte para sua execuo e replicao2 . Quando um programa infectado executado, o vrus tambm se executa, infectando outros executveis e eventualmente executando outras aes danosas. Alguns tipos de vrus so programados usando macros de aplicaes complexas, como editores de texto, e usam os arquivos de dados dessas aplicaes como suporte. Outros tipos de vrus usam o cdigo de inicializao dos discos e outras mdias como suporte de execuo. Worm : ao contrrio de um vrus, um verme um programa autnomo, que se propaga sem infectar outros programas. A maioria dos vermes se propaga explorando vulnerabilidades nos servios de rede, que os permitam invadir e instalar-se em sistemas remotos. Alguns vermes usam o sistema de e-mail como vetor de propagao, enquanto outros usam mecanismos de auto-execuo de mdias removveis (como pendrives) como mecanismo de propagao. Uma vez instalado em um sistema, o verme pode instalar spywares ou outros programas nocivos. Trojan horse : de forma anloga ao personagem da mitologia grega, um cavalo de Tria computacional um programa com duas funcionalidades: uma funcionalidade lcita conhecida de seu usurio e outra ilcita, executada sem que o usurio a perceba. Muitos cavalos de Tria so usados como vetores para a instalao de outros malwares. Um exemplo clssico o famoso Happy New Year 99, distribudo
De forma anloga, um vrus biolgico precisa de uma clula hospedeira, pois usa o material celular como suporte para sua existncia e replicao.
2
Infraestrutura de segurana 12
atravs de e-mails, que usava uma animao de fogos de artifcio como fachada para a propagao de um verme. Para convencer o usurio a executar o cavalo de Tria podem ser usadas tcnicas de engenharia social [Mitnick and Simon, 2002]. Exploit : um programa escrito para explorar vulnerabilidades conhecidas, como prova de conceito ou como parte de um ataque. Os exploits podem estar incorporados a outros malwares (como vermes e trojans) ou constiturem ferramentas autnomas, usadas em ataques manuais. Packet snier : um farejador de pacotes captura pacotes de rede do prprio computador ou da rede local, analisando-os em busca de informaes sensveis como senhas e dados bancrios. A criptograa (Seo 3) resolve parcialmente esse problema, embora um snier na mquina local possa capturar os dados antes que sejam cifrados, ou depois de decifrados. Keylogger : software dedicado a capturar e analisar as informaes digitadas pelo usurio na mquina local, sem seu conhecimento. Essas informaes podem ser transferidas a um computador remoto periodicamente ou em tempo real, atravs da rede. Rootkit : um conjunto de programas destinado a ocultar a presena de um intruso no sistema operacional. Como princpio de funcionamento, o rootkit modica os mecanismos do sistema operacional que mostram os processos em execuo, arquivos nos discos, portas e conexes de rede, etc, para ocultar o intruso. Os rootkits mais simples substituem utilitrios do sistema, como ps (lista de processos), ls (arquivos), netstat (conexes de rede) e outros, por verses adulteradas que no mostrem os arquivos, processos e conexes de rede do intruso. Verses mais elaboradas de rootkits substituem bibliotecas do sistema operacional ou modicam partes do prprio ncleo, o que torna complexa sua deteco e remoo. Backdoor : uma porta dos fundos um programa que facilita a entrada posterior do atacante em um sistema j invadido. Geralmente a porta dos fundos criada atravs um processo servidor de conexes remotas (usando SSH, telnet ou um protocolo ad-hoc). Muitos backdoors so instalados a partir de trojans, vermes ou rootkits. Deve-se ter em mente que h na mdia e na literatura muita confuso em relao nomenclatura de malwares; alm disso, muitos malwares tm vrias funcionalidades e se encaixam em mais de uma categoria. Esta seo teve como objetivo dar uma denio tecnicamente precisa de cada categoria, sem a preocupao de mapear os exemplos reais nessas categorias.
2.6
Infraestrutura de segurana
De forma genrica, o conjunto de todos os elementos de hardware e software considerados crticos para a segurana de um sistema so denominados Base Computacional Convel (TCB Trusted Computing Base) ou ncleo de segurana (security kernel). Fazem parte da TCB todos os elementos do sistema cuja falha possa representar um
Infraestrutura de segurana 13
risco sua segurana. Os elementos tpicos de uma base de computao convel incluem os mecanismos de proteo do hardware (tabelas de pginas/segmentos, modo usurio/ncleo do processador, instrues privilegiadas, etc.) e os diversos subsistemas do sistema operacional que visam garantir as propriedades bsicas de segurana, como o controle de acesso aos arquivos, acesso s portas de rede, etc. O sistema operacional emprega vrias tcnicas complementares para garantir a segurana de um sistema operacional. Essas tcnicas esto classicadas nas seguintes grandes reas: Autenticao : conjunto de tcnicas usadas para identicar inequivocamente usurios e recursos em um sistema; podem ir de simples pares login/senha at esquemas sosticados de biometria ou certicados criptogrcos. No processo bsico de autenticao, um usurio externo se identica para o sistema atravs de um procedimento de autenticao; no caso da autenticao ser bem sucedida, aberta uma sesso, na qual so criados uma ou mais entidades (processos, threads, transaes, etc.) para representar aquele usurio dentro do sistema. Controle de acesso : tcnicas usadas para denir quais aes so permitidas e quais so negadas no sistema; para cada usurio do sistema, devem ser denidas regras descrevendo as aes que este pode realizar no sistema, ou seja, que recursos este pode acessar e sob que condies. Normalmente, essas regras so denidas atravs de uma poltica de controle de acesso, que imposta a todos os acessos que os usurios efetuam sobre os recursos do sistema. Auditoria : tcnicas usadas para manter um registro das atividades efetuadas no sistema, visando a contabilizao de uso dos recursos, a anlise posterior de situaes de uso indevido ou a identicao de comportamento suspeitos. A gura 2 ilustra alguns dos conceitos vistos at agora. Nessa gura, as partes indicadas em cinza e os mecanismos utilizados para implement-las constituem a base de computao convel do sistema. Sob uma tica mais ampla, a base de computao convel de um sistema informtico compreende muitos fatores alm do sistema operacional em si. A manuteno das propriedades de segurana depende do funcionamento correto de todos os elementos do sistema, do hardware ao usurio nal. O hardware fornece vrias funcionalidades essenciais para a proteo do sistema: os mecanismos de memria virtual permitem isolar o ncleo e os processos entre si; o mecanismo de interrupo de software prov uma interface controlada de acesso ao ncleo; os nveis de execuo do processador permitem restringir as instrues e as portas de entrada sada acessveis aos diversos softwares que compem o sistema; alm disso, muitos tipos de hardware permitem impedir operaes de escrita ou execuo de cdigo em certas reas de memria. No nvel do sistema operacional surgem os processos isolados entre si, os as contas de usurios, os mecanismos de autenticao e controle de acesso e os registros de auditoria. Em paralelo com o sistema operacional esto os utilitrios de segurana, como anti-vrus, vericadores de integridade, detectores de intruso, entre outros. As linguagens de programao tambm desempenham um papel importante nesse contexto, pois muitos problemas de segurana tm origem em erros de programao.
Fundamentos de criptograa 14
Illenihild ubitatquin ullamscientiam habet(Nadaduvi daquemnadasabe )Illenihildubi tatquinullamsc ientiamhabet(N adaduvidaquemn adasabe)Illeni hildubitatquin ullamscientiam habet(Nadaduvi
auditoria
auditoria
dados de auditoria
evento
evento
arquivos
humanos
autenticao
processos threads transaes
controle de acesso
outros sujeitos ou sistemas
sistemas externos
dados de autenticao
polticas de controle de acesso
registros
usurios
autenticao
controle de acesso
recursos
Figura 2: Base de computao convel de um sistema operacional. O controle estrito de ndices em vetores, o uso restrito de ponteiros e a limitao de escopo de nomes para variveis e funes so exemplos de aspectos importantes para a segurana de um programa. Por m, as aplicaes tambm tm responsabilidade em relao segurana, no sentido de ter implementaes corretas e validar todos os dados manipulados. Isso particularmente importante em aplicaes multi-usurios (como sistemas corporativos e sistemas Web) e processos privilegiados que recebam requisies de usurios ou da rede (servidores de impresso, de DNS, etc).
Fundamentos de criptograa
As tcnicas criptogrcas so extensivamente usadas na segurana de sistemas, para garantir a condencialidade e integridade dos dados. Alm disso, elas desempenham um papel importante na autenticao de usurios e recursos. O termo criptograa provm das palavras gregas kryptos (oculto, secreto) e graphos (escrever). Assim, a criptograa foi criada para codicar informaes, de forma que somente as pessoas autorizadas pudessem ter acesso ao seu contedo. Alguns conceitos fundamentais para compreender as tcnicas criptogrcas so: o texto aberto, que a mensagem ou informao a ocultar; o texto cifrado, que a informao codicada; o cifrador, mecanismo responsvel por cifrar/decifrar as informaes, e as chaves, necessrias para poder cifrar ou decifrar as informaes [Menezes et al., 1996].
3.1
Cifragem e decifragem
Uma das mais antigas tcnicas criptogrcas conhecidas o cifrador de Csar, usado pelo imperador romano Jlio Csar para se comunicar com seus generais. O algoritmo
Criptograa simtrica e assimtrica 15
usado nesse cifrador bem simples: cada caractere do texto aberto substitudo pelo k-simo caractere sucessivo no alfabeto. Assim, considerando k = 2, a letra A seria substituda pela letra C, a letra R pela T, e assim por diante. Usando esse algoritmo, a mensagem secreta Reunir todos os generais para o ataque seria cifrada da seguinte forma: mensagem aberta: mensagem cifrada com k = 1: mensagem cifrada com k = 2: mensagem cifrada com k = 3: Reunir Sfvojs Tgwpkt Uhxqlu todos upept vqfqu wrgrv os pt qu rv generais hfofsbjt igpgtcku jhqhudlv para qbsb rctc sdud o p q r ataque bubrvf cvcswg dwdtxh
Para decifrar uma mensagem no cifrador de Csar, necessrio conhecer a mensagem cifrada e o valor de k utilizado para cifrar a mensagem, que denominado chave criptogrca. Caso essa chave no seja conhecida, possvel tentar quebrar a mensagem cifrada testando todas as chaves possveis, o que conhecido como anlise exaustiva ou de fora bruta. No caso do cifrador de Csar a anlise exaustiva trivial, pois h somente 26 valores possveis para a chave k. O nmero de chaves possveis para um algoritmo de cifragem conhecido como o seu espao de chaves. De acordo com princpios enunciados pelo criptgrafo Auguste Kerckhos em 1883, o segredo de uma tcnica criptogrca no deve residir no algoritmo em si, mas no espao de chaves que ele prov. Seguindo esses princpios, a criptograa moderna se baseia em algoritmos pblicos, bem avaliados pela comunidade cientca, para os quais o espao de chaves muito grande, tornando invivel qualquer anlise exaustiva. Por exemplo, o algoritmo de criptograa AES (Advanced Encryption Standard) adotado como padro pelo governo americano, usando chaves de 128 bits, oferece um espao de chaves com 2128 possibilidades, ou seja, 340.282.366.920.938.463.463.374.607.431.768.211.456 chaves diferentes... Se pudssemos analisar um bilho de chaves por segundo, ainda assim seriam necessrios 10 sextilhes de anos para testar todas as chaves possveis! No restante do texto, a operao de cifragem de um contedo x usando uma chave k ser representada por {x}k e a decifragem de um contedo x usando uma chave k ser representada por {x}1 . k
3.2
Criptograa simtrica e assimtrica
De acordo com o tipo de chave utilizada, os algoritmos de criptograa se dividem em dois grandes grupos: algoritmos simtricos e algoritmos assimtricos. Nos algoritmos simtricos, a mesma chave k usada para cifrar a informao deve ser usada para decifr-la. Essa propriedade pode ser expressa em termos matemticos: { { x }k }1 = x k = k k O cifrador de Csar um exemplo tpico de cifrador simtrico: se usarmos k = 2 para cifrar um texto, teremos de usar k = 2 para decifr-lo. Os algoritmos simtricos mais conhecidos e usados atualmente so o DES (Data Encryption Standard) e o AES (Advanced Encryption Standard).
Os algoritmos simtricos so muito teis para a cifragem de dados em um sistema local, como documentos ou arquivos em um disco rgido. Todavia, se a informao cifrada tiver de ser enviada a outro usurio, a chave criptogrca usada ter de ser informada a ele de alguma forma segura (de forma a preservar seu segredo). A gura 3 ilustra o funcionamento bsico de um sistema de criptograa simtrica.
texto aberto
Ille nihil dubitat qui nullam scientiam habet (Nada duvida quem nada sabe)
texto aberto
texto cifrado
6d034072696a6e6461656c2d31 3238002000636263006d63727970 742d7368613100157290d14234f6 fce39f0908827c54cdf58890687f 7368613100ff56dfb2015aae6f33 86a6acbd051a33562699a2d97623 ca974d8cc5d986b6c48fba534eab 2eb4d39273910b72c869c54521c1 c5df85cb3a37d2aaa6f19b560ead a9eb92c5e8e95
cifrar
decifrar
chave secreta
a chave secreta transferida atravs de um meio seguro
chave secreta
Figura 3: Criptograa simtrica. Por outro lado, os algoritmos assimtricos se caracterizam pelo uso de um par de chaves complementares: uma chave pblica kp e uma chave privada kv. Uma informao cifrada com uso de uma chave pblica s poder ser decifrada atravs da chave privada correspondente, e vice-versa. Considerando um usurio u com suas chaves pblica kp(u) e privada kv(u), temos: { { x }kp(u) }1 = x k = kv(u) k { { x }kv(u) }1 = x k = kp(u) k Essas duas chaves esto fortemente relacionadas: para cada chave pblica h uma nica chave privada correspondente, e vice-versa. Todavia, no possvel calcular uma das chaves a partir da outra. Como o prprio nome diz, geralmente as chaves pblicas so amplamente conhecidas e divulgadas (por exemplo, em uma pgina Web ou um repositrio de chaves pblicas), enquanto as chaves privadas correspondentes so mantidas em segredo por seus proprietrios. Alguns algoritmos assimtricos bem conhecidos so o RSA (Rivest-Shamir-Adleman) e o algoritmo de Die-Hellman. A gura 4 ilustra o funcionamento da criptograa assimtrica.

texto aberto

texto aberto
texto cifrado
cifrar
decifrar
chave pblica
chave privada
Figura 4: Criptograa assimtrica. Um exemplo de uso da criptograa assimtrica mostrado na gura 5. Nele, a usuria Alice deseja enviar um documento cifrado ao usurio Beto3 . Para tal, Alice busca a chave pblica de Beto previamente divulgada em um chaveiro pblico (que pode ser um servidor Web, por exemplo) e a usa para cifrar o documento que ser enviado a Beto. Somente Beto poder decifrar esse documento, pois s ele possui a chave privada correspondente chave pblica usada para cifr-lo. Outros usurios podero at ter acesso ao documento cifrado, mas no conseguiro decifr-lo. A criptograa assimtrica tambm pode ser usada para identicar a autoria de um documento. Por exemplo, se Alice criar um documento e cifr-lo com sua chave privada, qualquer usurio que tiver acesso ao documento poder decifr-lo e l-lo, pois a chave pblica de Alice est publicamente acessvel. Todavia, o fato do documento poder ser decifrado usando a chave pblica de Alice signica que ela a autora legtima do mesmo, pois s ela teria acesso chave privada que foi usada para cifr-lo. Esse mecanismo usado na criao das assinaturas digitais (Seo 3.4). Embora mais versteis, os algoritmos de cifragem assimtricos costumam exigir muito mais processamento que os algoritmos simtricos equivalentes. Por isso, muitas vezes ambos so usados em associao. Por exemplo, os protocolos de rede seguros baseados em TLS (Transport Layer Security), como o SSH e HTTPS, usam criptograa assimtrica somente durante o incio de cada conexo, para negociar uma chave simtrica comum entre os dois computadores que se comunicam. Essa chave simtrica, chamada chave de sesso, ento usada para cifrar/decifrar os dados trocados entre os dois computadores durante aquela conexo, sendo descartada quando a sesso encerra.
Textos em ingls habitualmente usam os nomes Alice, Bob, Carol e Dave para explicar algoritmos e protocolos criptogrcos, em substituio s letras A, B, C e D. Neste texto usaremos a mesma abordagem, mas com nomes em portugus.
3

Alice
Resumo criptogrco 18
texto cifrado
Beto
texto aberto
texto aberto
3: cifrar
4: envio do texto cifrado
5: decifrar
chave pblica chave privada
2: Alice obtm a chave pblica de Beto
Chaveiro pblico
1: Beto divulga sua chave pblica
Alice
Beto Carol Davi
Figura 5: Exemplo de uso da criptograa assimtrica.
3.3
Resumo criptogrco
Um resumo criptogrco (cryptographic hash) [Menezes et al., 1996] uma funo que gera uma sequncia de bytes de tamanho pequeno e xo (algumas dezenas ou centenas de bytes) a partir de um conjunto de dados de tamanho varivel aplicado como entrada. Os resumos criptogrcos so frequentemente usados para identicar unicamente um arquivo ou outra informao digital, ou para atestar sua integridade: caso o contedo de um documento digital seja modicado, seu resumo tambm ser alterado. Em termos matemticos, os resumos criptogrcos so um tipo de funo unidirecional (one-way function). Uma funo f (x) chamada unidirecional quando seu clculo direto (y = f (x)) simples, mas o clculo de sua inversa (x = f 1 (y)) impossvel ou invivel em termos computacionais. Um exemplo clssico de funo unidirecional a fatorao do produto de dois nmeros primos grandes: considere a funo f (p, q) = p q, onde p e q so inteiros primos. Calcular y = f (p, q) simples e rpido, mesmo se p e q forem grandes; entretanto, fatorizar y para obter de volta os primos p e q pode ser computacionalmente invivel, se y tiver muitos dgitos4 . Idealmente, uma funo de resumo criptogrco deve gerar sempre a mesma sada para a mesma entrada, e sadas diferentes para entradas diferentes. No entanto, como o nmero de bytes do resumo pequeno, podem ocorrer colises. Uma coliso ocorre quando duas entradas distintas x e x geram o mesmo valor de resumo (hash(x) = hash(x ) para x x ). Obviamente, bons algoritmos de resumo buscam minimizar essa possibilidade. Outras propriedades desejveis dos resumos criptogrcos so o espalhamento, em que uma modicao em um trecho especco dos dados de entrada
Em 2005, um grupo de pesquisadores alemes fatorizou um inteiro com 200 dgitos, usando 80 processadores Opteron calculando durante mais de de cinco meses.
4
Assinatura digital 19
gera modicaes em partes diversas do resumo, e a sensibilidade, em que uma pequena modicao nos dados de entrada pode gerar grandes mudanas no resumo. Os algoritmos de resumo criptogrco mais conhecidos e utilizados atualmente so o MD5 e o SHA1 [Menezes et al., 1996]. No Linux, os comandos md5sum e sha1sum permitem calcular respectivamente os resumos MD5 e SHA1 de arquivos comuns:
1 2 3 4 5 6 7 8 9 10 11
maziero:~> md5sum * 62ec3f9ff87f4409925a582120a40131 0920785a312bd88668930f761de740bf 45acbba4b57317f3395c011fbd43d68d 6c332adb037265a2019077e09a024d0c
header.tex main.pdf main.tex main.tex~
maziero:~> sha1sum * 742c437692369ace4bf0661a8fe5741f03ecb31a 9f9f52f48b75fd2f12fa297bdd5e1b13769a3139 d6973a71e5c30d0c05d762e9bc26bb073d377a0b cf1670f22910da3b9abf06821e44b4ad7efb5460
header.tex main.pdf main.tex main.tex~
3.4
Assinatura digital
Os mecanismos de criptograa assimtrica e resumos criptogrcos previamente apresentados permitem efetuar a assinatura digital de documentos eletrnicos. A assinatura digital uma forma de vericar a autoria e integridade de um documento, sendo por isso o mecanismo bsico utilizado na construo dos certicados digitais, amplamente empregados para a autenticao de servidores na Internet. Em termos gerais, a assinatura digital de um documento um resumo digital do mesmo, cifrado usando a chave privada de seu autor (ou de quem o est assinando). Sendo um documento d emitido pelo usurio u, sua assinatura digital s(d, u) denida por s(d, u) = {hash(d)}kv(u) onde hash(x) uma funo de resumo criptogrco conhecida, {x}k indica a cifragem de x usando uma chave k e kv(u) a chave privada do usurio u. Para vericar a validade da assinatura, basta calcular novamente o resumo r = hash(d) e compar-lo com o resumo obtido da assinatura, decifrada usando a chave pblica de u (r = {s}1 ). Se ambos kp(u) forem iguais (r = r ), o documento foi realmente assinado por u e est ntegro, ou seja, no foi modicado desde que u o assinou [Menezes et al., 1996]. A gura 6 ilustra o processo de assinatura digital e vericao de um documento. Os passos do processo so: 1. Alice divulga sua chave pblica kpa em um repositrio acessvel publicamente; 2. Alice calcula o resumo digital r do documento d a ser assinado; 3. Alice cifra o resumo r usando sua chave privada kva , obtendo uma assinatura digital s; 4. A assinatura s e o documento original d, em conjunto, constituem o documento assinado por Alice: [d, s];
Certicado de chave pblica 20
5. Beto obtm o documento assinado por Alice ([d , s ], com d = d e s = s se ambos estiverem ntegros); 6. Beto recalcula o resumo digital r = hash(d ) do documento, usando o mesmo algoritmo empregado por Alice; 7. Beto obtm a chave pblica kpa de Alice e a usa para decifrar a assinatura s do documento, obtendo um resumo r (r = r se s foi realmente cifrado com a chave kva e se s = s) ; 8. Beto compara o resumo r do documento com o resumo r obtido da assinatura digital; se ambos forem iguais (r = r ), o documento foi assinado por Alice e est ntegro, assim como sua assinatura.
4 2
Ille nihil dubitat qui nullam scientiam habet (Nada duvida quem nada sabe) 3423a2e67ba6fc 5b432c2d9f0588 4aef7f7362a74d
d'
hash
5
6fce39f0908827 ca54cdf5889068 7f734aef674d2a
r'
hash
resumo
documento assinado por Alice

r s s'
r'=r'' ?
sim
assinatura vlida
r''
cifrar Alice Chaveiro pblico decifrar 7
chave privada chave pblica 1
chave pblica de Alice

Alice Beto Carol Davi
Figura 6: Assinatura e vericao de uma assinatura digital.
3.5
Certicado de chave pblica
A identicao convel do proprietrio de uma chave pblica fundamental para o funcionamento correto das tcnicas de criptograa assimtrica e de assinatura digital. Uma chave pblica composta por uma mera seqncia de bytes que no permite a identicao direta de seu proprietrio. Por isso, torna-se necessria uma estrutura complementar para fazer essa identicao. A associao entre chaves pblicas e seus respectivos proprietrios realizada atravs dos certicados digitais. Um certicado digital um documento digital assinado, composto das seguintes partes [Menezes et al., 1996]:
Certicado de chave pblica 21
A chave pblica do proprietrio do certicado; Identidade do proprietrio do certicado (nome, endereo, e-mail, URL, nmero IP e/ou outras informaes que permitam identic-lo unicamente)5 ; Outras informaes, como perodo de validade do certicado, algoritmos de criptograa e resumos preferidos ou suportados, etc.; Uma ou mais assinaturas digitais do contedo, emitidas por entidades consideradas conveis pelos usurios dos certicados. Dessa forma, um certicado digital amarra uma identidade a uma chave pblica. Para vericar a validade de um certicado, basta usar as chaves pblicas das entidades que o assinaram. Existem vrios tipos de certicados digitais com seus formatos e contedos prprios, sendo os certicados PGP e X.509 aqueles mais difundidos [Mollin, 2000]. Todo certicado deve ser assinado por alguma entidade considerada convel pelos usurios do sistema. Essas entidades so normalmente denominadas Autoridades Certicadoras (AC ou CA Certication Authorities). Como as chaves pblicas das ACs devem ser usadas para vericar a validade de um certicado, surge um problema: como garantir que uma chave pblica realmente pertence a uma dada autoridade certicadora? A soluo simples: basta criar um certicado para essa AC, assinado por outra AC ainda mais convel. Dessa forma, pode-se construir uma estrutura hierrquica de certicao, na qual a AC de ordem mais elevada (denominada AC raiz) assina os certicados de outras ACs, e assim sucessivamente, at chegar aos certicados dos usurios e demais entidades do sistema. Uma estrutura de certicao se chama Infra-estrutura de Chaves Pblicas (ICP ou PKI - Public-Key Infrastructure). Em uma ICP convencional (hierrquica), a chave pblica da AC raiz deve ser conhecida de todos e considerada ntegra [Mollin, 2000].
Deve-se ressaltar que um certicado pode pertencer a um usurio humano, a um sistema computacional ou qualquer mdulo de software que precise ser identicado de forma inequvoca.
Autenticao 22
chave pblica AC raiz

dfh kds ks
identificao
d lk
s lj k l s
d
lsd jsfhd
29-05-2009
k
assinatura
ACs secundrias
dfh kds ks
lk
d s lj k l s
d
lsd jsfhd
29-05-2009
k
dfh kds ks
dfh kds ks
dfh kds ks
Figura 7: Infra-estrutura de chaves pblicas hierrquica.
Autenticao
O objetivo da autenticao consiste em identicar as diversas entidades de um sistema computacional. Atravs da autenticao, o usurio interessado em acessar o sistema comprova que ele/a realmente quem arma ser. Para tal podem ser usadas vrias tcnicas, sendo as mais relevantes apresentadas nesta seo. Inicialmente, a autenticao visava apenas identicar usurios, para garantir que somente usurios devidamente credenciados teriam acesso ao sistema. Atualmente, em muitas circunstncias tambm necessrio o oposto, ou seja, identicar o sistema para o usurio, ou mesmo sistemas entre si. Por exemplo, quando um usurio acessa um servio bancrio via Internet, deseja ter certeza de que o sistema acessado realmente aquele do banco desejado, e no um sistema falso, construdo para roubar seus dados bancrios. Outro exemplo ocorre durante a instalao de componentes de software como drivers: o sistema operacional deve assegurar-se que o software a ser instalado provm de uma fonte convel e no foi corrompido por algum contedo malicioso.
4.1
Usurios e grupos
A autenticao geralmente o primeiro passo no acesso de um usurio a um sistema computacional. Caso a autenticao do usurio tenha sucesso, so criados processos para represent-lo dentro do sistema. Esses processos interagem com o usurio atravs
d sk
f dsjh
29-05-2009
k
d sk
f dsjh
29-05-2009
k
29-05-2009
dfh kds ks
lk
dfh kds ks
lk
d s lj k l s
d
lsd jsfhd
d s lj k l s
d
lsd jsfhd
lk
d s lj k l s
d
lsd jsfhd
d sk
f dsjh
d sk
f dsjh
d sk
lk
d s lj k l s
d
lsd jsfhd
29-05-2009
f dsjh
d sk
f dsjh
d sk
lk
d s lj k l s
d
lsd jsfhd
29-05-2009
f dsjh
Tcnicas de autenticao 23
da interface e executam as aes desejadas por ele dentro do sistema, ou seja, agem em nome do usurio. A presena de um ou mais processos agindo em nome de um usurio dentro do sistema denominada uma sesso de usurio (user session ou working session). A sesso de usurio inicia imediatamente aps a autenticao do usurio (login ou logon) e termina quando seu ltimo processo encerrado, na desconexo (logout ou logo ). Um sistema operacional servidor ou desktop tpico suporta vrias sesses de usurios simultaneamente. A m de permitir a implementao das tcnicas de controle de acesso e auditoria, cada processo deve ser associado a seu respectivo usurio atravs de um identicador de usurio (UID - User IDentier), geralmente um nmero inteiro usado como chave em uma tabela de usurios cadastrados (como o arquivo /etc/passwd dos sistemas UNIX). O identicador de usurio usado pelo sistema operacional para denir o proprietrio de cada entidade e recurso conhecido: processo, arquivo, rea de memria, semforo, etc. habitual tambm classicar os usurios em grupos, como professores, alunos, contabilidade, engenharia, etc. Cada grupo identicado atravs de um identicador de grupo (GID - Group IDentier). A organizao dos grupos de usurios pode ser hierrquica ou arbitrria. O conjunto de informaes que relaciona um processo ao seu usurio e grupo geralmente denominado credenciais do processo. Normalmente, somente usurios devidamente autenticados podem ter acesso aos recursos de um sistema. Todavia, alguns recursos podem estar disponveis abertamente, como o caso de pastas de arquivos pblicas em rede e pginas em um servidor Web pblico. Nestes casos, assume-se a existncia de um usurio ctcio convidado (guest, nobody, anonymous ou outros), ao qual so associados todos os acessos externos no-autenticados e para o qual so denidas polticas de segurana especcas.
4.2
Tcnicas de autenticao
As tcnicas usadas para a autenticao de um usurio podem ser classicadas em trs grandes grupos: SYK Something You Know (algo que voc sabe): estas tcnicas de autenticao so baseadas em informaes conhecidas pelo usurio, como seu nome de login e sua senha. So consideradas tcnicas de autenticao fracas, pois a informao necessria para a autenticao pode ser facilmente comunicada a outras pessoas, ou mesmo roubada. SYH Something You Have (algo que voc tem): so tcnicas que se baseiam na posse de alguma informao mais complexa, como um certicado digital ou uma chave criptogrca, ou algum dispositivo material, como um smartcard, um carto magntico, um cdigo de barras, etc. Embora sejam mais robustas que as tcnicas SYK, estas tcnicas tambm tm seus pontos fracos, pois dispositivos materiais, como cartes, tambm podem ser roubados ou copiados. SYA Something You Are (algo que voc ): se baseiam em caractersticas intrinsecamente associadas ao usurio, como seus dados biomtricos: impresso digital, padro da ris, timbre de voz, etc. So tcnicas mais complexas de implementar, mas so potencialmente mais robustas que as anteriores.
Senhas 24
Muitos sistemas implementam somente a autenticao por login/senha (SYK). Sistemas mais recentes tm suporte a tcnicas SYH atravs de smartcards ou a tcnicas SYA usando biometria, como os sensores de impresso digital. Alguns servios de rede, como HTTP e SSH, tambm podem usar autenticao pelo endereo IP do cliente (SYA) ou atravs de certicados digitais (SYH). Sistemas computacionais com fortes requisitos de segurana geralmente implementam mais de uma tcnica de autenticao, o que chamado de autenticao multi-fator. Por exemplo, um sistema militar pode exigir senha e reconhecimento de ris para o acesso de seus usurios, enquanto um sistema bancrio pode exigir uma senha e o carto emitido pelo banco. Essas tcnicas tambm podem ser usadas de forma gradativa: uma autenticao bsica solicitada para o usurio acessar o sistema e executar servios simples (como consultar o saldo de uma conta bancria); se ele solicitar aes consideradas crticas (como fazer transferncias de dinheiro para outras contas), o sistema pode exigir mais uma autenticao, usando outra tcnica.
4.3
Senhas
A grande maioria dos sistemas operacionais de propsito geral implementam a tcnica de autenticao SYK baseada em login/senha. Na autenticao por senha, o usurio informa ao sistema seu identicador de usurio (nome de login) e sua senha, que normalmente uma sequncia de caracteres memorizada por ele. O sistema ento compara a senha informada pelo usurio com a senha previamente registrada para ele: se ambas forem iguais, o acesso consentido. A autenticao por senha simples mas muito frgil, pois implica no armazenamento das senhas em aberto no sistema, em um arquivo ou base de dados. Caso o arquivo ou base seja exposto devido a algum erro ou descuido, as senhas dos usurios estaro visveis. Para evitar o risco de exposio indevida das senhas, so usadas funes unidirecionais para armazen-las, como os resumos criptogrcos (Seo 3.3). A autenticao por senhas usando um resumo criptogrco bem simples: ao registrar a senha s de um novo usurio, o sistema calcula seu resumo (r = hash(s)), e o armazena. Mais tarde, quando esse usurio solicitar sua autenticao, ele informar uma senha s ; o sistema ento calcular novamente seu resumo r = hash(s ) e ir compar-lo ao resumo previamente armazenado (r = r). Se ambos forem iguais, a senha informada pelo usurio considerada autntica e o acesso do usurio ao sistema permitido. Com essa estratgia, as senhas no precisam ser armazenadas em aberto no sistema, aumentando sua segurana. Caso um intruso tenha acesso aos resumos das senhas dos usurios, ele no conseguir calcular de volta as senhas originais (pois o resumo foi calculado por uma funo unidirecional), mas pode tentar obter as senhas indiretamente, atravs do ataque do dicionrio. Nesse ataque, o invasor usa o algoritmo de resumo para cifrar palavras conhecidas ou combinaes delas, comparando os resumo obtidos com aqueles presentes no arquivo de senhas. Caso detecte algum resumo coincidente, ter encontrado a senha correspondente. O ataque do dicionrio permite encontrar senhas consideradas fracas, por serem muito curtas ou baseadas em palavras conhecidas. Por isso, muitos sistemas operacionais denem polticas rgidas para as senhas, impedindo o registro de senhas bvias ou muito curtas e restringindo o acesso ao repositrio dos resumos de senhas.
Senhas descartveis 25
4.4
Senhas descartveis
Um problema importante relacionado autenticao por senhas reside no risco de roubo da senhas. Por ser uma informao esttica, caso uma senha seja roubada, o malfeitor poder us-la enquanto o roubo no for percebido e a senha substituda. Para evitar esse problema, so propostas tcnicas de senhas descartveis (OTP - One-Time Passwords). Como o nome diz, uma senha descartvel s pode ser usada uma nica vez, perdendo sua validade aps esse uso. O usurio deve ento ter em mos uma lista de senhas pr-denidas, ou uma forma de ger-las quando necessrio. H vrias formas de se produzir e usar senhas descartveis, entre elas: Armazenar uma lista sequencial de senhas (ou seus resumos) no sistema e fornecer essa lista ao usurio, em papel ou outro suporte. Quando uma senha for usada com sucesso, o usurio e o sistema a eliminam de suas respectivas listas. Uma variante da lista de senhas conhecida como algoritmo OTP de Lamport [Menezes et al., 1996]. Ele consiste em criar uma sequncia de senhas s0 , s1 , s2 , , sn com s0 aleatrio e si = hash(si1 ) i > 0, sendo hash(x) uma funo de resumo criptogrco conhecida. O valor de sn informado ao servidor previamente. Ao acessar o servidor, o cliente informa o valor de sn1 . O servidor pode ento comparar hash(sn1 ) com o valor de sn previamente informado: se forem iguais, o cliente est autenticado e ambos podem descartar sn . O servidor armazena sn1 para validar a prxima autenticao, e assim sucessivamente. Um intruso que conseguir capturar uma senha si no poder us-la mais tarde, pois no conseguir calcular si1 = hash1 (si ). Gerar senhas temporrias sob demanda, atravs de um dispositivo ou software externo usado pelo cliente; as senhas temporrias podem ser geradas por um algoritmo de resumo que combine uma senha pr-denida com a data/horrio corrente. Dessa forma, cliente e servidor podem calcular a senha temporria de forma independente. Como o tempo uma informao importante nesta tcnica, o dispositivo ou software gerador de senhas do cliente deve estar sincronizado com o relgio do servidor. Dispositivos OTP como o mostrado na gura 8 so frequentemente usados em sistemas de Internet Banking.
4.5
Desao-resposta
Em algumas situaes o uso de senhas indesejvel, pois sua exposio indevida pode comprometer a segurana do sistema. Um exemplo disso so os servios via rede: caso o trfego de rede possa ser capturado por um intruso, este ter acesso s senhas transmitidas entre o cliente e o servidor. Uma tcnica interessante para resolver esse problema so os protocolos de desao-resposta. A tcnica de desao-resposta se baseia sobre um segredo s previamente denido entre o cliente e o servidor (ou o usurio e o sistema), que pode ser uma senha ou uma chave criptogrca, e um algoritmo de cifragem ou resumo hash(x), tambm previamente denido. No incio da autenticao, o servidor escolhe um valor aleatrio d e o envia ao cliente, como um desao. O cliente recebe esse desao, o concatena com
Desao-resposta 26
Figura 8: Um dispositivo gerador de senhas descartveis. seu segredo s, calcula o resumo da concatenao e a devolve ao servidor, como resposta (r = hash(s + d)). O servidor executa a mesma operao de seu lado, usando o valor do segredo armazenado localmente (s ) e compara o resultado obtido r = hash(s + d) com a resposta r fornecida pelo cliente. Se ambos os resultados forem iguais, os segredos so iguais (r = r s = s ) e o cliente considerado autntico. A gura 9 apresenta os passos desse algoritmo.
Cliente
senha s solicita acesso
Servidor
senha s' define d aleatrio
desafio(d) r=hash(s+d) resposta(r)
aceito/recusado
r'=hash(s'+d) aceito se r'=r (implica s'=s)
requisies (caso aceito) t
Figura 9: Autenticao por desao-resposta. A estratgia de desao-resposta robusta, porque o segredo s nunca exposto fora do cliente nem do servidor; alm disso, como o desao d aleatrio e a resposta cifrada, intrusos que eventualmente conseguirem capturar d ou r no podero utiliz-los para se autenticar nem para descobrir s. Variantes dessa tcnica so usadas em vrios protocolos de rede.
Certicados de autenticao 27
4.6
Certicados de autenticao
Uma forma cada vez mais frequente de autenticao envolve o uso de certicados digitais. Conforme apresentado na Seo 3.5, um certicado digital um documento assinado digitalmente, atravs de tcnicas de criptograa assimtrica e resumo criptogrco. Os padres de certicados PGP e X.509 denem certicados de autenticao (ou de identidade), cujo objetivo identicar entidades atravs de suas chaves pblicas. Um certicado de autenticao conforme o padro X.509 contm as seguintes informaes [Mollin, 2000]: Nmero de verso do padro X.509 usado no certicado; Chave pblica do proprietrio do certicado e indicao do algoritmo de criptograa ao qual ela est associada e eventuais parmetros; Nmero serial nico, denido pelo emissor do certicado (quem o assinou); Identicao detalhada do proprietrio do certicado, denida de acordo com normas do padro X.509; Perodo de validade do certicado (datas de incio e nal de validade); Identicao da Autoridade Certicadora que emitiu/assinou o certicado; Assinatura digital do certicado e indicao do algoritmo usado na assinatura e eventuais parmetros; Os certicados digitais so o principal mecanismo usado para vericar a autenticidade de servios acessveis atravs da Internet, como bancos e comrcio eletrnico. Nesse caso, eles so usados para autenticar os sistemas para os usurios. No entanto, cada vez mais frequente o uso de certicados para autenticar os prprios usurios. Nesse caso, um smartcard ou um dispositivo USB contendo o certicado conectado ao sistema para permitir a autenticao do usurio.
4.7
Tcnicas biomtricas
A biometria (biometrics) consiste em usar caractersticas fsicas ou comportamentais de um indivduo, como suas impresses digitais ou seu timbre de voz, para identiclo unicamente perante o sistema. Diversas caractersticas podem ser usadas para a autenticao biomtrica; no entanto, elas devem obedecer a um conjunto de princpios bsicos [Jain et al., 2004]: Universalidade: a caracterstica biomtrica deve estar presente em todos os indivduos que possam vir a ser autenticados; Singularidade (ou unicidade): dois indivduos quaisquer devem apresentar valores distintos para a caracterstica em questo; Permanncia: a caracterstica no deve mudar ao longo do tempo, ou ao menos no deve mudar de forma abrupta;
Kerberos 28
Mensurabilidade: a caracterstica em questo deve ser facilmente mensurvel em termos quantitativos. As caractersticas biomtricas usadas em autenticao podem ser fsicas ou comportamentais. Como caractersticas fsicas so consideradas, por exemplo, o DNA, a geometria das mos, do rosto ou das orelhas, impresses digitais, o padro da ris (padres na parte colorida do olho) ou da retina (padres de vasos sanguneos no fundo do olho). Como caractersticas comportamentais so consideradas a assinatura, o padro de voz e a dinmica de digitao (intervalos de tempo entre teclas digitadas), por exemplo. Os sistemas mais populares de autenticao biomtrica atualmente so os baseados em impresses digitais e no padro de ris. Esses sistemas so considerados conveis, por apresentarem taxas de erro relativamente baixas, custo de implantao/operao baixo e facilidade de coleta dos dados biomtricos. A gura 10 apresenta alguns exemplos de caractersticas biomtricas empregadas nos sistemas atuais.
iris
retina
retina e ris
padro de voz
impresso digital
Figura 10: Exemplo de caractersticas biomtricas. Um sistema biomtrico tpico composto de um sensor, responsvel por capturar dados biomtricos de uma pessoa; um extrator de caractersticas, que processa os dados do sensor para extrair suas caractersticas mais relevantes; um comparador, cuja funo comparar as caractersticas extradas do indivduo sob anlise com dados previamente armazenados, e um banco de dados contendo as caractersticas biomtricas dos usurios registrados no sistema [Jain et al., 2004]. O sistema pode funcionar de dois modos: no modo de autenticao, ele verica se as caractersticas biomtricas de um indivduo (previamente identicado por algum outro mtodo, como login/senha, carto, etc) correspondem s suas caractersticas biomtricas previamente armazenadas. Desta forma, a biometria funciona como uma autenticao complementar. No modo de identicao, o sistema biomtrico visa identicar o indivduo a quem correspondem as caractersticas biomtricas coletadas pelo sensor, dentre todos aqueles presentes no banco de dados. A gura 11 mostra os principais elementos de um sistema biomtrico tpico.
4.8
Kerberos
O sistema de autenticao Kerberos foi proposto pelo MIT nos anos 80 [Neuman and Tso, 1994]. Hoje, esse sistema utilizado para centralizar a autenticao de rede em vrios sistemas operacionais, como Windows, Solaris, MacOS X e Linux. O sistema Kerberos se baseia na noo de tickets, que so obtidos pelos clientes
Kerberos 29
dados biomtricos
sensor
dados biomtricos
sistema biomtrico extrator de caractersticas

caractersticas relevantes usurios cadastrados coleta/registro
humanos senha carto etc.
autenticador
identidade
comparador
base de dados
resultado (identificao ou autenticao)
Figura 11: Um sistema biomtrico tpico. junto a um servio de autenticao e podem ser usados para acessar os demais servios da rede. Os tickets so cifrados usando criptograa simtrica DES e tm validade limitada, para aumentar sua segurana. Os principais componentes de um sistema Kerberos so o Servio de Autenticao (AS - Authentication Service), o Servio de Concesso de Tickets (TGS - Ticket Granting Service), a base de chaves, os clientes e os servios de rede que os clientes podem acessar. Juntos, o AS e o TGS constituem o Centro de Distribuio de Chaves (KDC - Key Distribution Center). O funcionamento bsico do sistema Kerberos, ilustrado na gura 12, relativamente simples: o cliente se autentica junto ao AS (passo 1) e obtm um ticket de acesso ao servio de tickets TGS (passo 2). A seguir, solicita ao TGS um ticket de acesso ao servidor desejado (passos 3 e 4). Com esse novo ticket, ele pode se autenticar junto ao servidor desejado e solicitar servios (passos 5 e 6).
Key Distribution Center 1 client 5 T2 6 server T2 3 T1 2 Authentication Service
T1 4 Ticket Granting Service users/keys database
Figura 12: Viso geral do servio Kerberos. No Kerberos, cada cliente c possui uma chave secreta kc registrada no servidor de autenticao AS. Da mesma forma, cada servidor s tambm tem sua chave ks registrada no AS. As chaves so simtricas, usando cifragem DES, e somente so conhecidas por
Kerberos 30
seus respectivos proprietrios e pelo AS. Os seguintes passos detalham o funcionamento do Kerberos verso 5 [Neuman and Tso, 1994]: 1. Uma mquina cliente c desejando acessar um determinado servidor s envia uma solicitao de autenticao ao servio de autenticao (AS); essa mensagem m1 contm sua identidade (c), a identidade do servio desejado (tgs), um prazo de validade solicitado (ts) e um nmero aleatrio (n1 ) que ser usado para vericar se a resposta do AS corresponde ao pedido efetuado: m1 = [c tgs ts n1 ] 2. A resposta do AS (mensagem m2 ) contm duas partes: a primeira parte contm a chave de sesso a ser usada na comunicao com o TGS (kctgs ) e o nmero aleatrio n1 , ambos cifrados com a chave do cliente kc registrada no AS; a segunda parte um ticket cifrado com a chave do TGS (ktgs ), contendo a identidade do cliente (c), o prazo de validade do ticket concedido pelo AS (tv) e uma chave de sesso kctgs , a ser usada na interao com o TGS: m2 = [{kctgs n1 }kc Tctgs ] onde Tctgs = {c tv kctgs }ktgs
O ticket Tctgs fornecido pelo AS para permitir o acesso ao TGS chamado TGT (Ticket Granting Ticket), e possui um prazo de validade limitado (geralmente de algumas horas). Ao receber m2 , o cliente tem acesso chave de sesso kctgs e ao ticket TGT. Todavia, esse ticket cifrado com a chave ktgs e portanto somente o TGS poder abr-lo. 3. A seguir, o cliente envia uma solicitao ao TGS (mensagem m3 ) para obter um ticket de acesso ao servidor desejado s. Essa solicitao contm a identidade do cliente (c) e a data atual (t), ambos cifrados com a chave de sesso kctgs , o ticket TGT recebido em m2 , a identidade do servidor s e um nmero aleatrio n2 : m3 = [{c t}kctgs Tctgs s n2 ] 4. Aps vericar a validade do ticket TGT, o TGS devolve ao cliente uma mensagem m4 contendo a chave de sesso kcs a ser usada no acesso ao servidor s e o nmero aleatrio n2 informado em m3 , ambos cifrados com a chave de sesso kctgs , e um ticket Tcs cifrado, que deve ser apresentado ao servidor s: m4 = [{kcs n}kctgs Tcs ] onde Tcs = {c tv kcs }ks
5. O cliente usa a chave de sesso kcs e o ticket Tcs para se autenticar junto ao servidor s atravs da mensagem m5 . Essa mensagem contm a identidade do cliente (c) e a data atual (t), ambos cifrados com a chave de sesso kcs , o ticket Tcs recebido em m4 e o pedido de servio ao servidor (request), que dependente da aplicao: m5 = [{c t}kcs Tcs request]
Infra-estruturas de autenticao 31
6. Ao receber m5 , o servidor s decifra o ticket Tcs para obter a chave de sesso kcs e a usa para decifrar a primeira parte da mensagem e conrmar a identidade do cliente. Feito isso, o servidor pode atender a solicitao e responder ao cliente, cifrando sua resposta com a chave de sesso kcs : m6 = [{reply}kcs ] Enquanto o ticket de servio Tcs for vlido, o cliente pode enviar solicitaes ao servidor sem a necessidade de se reautenticar. Da mesma forma, enquanto o ticket Tctgs for vlido, o cliente pode solicitar tickets de acesso a outros servidores sem precisar se reautenticar. Pode-se observar que em nenhum momento as chaves de sesso kctgs e kcs circularam em aberto atravs da rede. Alm disso, a presena de prazos de validade para as chaves permite minimizar os riscos de uma eventual captura da chave. Informaes mais detalhadas sobre o funcionamento do protocolo Kerberos 5 podem ser encontradas em [Neuman et al., 2005].
4.9
Infra-estruturas de autenticao
A autenticao um procedimento necessrio em vrios servios de um sistema computacional, que vo de simples sesses de terminal em modo texto a servios de rede, como e-mail, bancos de dados e terminais grcos remotos. Historicamente, cada forma de acesso ao sistema possua seus prprios mecanismos de autenticao, com suas prprias regras e informaes. Essa situao dicultava a criao de novos servios, pois estes deveriam tambm denir seus prprios mtodos de autenticao. Alm disso, a existncia de vrios mecanismos de autenticao desconexos prejudicava a experincia do usurio e dicultava a gerncia do sistema. Para resolver esse problema, foram propostas infra-estruturas de autenticao (authentication frameworks) que unicam as tcnicas de autenticao, oferecem uma interface de programao homognea e usam as mesmas informaes (pares login/senha, dados biomtricos, certicados, etc). Assim, as informaes de autenticao so coerentes entre os diversos servios, novas tcnicas de autenticao podem ser automaticamente usadas por todos os servios e, sobretudo, a criao de novos servios simplicada. A viso genrica de uma infra-estrutura de autenticao apresentada na gura 13. Nela, os vrios mecanismos disponveis de autenticao so oferecidos s aplicaes atravs de uma interface de programao (API) padronizada. As principais infraestruturas de autenticao em uso nos sistemas operacionais atuais so: PAM (Pluggable Authentication Modules): proposto inicialmente para o sistema Solaris, foi depois adotado em vrios outros sistema UNIX, como FreeBSD, NetBSD, MacOS X e Linux; XSSO (X/Open Single Sign-On): uma tentativa de extenso e padronizao do sistema PAM, ainda pouco utilizada; BSD Auth : usada no sistema operacional OpenBSD; cada mtodo de autenticao implementado como um processo separado, respeitando o princpio do privilgio mnimo (vide Seo 5.1);
Controle de acesso 32
NSS (Name Services Switch): infra-estrutura usada em sistemas UNIX para denir as bases de dados a usar para vrios servios do sistema operacional, inclusive a autenticao; GSSAPI (Generic Security Services API): padro de API para acesso a servios de segurana, como autenticao, condencialidade e integridade de dados; SSPI (Security Support Provider Interface): variante proprietria da GSSAPI, especca para plataformas Windows.
aplicaes e/ou servios
API padronizada
login/senha
certificados
endereo IP
biometria
Figura 13: Estrutura genrica de uma infra-estrutura de autenticao.
Controle de acesso
Em um sistema computacional, o controle de acesso consiste em mediar cada solicitao de acesso de um usurio autenticado a um recurso ou dado mantido pelo sistema, para determinar se aquela solicitao deve ser autorizada ou negada [Samarati and De Capitani di Vimercati, 2001]. Praticamente todos os recursos de um sistema operacional tpico esto submetidos a um controle de acesso, como arquivos, reas de memria, semforos, portas de rede, dispositivos de entrada/sada, etc. H alguns conceitos importantes para a compreenso do controle de acesso, como polticas, modelos e mecanismos. Esses conceitos sero estudados nesta seo. Em controle de acesso, habitual classicar as entidades de um sistema em dois grupos: os sujeitos e os objetos. Sujeitos so todas aquelas entidades que exercem um papel ativo no sistema, como processos, threads ou transaes. Normalmente um sujeito opera em nome de um usurio, que pode ser um ser humano ou outro sistema computacional externo. Objetos so as entidades passivas utilizadas pelos sujeitos, como arquivos, reas de memria ou registros em um banco de dados. Em alguns
...
Polticas, modelos e mecanismos de controle de acesso 33
casos, um sujeito pode ser visto como objeto por outro sujeito (por exemplo, quando um sujeito deve enviar uma mensagem a outro sujeito). Tanto sujeitos quanto objetos podem ser organizados em grupos e hierarquias, para facilitar a gerncia da segurana.
5.1
Polticas, modelos e mecanismos de controle de acesso
Uma poltica de controle de acesso uma viso abstrata das possibilidades de acesso a recursos (objetos) pelos usurios (sujeitos) de um sistema. Essa poltica consiste basicamente de um conjunto de regras denindo os acessos possveis aos recursos do sistema e eventuais condies necessrias para permitir cada acesso. Por exemplo, as regras a seguir poderiam constituir parte da poltica de segurana de um sistema de informaes mdicas: Mdicos podem consultar os pronturios de seus pacientes; Mdicos podem modicar os pronturios de seus pacientes enquanto estes estiverem internados; O supervisor geral pode consultar os pronturios de todos os pacientes; Enfermeiros podem consultar apenas os pronturios dos pacientes de sua seo e somente durante seu perodo de turno; Assistentes no podem consultar pronturios; Pronturios de pacientes de planos de sade privados podem ser consultados pelo responsvel pelo respectivo plano de sade no hospital; Pacientes podem consultar seus prprios pronturios (aceitar no mximo 30 pacientes simultneos). As regras ou denies individuais de uma poltica so denominadas autorizaes. Uma poltica de controle de acesso pode ter autorizaes baseadas em identidades (como sujeitos e objetos) ou em outros atributos (como idade, sexo, tipo, preo, etc); as autorizaes podem ser individuais (a sujeitos) ou coletivas (a grupos); tambm podem existir autorizaes positivas (permitindo o acesso) ou negativas (negando o acesso); por m, uma poltica pode ter autorizaes dependentes de condies externas (como o tempo ou a carga do sistema). Alm da poltica de acesso aos objetos, tambm deve ser denida uma poltica administrativa, que dene quem pode modicar/gerenciar as polticas vigentes no sistema [Samarati and De Capitani di Vimercati, 2001]. O conjunto de autorizaes de uma poltica deve ser ao mesmo tempo completo, cobrindo todas as possibilidades de acesso que vierem a ocorrer no sistema, e consistente, sem regras conitantes entre si (por exemplo, uma regra que permita um acesso e outra que negue esse mesmo acesso). Alm disso, toda poltica deve buscar respeitar o princpio do privilgio mnimo [Saltzer and Schroeder, 1975], segundo o qual um usurio nunca deve receber mais autorizaes que aquelas que necessita para cumprir sua tarefa. A construo e validao de polticas de controle de acesso um tema complexo, que est fora do escopo deste texto, sendo melhor descrito em [di Vimercati et al., 2005, di Vimercati et al., 2007].
Polticas discricionrias 34
As polticas de controle de acesso denem de forma abstrata como os sujeitos podem acessar os objetos do sistema. Existem muitas formas de se denir uma poltica, que podem ser classicadas em quatro grandes classes: polticas discricionrias, polticas obrigatrias, polticas baseadas em domnios e polticas baseadas em papis [Samarati and De Capitani di Vimercati, 2001]. As prximas sees apresentam com mais detalhe cada uma dessas classes de polticas. Geralmente a descrio de uma poltica de controle de acesso muito abstrata e informal. Para sua implementao em um sistema real, ela precisa ser descrita de uma forma precisa, atravs de um modelo de controle de acesso. Um modelo de controle de acesso uma representao lgica ou matemtica da poltica, de forma a facilitar sua implementao e permitir a anlise de eventuais erros. Em um modelo de controle de acesso, as autorizaes de uma poltica so denidas como relaes lgicas entre atributos do sujeito (como seus identicadores de usurio e grupo) atributos do objeto (como seu caminho de acesso ou seu proprietrio) e eventuais condies externas (como o horrio ou a carga do sistema). Nas prximas sees, para cada classe de polticas de controle de acesso apresentada sero discutidos alguns modelos aplicveis mesma. Por m, os mecanismos de controle de acesso so as estruturas necessrias implementao de um determinado modelo em um sistema real. Como bem sabido, de fundamental importncia a separao entre polticas e mecanismos, para permitir a substituio ou modicao de polticas de controle de acesso de um sistema sem incorrer em custos de modicao de sua implementao. Assim, um mecanismo de controle de acesso ideal deveria ser capaz de suportar qualquer poltica de controle de acesso.
5.2
Polticas discricionrias
As polticas discricionrias (DAC - Discretionary Access Control) se baseiam na atribuio de permisses de forma individualizada, ou seja, pode-se claramente conceder (ou negar) a um sujeito especco s a permisso de executar a ao a sobre um objeto especco o. Em sua forma mais simples, as regras de uma poltica discricionria tm a forma s, o, +a ou s, o, a , para respectivamente autorizar ou negar a ao a do sujeito s sobre o objeto o (tambm podem ser denidas regras para grupos de usurios e/ou de objetos devidamente identicados). Por exemplo: O usurio Beto pode ler e escrever arquivos em /home/beto Usurios do grupo admin podem ler os arquivos em /suporte O responsvel pela administrao das permisses de acesso a um objeto pode ser o seu proprietrio ou um administrador central. A denio de quem estabelece as regras da poltica de controle de acesso inerente a uma poltica administrativa, independente da poltica de controle de acesso em si6 .
Muitas polticas de controle de acesso discricionrias so baseadas na noo de que cada recurso do sistema possui um proprietrio, que decide quem pode acessar o recurso. Isso ocorre por exemplo nos sistemas de arquivos, onde as permisses de acesso a cada arquivo ou diretrio so denidas pelo respectivo proprietrio. Contudo, a noo de proprietrio de um recurso no essencial para a construo de polticas discricionrias [Shirey, 2000].
6
Alice
Beto
f ile1 read write remove read write
f ile2 read write read write remove read append
program1 execute
socket1 write
read
Carol Davi read
execute read
read write read append
Tabela 1: Uma matriz de controle de acesso 5.2.1 Matriz de controle de acesso
O modelo matemtico mais simples e conveniente para representar polticas discricionrias a Matriz de Controle de Acesso, proposta em [Lampson, 1971]. Nesse modelo, as autorizaes so dispostas em uma matriz, cujas linhas correspondem aos sujeitos do sistema e cujas colunas correspondem aos objetos. Em termos formais, considerando um conjunto de sujeitos S = {s1 , s2 , . . . , sm }, um conjunto de objetos O = {o1 , o2 , . . . , on } e um conjunto de aes possveis sobre os objetos A = {a1 , a2 , . . . , ap }, cada elemento Mi j da matriz de controle de acesso um sub-conjunto (que pode ser vazio) do conjunto de aes possveis, que dene as aes que si S pode efetuar sobre o j O: si S, o j O, Mi j A Por exemplo, considerando um conjunto de sujeitos S = {Alice, Beto, Carol, Davi}, um conjunto de objetos O = { f ile1 , f ile2 , program1 , socket1 } e um conjunto de aes A = {read, write, execute, remove}, podemos ter uma matriz de controle de acesso como a apresentada na Tabela 1. Apesar de simples, o modelo de matriz de controle de acesso sucientemente exvel para suportar polticas administrativas. Por exemplo, considerando uma poltica administrativa baseada na noo de proprietrio do recurso, poder-se-ia considerar que que cada objeto possui um ou mais proprietrios (owner), e que os sujeitos podem modicar as entradas da matriz de acesso relativas aos objetos que possuem. Uma matriz de controle de acesso com essa poltica administrativa apresentada na Tabela 2. Embora seja um bom modelo conceitual, a matriz de acesso inadequada para implementao. Em um sistema real, com milhares de sujeitos e milhes de objetos, essa matriz pode se tornar gigantesca e consumir muito espao. Como em um sistema real cada sujeito tem seu acesso limitado a um pequeno grupo de objetos (e vice-versa), a matriz de acesso geralmente esparsa, ou seja, contm muitas clulas vazias. Assim, algumas tcnicas simples podem ser usadas para implementar esse modelo, como as tabelas de autorizaes, as listas de controle de acesso e as listas de capacidades [Samarati and De Capitani di Vimercati, 2001], explicadas a seguir.
Alice
Beto
f ile1 read write remove owner read write
f ile2 read write
program1 execute
socket1 write
Carol Davi read
read write remove owner read write
read owner
execute read
read write read write owner
Tabela 2: Uma matriz de controle de acesso com poltica administrativa 5.2.2 Tabela de autorizaes
Na abordagem conhecida como Tabela de Autorizaes, as entradas no-vazias da matriz so relacionadas em uma tabela com trs colunas: sujeitos, objetos e aes, onde cada tupla da tabela corresponde a uma autorizao. Esta abordagem muito utilizada em sistemas gerenciadores de bancos de dados (DBMS - Database Management Systems), devido sua facilidade de implementao e consulta nesse tipo de ambiente. A tabela 3 mostra como caria a matriz de controle de acesso da Tabela 2 sob a forma de uma tabela de autorizaes. 5.2.3 Listas de controle de acesso
Outra abordagem usual a Lista de Controle de Acesso. Nesta abordagem, para cada objeto denida uma lista de controle de acesso (ACL - Access Control List), que contm a relao de sujeitos que podem acess-lo, com suas respectivas permisses. Cada lista de controle de acesso corresponde a uma coluna da matriz de controle de acesso. Como exemplo, as listas de controle de acesso relativas matriz de controle de acesso da Tabela 2 seriam: ACL( f ile1 ) = { Alice : (read, write, remove, owner), Beto : (read, write), Davi : (read) } ACL( f ile2 ) = { Alice : (read, write), Beto : (read, write, remove, owner), Carol : (read), Davi : (write) } ACL(program1 ) = { Alice : (execute),
Sujeito Alice Alice Alice Alice Alice Alice Alice Alice Beto Beto Beto Beto Beto Beto Beto Beto Carol Carol Carol Carol Davi Davi Davi Davi Davi Davi
Objeto f ile1 f ile1 f ile1 f ile1 f ile2 f ile2 program1 socket1 f ile1 f ile1 f ile2 f ile2 f ile2 f ile2 program1 socket1 f ile2 program1 socket1 socket1 f ile1 f ile2 program1 socket1 socket1 socket1
Ao read write remove owner read write execute write read write read write remove owner read owner read execute read write read write read read write owner
Tabela 3: Tabela de autorizaes
Beto : (read, owner), Carol : (execute), Davi : (read) } ACL(socket1 ) = { Alice : (write), Carol : (read, write), Davi : (read, write, owner) }
Esta forma de implementao a mais freqentemente usada em sistemas operacionais, por ser simples de implementar e bastante robusta. Por exemplo, o sistema de arquivos associa uma ACL a cada arquivo ou diretrio, para indicar quem so os sujeitos autorizados a acess-lo. Em geral, somente o proprietrio do arquivo pode modicar sua ACL, para incluir ou remover permisses de acesso. 5.2.4 Listas de capacidades
Uma terceira abordagem possvel para a implementao da matriz de controle de acesso a Lista de Capacidades (CL - Capability List), ou seja, uma lista de objetos que um dado sujeito pode acessar e suas respectivas permisses sobre os mesmos. Cada lista de capacidades corresponde a uma linha da matriz de acesso. Como exemplo, as listas de capacidades correspondentes matriz de controle de acesso da Tabela 2 seriam: CL(Alice) = { f ile1 : (read, write, remove, owner), f ile2 : (read, write), program1 : (execute), socket1 : (write) } CL(Beto) = { f ile1 : (read, write), f ile2 : (read, write, remove, owner), program1 : (read, owner) } CL(Carol) = { f ile2 : (read), program1 : (execute), socket1 : (read, write) } CL(Davi) = { f ile1 : (read), f ile2 : (write), program1 : (read), socket1 : (read, write, owner) }
Uma capacidade pode ser vista como uma cha ou token: sua posse d ao proprietrio o direito de acesso ao objeto em questo. Capacidades so pouco usadas em sistemas operacionais, devido sua diculdade de implementao e possibilidade de fraude, pois uma capacidade mal implementada pode ser transferida deliberadamente a outros
Polticas obrigatrias 39
sujeitos, ou modicada pelo prprio proprietrio para adicionar mais permisses a ela. Outra diculdade inerente s listas de capacidades a administrao das autorizaes: por exemplo, quem deve ter permisso para modicar uma lista de capacidades, e como retirar uma permisso concedida anteriormente a um sujeito? Alguns sistemas operacionais que implementam o modelo de capacidades so discutidos na Seo 5.6.4.
5.3
Polticas obrigatrias
Nas polticas obrigatrias (MAC - Mandatory Access Control) o controle de acesso denido por regras globais incontornveis, que no dependem das identidades dos sujeitos e objetos nem da vontade de seus proprietrios ou mesmo do administrador do sistema [Samarati and De Capitani di Vimercati, 2001]. Essas regras so normalmente baseadas em atributos dos sujeitos e/ou dos objetos, como mostram estes exemplos bancrios (ctcios): Cheques com valor acima de R$ 5.000,00 devem ser necessariamente depositados e no podem ser descontados; Clientes com renda mensal acima de R$3.000,00 no tm acesso ao crdito consignado. Uma das formas mais usuais de poltica obrigatria so as polticas multi-nvel (MLS Multi-Level Security), que se baseiam na classicao de sujeitos e objetos do sistema em nveis de segurana (clearance levels) e na denio de regras usando esses nveis. Um exemplo bem conhecido de escala de nveis de classicao aquela usada pelo governo britnico para denir a condencialidade de um documento: TS: Top Secret (Ultrassecreto) S: Secret (Secreto) C: Condential (Condencial) R: Restrict (Reservado) U: Unclassied (Pblico) Em uma poltica MLS, considera-se que os nveis de segurana esto ordenados entre si (por exemplo, U < R < C < S < TS) e so associados a todos os sujeitos e objetos do sistema, sob a forma de habilitao dos sujeitos (h(si )) e classicao dos objetos (c(o j )). As regras da poltica so ento estabelecidas usando essas habilitaes e classicaes, como mostram os modelos descritos a seguir. 5.3.1 Modelo de Bell-LaPadula
Um modelo de controle de acesso que permite formalizar polticas multi-nvel o de Bell-LaPadula [Bell and LaPadula, 1974], usado para garantir a condencialidade das informaes. Esse modelo consiste basicamente de duas regras:
Polticas obrigatrias 40
No-Read-Up (no ler acima, ou propriedade simples): impede que um sujeito leia objetos que se encontrem em nveis de segurana acima do seu. Por exemplo, um sujeito habilitado como condencial (C) somente pode ler objetos cuja classicao seja condencial (C), reservada (R) ou pblica (U). Considerando um sujeito s e um objeto o, formalmente temos: request(s, o, read) h(s) c(o) No-Write-Down (no escrever abaixo, ou propriedade ): impede que um sujeito escreva em objetos abaixo de seu nvel de segurana, para evitar o vazamento de informaes dos nveis superiores para os inferiores. Por exemplo, um sujeito habilitado como condencial somente pode escrever em objetos cuja classicao seja condencial, secreta ou ultrassecreta. Formalmente, temos: request(s, o, write) h(s) c(o) Pode-se perceber facilmente que a poltica obrigatria representada pelo modelo de Bell-LaPadula visa proteger a condencialidade das informaes do sistema, evitando que estas uam dos nveis superiores para os inferiores. Todavia, nada impede um sujeito com baixa habilitao escrever sobre um objeto de alta classicao, destruindo seu contedo. 5.3.2 Modelo de Biba
Para garantir a integridade das informaes, um modelo dual ao de Bell-LaPadula foi proposto por Biba [Biba, 1977]. Esse modelo dene nveis de integridade i(x) para sujeitos e objetos (como Baixa, Mdia, Alta e Sistema, com B < M < A < S), e tambm possui duas regras bsicas: No-Write-Up (no escrever acima, ou propriedade simples de integridade): impede que um sujeito escreva em objetos acima de seu nvel de integridade, preservandoos ntegros. Por exemplo, um sujeito de integridade mdia (M) somente pode escrever em objetos de integridade baixa (B) ou mdia (M). Formalmente, temos: request(s, o, write) i(s) i(o) No-Read-Down (no ler abaixo, ou propriedade de integridade): impede que um sujeito leia objetos em nveis de integridade abaixo do seu, para no correr o risco de ler informao duvidosa. Por exemplo, um sujeito com integridade alta (A) somente pode ler objetos com integridade alta (A) ou de sistema (S). Formalmente, temos: request(s, o, read) i(s) i(o)
Polticas baseadas em domnios 41
A poltica obrigatria denida atravs do modelo de Biba evita violaes de integridade, mas no garante a condencialidade das informaes. Para que as duas polticas (condencialidade e integridade) possam funcionar em conjunto, necessrio portanto associar a cada sujeito e objeto do sistema um nvel de condencialidade e um nvel de integridade, possivelmente distintos. importante observar que, na maioria dos sistemas reais, as polticas obrigatrias no substituem as polticas discricionrias, mas as complementam. Em um sistema que usa polticas obrigatrias, cada acesso a recurso vericado usando a politica obrigatria e tambm uma politica discricionria; o acesso permitido somente se ambas as politicas o autorizarem. A ordem de avaliao das polticas MAC e DAC obviamente no afeta o resultado nal, mas pode ter impacto sobre o desempenho do sistema. Por isso, deve-se primeiro avaliar a poltica mais restritiva, ou seja, aquela que tem mais probabilidades de negar o acesso. 5.3.3 Categorias
Uma extenso freqente s polticas multi-nvel a noo de categorias ou compartimentos. Uma categoria dene uma rea funcional dentro do sistema computacional, como pessoal, projetos, nanceiro, suporte, etc. Normalmente o conjunto de categorias esttico no h uma ordem hierrquica entre elas. Cada sujeito e cada objeto do sistema so rotulados com uma ou mais categorias; a poltica ento consiste em restringir o acesso de um sujeito somente aos objetos pertencentes s mesmas categorias dele, ou a um sub-conjunto destas. Dessa forma, um sujeito com as categorias {suporte, f inanceiro} s pode acessar objetos rotulados como {suporte, f inanceiro}, {suporte}, { f inanceiro} ou {}. Formalmente: sendo C(s) o conjunto de categorias associadas a um sujeito s e C(o) o conjunto de categorias associadas a um objeto o, s s pode acessar o se C(s) C(o) [Samarati and De Capitani di Vimercati, 2001].
5.4
Polticas baseadas em domnios
O domnio de segurana de um sujeito dene o conjunto de objetos que ele pode acessar e como pode acess-los. Muitas vezes esse domnio est denido implicitamente nas regras das polticas obrigatrias ou na matriz de controle de acesso de uma poltica discricionria. As polticas baseadas em domnios (DTE - Domain and Type Enforcement policies) [Boebert and Kain, 1985] tornam explcito esse conceito: cada sujeito s do sistema rotulado com um atributo constante denindo seu domnio domain(s) e cada objeto o associado a um tipo type(o), tambm constante. No modelo de implementao de uma poltica DTE denido em [Badger et al., 1995], as permisses de acesso de sujeitos a objetos so denidas em uma tabela global chamada Tabela de Denio de Domnios (DDT - Domain Denition Table), na qual cada linha associada a um domnio e cada coluna a um tipo; cada clula DDT[x, y] contm as permisses de sujeitos do domnio x a objetos do tipo y: request(s, o, action) action DDT[domain(s), type(o)] Por sua vez, as interaes entre sujeitos (trocas de mensagens, sinais, etc) so reguladas atravs de uma Tabela de Interao entre Domnios (DIT - Domain Interaction
Polticas baseadas em papis 42
Table). Nessa tabela, linhas e colunas correspondem a domnios e cada clula DIT[x, y] contm as interaes possveis de um sujeito no domnio x sobre um sujeito no domnio y: request(si , s j , interaction) interaction DIT[domain(si ), domain(s j )] A implementao direta desse modelo sobre um sistema real pode ser invivel, pois exige a classicao de todos os sujeitos e objetos do mesmo em domnios e tipos. Para atenuar esse problema, [Badger et al., 1995, Cowan et al., 2000] propem o uso de tipagem implcita: todos os objetos que satisfazem um certo critrio (como por exemplo ter como caminho /usr/local/*) so automaticamente classicados em um dado tipo. Da mesma forma, os domnios podem ser denidos pelos nomes dos programas executveis que os sujeitos executam (como /usr/bin/httpd e /usr/lib/httpd/plugin/* para o domnio do servidor Web). Alm disso, ambos os autores propem linguagens para a denio dos domnios e tipos e para a descrio das polticas de controle de acesso.
5.5
Polticas baseadas em papis
Um dos principais problemas de segurana em um sistema computacional a administrao correta das polticas de controle de acesso. As polticas MAC so geralmente consideradas pouco exveis e por isso as polticas DAC acabam sendo muito mais usadas. Todavia, gerenciar as autorizaes medida em que usurios mudam de cargo e assumem novas responsabilidades, novos usurios entram na empresa e outros saem pode ser uma tarefa muito complexa e sujeita a erros. Esse problema pode ser reduzido atravs do controle de acesso baseado em papis (RBAC - Role-Based Access Control) [Sandhu et al., 1996]. Uma poltica RBAC dene um conjunto de papis no sistema, como diretor, gerente, suporte, programador, etc. e atribui a cada papel um conjunto de autorizaes. Essas autorizaes podem ser atribudas aos papis de forma discricionria ou obrigatria. Para cada usurio do sistema denido um conjunto de papis que este pode assumir. Durante sua sesso no sistema (geralmente no incio), o usurio escolhe os papis que deseja ativar e recebe as autorizaes correspondentes, vlidas at este desativar os papis correspondentes ou encerrar sua sesso. Assim, um usurio autorizado pode ativar os papis de professor ou de aluno dependendo do que deseja fazer no sistema. Os papis permitem desacoplar os usurios das permisses. Por isso, um conjunto de papis denido adequadamente bastante estvel, restando gerncia apenas atribuir a cada usurio os papis a que este tem direito. A gura 14 apresenta os principais componentes de uma poltica RBAC. Existem vrios modelos para a implementao de polticas baseadas em papis, como os apresentados em [Sandhu et al., 1996]. Por exemplo, no modelo RBAC hierrquico os papis so classicados em uma hierarquia, na qual os papis superiores herdam as permisses dos papis inferiores. No modelo RBAC com restries possvel denir restries ativao de papis, como o nmero mximo de usurios que podem ativar um determinado papel simultaneamente ou especicar que dois papis so conitantes e no podem ser ativados pelo mesmo usurio simultaneamente.
Mecanismos de controle de acesso 43
professor
arquivos
diretor
aluno
suporte
registros
usurios
ativaes
papis
permisses
objetos
Figura 14: Polticas baseadas em papis.
5.6
Mecanismos de controle de acesso
A implementao do controle de acesso em um sistema computacional deve ser independente das polticas de controle de acesso adotadas. Como nas demais reas de um sistema operacional, a separao entre mecanismo e poltica importante, por possibilitar trocar a poltica de controle de acesso sem ter de modicar a implementao do sistema. A infra-estrutura de controle de acesso deve ser ao mesmo tempo inviolvel (impossvel de adulterar ou enganar) e incontornvel (todos os acessos aos recursos do sistema devem passar por ela). 5.6.1 Infra-estrutura bsica
A arquitetura bsica de uma infra-estrutura de controle de acesso tpica composta pelos seguintes elementos (gura 15): Bases de sujeitos e objetos (User/Object Bases): relao dos sujeitos e objetos que compem o sistema, com seus respectivos atributos; Base de polticas (Policy Base): base de dados contendo as regras que denem como e quando os objetos podem ser acessados pelos sujeitos, ou como/quando os sujeitos podem interagir entre si; Monitor de referncias (Reference monitor): elemento que julga a pertinncia de cada pedido de acesso. Com base em atributos do sujeito e do objeto (como suas respectivas identidades), nas regras da base de polticas e possivelmente em
informaes externas (como horrio, carga do sistema, etc), o monitor decide se um acesso deve ser permitido ou negado; Mediador (impositor ou Enforcer): elemento que medeia a interao entre sujeitos e objetos; a cada pedido de acesso a um objeto, o mediador consulta o monitor de referncias e permite/nega o acesso, conforme a deciso deste ltimo.
sujeitos
objetos
arquivos
permite acessos
mediador
nega
aes
processos threads transaes
sujeito, objeto, ao
deciso
informaes externas (horrio, etc)
monitor de referncias
eventos
para os registros de auditoria
base de sujeitos
base de polticas
base de objetos
Figura 15: Estrutura genrica de uma infra-estrutura de controle de acesso. importante observar que os elementos dessa estrutura so componentes lgicos, que no impem uma forma de implementao rgida. Por exemplo, em um sistema operacional convencional, o sistema de arquivos possui sua prpria estrutura de controle de acesso, com permisses de acesso armazenadas nos prprios arquivos, e um pequeno monitor/mediador associado a algumas chamadas de sistema, como open e mmap. Outros recursos (como reas de memria ou semforos) possuem suas prprias regras e estruturas de controle de acesso, organizadas de forma diversa. 5.6.2 Controle de acesso em UNIX
Os sistemas operacionais do mundo UNIX implementam um sistema de ACLs bsico bastante rudimentar, no qual existem apenas trs sujeitos: user (o dono do recurso), group (um grupo de usurios ao qual o recurso est associado) e others (todos os demais
usurios do sistema). Para cada objeto existem trs possibilidades de acesso: read, write e execute, cuja semntica depende do tipo de objeto (arquivo, diretrio, socket de rede, rea de memria compartilhada, etc). Dessa forma, so necessrios apenas 9 bits por arquivo para denir suas permisses bsicas de acesso.
tipo (arquivo, diretrio, atalho, ...) permisses (proprietrio) permisses (grupo) permisses (terceiros) nmero de ligaes proprietrio grupo
tamanho em bytes data/hora da ltima modificao nome
Figura 16: Listas de controle de acesso em UNIX. A gura 16 apresenta uma listagem de diretrio tpica em UNIX. Nessa listagem, o arquivo hello-unix.c pode ser acessado em leitura e escrita por seu proprietrio (o usurio maziero, com permisses rw-), em leitura pelos usurios do grupo prof (permisses r--) e em leitura pelos demais usurios do sistema (permisses r--). J o arquivo hello-unix pode ser acessado em leitura, escrita e execuo por seu proprietrio (permisses rwx), em leitura e execuo pelos usurios do grupo prof (permisses r-x) e no pode ser acessado pelos demais usurios (permisses ---). No caso de diretrios, a permisso de leitura autoriza a listagem do diretrio, a permisso de escrita autoriza sua modicao (criao, remoo ou renomeao de arquivos ou sub-diretrios) e a permisso de execuo autoriza usar aquele diretrio como diretrio de trabalho ou parte de um caminho. importante destacar que o controle de acesso normalmente realizado apenas durante a abertura do arquivo, para a criao de seu descritor em memria. Isso signica que, uma vez aberto um arquivo por um processo, este ter acesso ao arquivo enquanto o mantiver aberto, mesmo que as permisses do arquivo sejam modicadas para impedir esse acesso. O controle contnuo de acesso a arquivos pouco freqentemente implementado em sistemas operacionais, porque vericar as permisses de acesso a cada operao de leitura ou escrita teria um forte impacto negativo sobre o desempenho do sistema. Dessa forma, um descritor de arquivo aberto pode ser visto como uma capacidade (vide Seo 5.2.4), pois a posse do descritor permite ao processo acessar o arquivo referenciado por ele. O processo recebe esse descritor ao abrir o arquivo e deve apresent-
lo a cada acesso subseqente; o descritor pode ser transferido aos processos lhos ou at mesmo a outros processos, outorgando a eles o acesso ao arquivo aberto. A mesma estratgia usada em sockets de rede, semforos e outros mecanismos de IPC. O padro POSIX 1003.1e deniu ACLs mais detalhadas para o sistema de arquivos, que permitem denir permisses para usurios e grupos especcos alm do proprietrio do arquivo. Esse padro parcialmente implementado em vrios sistemas operacionais, como o Linux e o FreeBSD. No Linux, os comandos getfacl e setfacl permitem manipular essas ACLs, como mostra o exemplo a seguir:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
host:~> ll -rw-r--r-- 1 maziero prof 2450791 2009-06-18 10:47 main.pdf host:~> getfacl main.pdf # file: main.pdf # owner: maziero # group: maziero user::rwgroup::r-other::r-host:~> setfacl -m diogo:rw,rafael:rw main.pdf host:~> getfacl main.pdf # file: main.pdf # owner: maziero # group: maziero user::rwuser:diogo:rwuser:rafael:rwgroup::r-mask::rwother::r--
No exemplo, o comando da linha 12 dene permisses de leitura e escrita especcas para os usurios diogo e rafael sobre o arquivo main.pdf. Essas permisses estendidas so visveis na linha 19 e 20, junto com as permisses UNIX bsicas (nas linhas 18, 21 e 23). 5.6.3 Controle de acesso em Windows
Os sistemas Windows baseados no ncleo NT (NT, 2000, XP, Vista e sucessores) implementam mecanismos de controle de acesso bastante sosticados [Brown, 2000, Russinovich and Solomon, 2004]. Em um sistema Windows, cada sujeito (computador, usurio, grupo ou domnio) unicamente identicado por um identicador de segurana (SID - Security IDentier). Cada sujeito do sistema est associado a um token de acesso, criado no momento em que o respectivo usurio ou sistema externo se autentica no sistema. A autenticao e o incio da sesso do usurio so gerenciados pelo LSASS (Local Security Authority Subsystem), que cria os processos iniciais e os associa ao token de acesso
criado para aquele usurio. Esse token normalmente herdado pelos processos lhos, at o encerramento da sesso do usurio. Ele contm o identicador do usurio (SID), dos grupos aos quais ele pertence, privilgios a ele associados e outras informaes. Privilgios so permisses para realizar operaes genricas, que no dependem de um recurso especco, como reiniciar o computador, carregar um driver ou depurar um processo. Por outro lado, cada objeto do sistema est associado a um descritor de segurana (SD Security Descriptor). Como objetos, so considerados arquivos e diretrios, processos, impressoras, servios e chaves de registros, por exemplo. Um descritor de segurana indica o proprietrio e o grupo primrio do objeto, uma lista de controle de acesso de sistema (SACL - System ACL), uma lista de controle de acesso discricionria (DACL Discretionary ACL) e algumas informaes de controle. A DACL contm uma lista de regras de controle de acesso ao objeto, na forma de ACEs (Access Control Entries). Cada ACE contm um identicador de usurio ou grupo, um modo de autorizao (positiva ou negativa), um conjunto de permisses (ler, escrever, executar, remover, etc), sob a forma de um mapa de bits. Quando um sujeito solicita acesso a um recurso, o SRM (Security Reference Monitor) compara o token de acesso do sujeito com as entradas da DACL do objeto, para permitir ou negar o acesso. Como sujeitos podem pertencer a mais de um grupo e as ACEs podem ser positivas ou negativas, podem ocorrer conitos entre as ACEs. Por isso, um mecanismo de resoluo de conitos acionado a cada acesso solicitado ao objeto. A SACL dene que tipo de operaes sobre o objeto devem ser registradas pelo sistema, sendo usada basicamente para para ns de auditoria (Seo 6). A estrutura das ACEs de auditoria similar das ACEs da DACL, embora dena quais aes sobre o objeto em questo devem ser registradas para quais sujeitos. A gura 17 ilustra alguns dos componentes da estrutura de controle de acesso dos sistemas Windows.
usurio logon sujeito recurso solicitao de acesso acesso autorizado
Local Security Authority Subsystem
processo ou thread
Security Reference Monitor
AT
eventos access token Token ID Owner SID Group1 SID Group2 SID ... Flags Privileges ... eventos
SD
security descriptor Revision number Owner SID Group SID Flags DACL ACE ACE ACE ACE ... SACL ACE ACE ACE ACE ...
registros de auditoria
registros de auditoria
Figura 17: Listas de controle de acesso no Windows.
5.6.4
Outros mecanismos
As polticas de segurana bsicas utilizadas na maioria dos sistemas operacionais so discricionrias, baseadas nas identidades dos usurios e em listas de controle de acesso. Entretanto, polticas de segurana mais sosticadas vm sendo gradualmente agregadas aos sistemas operacionais mais complexos, visando aumentar sua segurana. Algumas iniciativas dignas de nota so apresentadas a seguir: O SELinux um mecanismo de controle de acesso multi-polticas, desenvolvido pela NSA (National Security Agency, USA) [Loscocco and Smalley, 2001] a partir da arquitetura exvel de segurana Flask (Flux Advanced Security Kernel) [Spencer et al., 1999]. Ele constitui uma infra-estrutura complexa de segurana para o ncleo Linux, capaz de aplicar diversos tipos de polticas obrigatrias aos recursos do sistema operacional. A poltica default do SELinux baseada em RBAC e DTE, mas ele tambm capaz de implementar polticas de segurana multi-nvel. O SELinux tem sido criticado devido sua complexidade, que torna difcil sua compreenso e congurao. Em conseqncia, outros projetos visando adicionar polticas MAC mais simples e fceis de usar ao ncleo Linux tm sido propostos, como LIDS, SMACK e AppArmor. O sistema operacional Windows Vista incorpora uma poltica denominada Mandatory Integrity Control (MIC) que associa aos processos e recursos os nveis de integridade Low, Medium, High e System [Microsoft, 2007], de forma similar ao modelo de Biba (Seo 5.3.2). Os processos normais dos usurios so classicados como de integridade mdia, enquanto o navegador Web e executveis provindos da Internet so classicados como de integridade baixa. Alm disso, o Vista conta com o UAC (User Account Control) que aplica uma poltica baseada em RBAC: um usurio com direitos administrativos inicia sua sesso como usurio normal, e somente ativa seu papel administrativo quando necessita efetuar uma ao administrativa. O projeto TrustedBSD [Watson, 2001] implementa ACLs no padro POSIX, capacidades POSIX e o suporte a polticas obrigatrias como Bell LaPadula, Biba, categorias e TE/DTE. Uma verso deste projeto foi portada para o MacOS X, sendo denominada MacOS X MAC Framework. Desenvolvido nos anos 90, o sistema operacional experimental EROS (Extremely Reliable Operating System) [Shapiro and Hardy, 2002] implementou um modelo de controle de acesso totalmente baseado em capacidades. Nesse modelo, todas as interfaces dos componentes do sistema s so acessveis atravs de capacidades, que so usadas para nomear as interfaces e para controlar seu acesso. O sistema EROS deriva de desenvolvimentos anteriores feitos no sistema operacional KeyKOS para a plataforma S/370 [Bomberger et al., 1992]. Em 2009, o sistema operacional experimental SeL4, que estende o sistema microncleo L4 [Liedtke, 1996] com um modelo de controle de acesso baseado em capacidades similar ao utilizado no sistema EROS, tornou-se o primeiro sistema operacional cuja segurana foi formalmente vericada [Klein et al., 2009]. A
Mudana de privilgios 49
vericao formal uma tcnica de engenharia de software que permite demonstrar matematicamente que a implementao do sistema corresponde sua especicao, e que a especicao est completa e sem erros. O sistema Trusted Solaris [Sun Microsystems, 2000] implementa vrias polticas de segurana: em MLS (Multi-Level Security), nveis de segurana so associados aos recursos do sistema e aos usurios. Alm disso, a noo de domnios implementada atravs de compartimentos: um recurso associado a um determinado compartimento s pode ser acessado por sujeitos no mesmo compartimento. Para limitar o poder do super-usurio, usada uma poltica de tipo RBAC, que divide a administrao do sistema em vrios papis de podem ser atribudos a usurios distintos.
5.7
Mudana de privilgios
Normalmente, os processos em um sistema operacional so sujeitos que representam o usurio que os lanou. Quando um novo processo criado, ele herda as credenciais de seu processo-pai, ou seja, seus identicadores de usurio e de grupo. Na maioria dos mecanismos de controle de acesso usados em sistemas operacionais, as permisses so atribudas aos processos em funo de suas credenciais. Com isso, normalmente cada novo processo herda as mesmas permisses de seu processo-pai, pois possui as mesmas credenciais dele. O uso de privilgios xos adequado para o uso normal do sistema, pois os processos de cada usurio s devem ter acesso aos recursos autorizados para esse usurio. Entretanto, em algumas situaes esse mecanismo se mostra inadequado. Por exemplo, caso um usurio precise executar uma tarefa administrativa, como instalar um novo programa, modicar uma congurao de rede ou atualizar sua senha, alguns de seus processos devem possuir permisses para as aes necessrias, como editar arquivos de congurao do sistema. Os sistemas operacionais atuais oferecem diversas abordagens para resolver esse problema: Usurios administrativos : so associadas permisses administrativas s sesses de trabalho de alguns usurios especcos, permitindo que seus processos possam efetuar tarefas administrativas, como instalar softwares ou mudar conguraes. Esta a abordagem utilizada em alguns sistemas operacionais de amplo uso. Algumas implementaes denem vrios tipos de usurios administrativos, com diferentes tipos de privilgios, como acessar dispositivos externos, lanar mquinas virtuais, reiniciar o sistema, etc. Embora simples, essa soluo falha, pois se algum programa com contedo malicioso for executado por um usurio administrativo, ter acesso a todas as suas permisses. Permisses temporrias : conceder sob demanda a certos processos do usurio as permisses de que necessitam para realizar aes administrativas; essas permisses podem ser descartadas pelo processo assim que concluir as aes. Essas permisses podem estar associadas a papis administrativos (Seo 5.5), ativados quando o usurio tiver necessidade deles. Esta a abordagem usada pela infra-estrutura UAC (User Access Control) [Microsoft, 2007], na qual um usurio administrativo
inicia sua sesso de trabalho como usurio normal, e somente ativa seu papel administrativo quando necessita efetuar uma ao administrativa, desativando-o imediatamente aps a concluso da ao. A ativao do papel administrativo pode impor um procedimento de reautenticao. Mudana de credenciais : permitir que certos processos do usurio mudem de identidade, assumindo a identidade de algum usurio com permisses sucientes para realizar a ao desejada; pode ser considerada uma variante da atribuio de permisses temporrias. O exemplo mais conhecido de implementao desta abordagem so os ags setuid e setgid do UNIX, explicados a seguir. Monitores : denir processos privilegiados, chamados monitores ou supervisores, recebem pedidos de aes administrativas dos processos no-privilegiados, atravs de uma API pr-denida; os pedidos dos processos normais so validados e atendidos. Esta a abordagem denida como separao de privilgios em [Provos et al., 2003], e tambm usada na infra-estrutura PolicyKit, usada para autorizar tarefas administrativas em ambientes desktop Linux. Um mecanismo amplamente usado para mudana de credenciais consiste dos ags setuid e setgid dos sistemas UNIX. Se um arquivo executvel tiver o ag setuid habilitado (indicado pelo caractere s em suas permisses de usurio), seus processos assumiro as credenciais do proprietrio do arquivo. Portanto, se o proprietrio de um arquivo executvel for o usurio root, os processos lanados a partir dele tero todos os privilgios do usurio root, independente de quem o tiver lanado. De forma similar, processos lanados a partir de um arquivo executvel com o ag setgid habilitado tero as credenciais do grupo associado ao arquivo. A gura 18 ilustra esse mecanismo: o primeiro caso representa um executvel normal (sem esses ags habilitados); um processo lho lanado a partir do executvel possui as mesmas credenciais de seu pai. No segundo caso, o executvel pertence ao usurio root e tem o ag setuid habilitado; assim, o processo lho assume a identidade do usurio root e, em conseqncia, suas permisses de acesso. No ltimo caso, o executvel pertence ao usurio root e tem o ag setgid habilitado; assim, o processo lho pertencer ao grupo mail. Os ags setuid e setgid so muito utilizados em programas administrativos no UNIX, como troca de senha e agendamento de tarefas, sempre que for necessrio efetuar uma operao inacessvel a usurios normais, como modicar o arquivo de senhas. Todavia, esse mecanismo pode ser perigoso, pois o processo lho recebe todos os privilgios do proprietrio do arquivo, o que contraria o princpio do privilgio mnimo. Por exemplo, o programa passwd deveria somente receber a autorizao para modicar o arquivo de senhas (/etc/passwd) e nada mais, pois o super-usurio (root user) tem acesso a todos os recursos do sistema e pode efetuar todas as operaes que desejar. Se o programa passwd contiver erros de programao, ele pode ser induzido pelo seu usurio a efetuar aes no-previstas, visando comprometer a segurana do sistema (vide Seo 2.3). Uma alternativa mais segura aos ags setuid e setgid so os privilgios POSIX (POSIX Capabilities7 ), denidos no padro POSIX 1003.1e [Gallmeister, 1994]. Nessa
O padro POSIX usou indevidamente o termo capacidade para denir o que na verdade so privilgios associados aos processos. O uso indevido do termo POSIX Capabilities perdura at hoje em vrios sistemas, como o caso do Linux.
7

processo pai arquivo executvel
processo filho
Permisses e proprietrio/grupo do arquivo
flag setuid habilitado
flag setgid habilitado
Figura 18: Funcionamento dos ags setuid e setgid do UNIX. abordagem, o poder absoluto do super-usurio dividido em um grande nmero de pequenos privilgios especcos, que podem ser atribudos a certos processos do sistema. Como medida adicional de proteo, cada processo pode ativar/desativar os privilgios que possui em funo de sua necessidade. Vrios sistemas UNIX implementam privilgios POSIX, como o caso do Linux, que implementa: CAP_CHOWN: alterar o proprietrio de um arquivo qualquer; CAP_USER_DEV: abrir dispositivos; CAP_USER_FIFO: usar pipes (comunicao); CAP_USER_SOCK: abrir sockets de rede; CAP_NET_BIND_SERVICE: abrir portas de rede com nmero abaixo de 1024; CAP_NET_RAW: abrir sockets de baixo nvel (raw sockets); CAP_KILL: enviar sinais para processos de outros usurios. ... (outros +30 privilgios)
Auditoria 52
Para cada processo so denidos trs conjuntos de privilgios: Permitidos (P), Efetivos (E) e Herdveis (H). Os privilgios permitidos so aqueles que o processo pode ativar quando desejar, enquanto os efetivos so aqueles ativados no momento (respeitando-se E P). O conjunto de privilgios herdveis H usado no clculo dos privilgios transmitidos aos processos lhos. Os privilgios POSIX tambm podem ser atribudos a programas executveis em disco, substituindo os tradicionais (e perigosos) ags setuid e setgid. Assim, quando um executvel for lanado, o novo processo recebe um conjunto de privilgios calculado a partir dos privilgios atribudos ao arquivo executvel e aqueles herdados do processo-pai que o criou [Bovet and Cesati, 2005]. Um caso especial de mudana de credenciais ocorre em algumas circunstncias, quando necessrio reduzir as permisses de um processo. Por exemplo, o processo responsvel pela autenticao de usurios em um sistema operacional deve criar novos processos para iniciar a sesso de trabalho de cada usurio. O processo autenticador geralmente executa com privilgios elevados, para poder acessar a bases de dados de autenticao dos usurios, enquanto os novos processos devem receber as credenciais do usurio autenticado, que normalmente tem menos privilgios. Em UNIX, um processo pode solicitar a mudana de suas credenciais atravs da chamada de sistema setuid(), entre outras. Em Windows, o mecanismo conhecido como impersonation permite a um processo ou thread abandonar temporariamente seu token de acesso e assumir outro, para realizar uma tarefa em nome do sujeito correspondente [Russinovich and Solomon, 2004].
Auditoria
Na rea de segurana de sistemas, o termo auditar signica recolher dados sobre o funcionamento de um sistema ou aplicao e analis-los para descobrir vulnerabilidades ou violaes de segurana, ou para examinar violaes j constatadas, buscando suas causas e possveis conseqncias8 [Sandhu and Samarati, 1996]. Os dois pontos-chave da auditoria so portanto a coleta de dados e a anlise desses dados, que sero discutidas a seguir.
6.1
Coleta de dados
Um sistema computacional em funcionamento processa uma grande quantidade de eventos. Destes, alguns podem ser de importncia para a segurana do sistema, como a autenticao de um usurio (ou uma tentativa malsucedida de autenticao), uma mudana de credenciais, o lanamento ou encerramento de um servio, etc. Os dados desses eventos devem ser coletados a partir de suas fontes e registrados de forma adequada para a anlise e arquivamento. Dependendo da natureza do evento, a coleta de seus dados pode ser feita no nvel da aplicao, de sub-sistema ou do ncleo do sistema operacional: Aplicao : eventos internos aplicao, cuja semntica especca ao seu contexto. Por exemplo, as aes realizadas por um servidor HTTP, como pginas fornecidas,
8
A anlise de violaes j ocorridas comumente conhecida como anlise post-mortem.
Coleta de dados 53
pginas no encontradas, erros de autenticao, pedidos de operaes no suportadas, etc. Normalmente esses eventos so registrados pela prpria aplicao, muitas vezes usando formatos prprios para os dados. Sub-sistema : eventos no especcos a uma aplicao, mas que ocorrem no espao de usurio do sistema operacional. Exemplos desses eventos so a autenticao de usurios (ou erros de autenticao), lanamento ou encerramento de servios do sistema, atualizaes de softwares ou de bibliotecas, criao ou remoo de usurios, etc. O registro desses eventos normalmente ca a cargo dos processos ou bibliotecas responsveis pelos respectivos sub-sistemas. Ncleo : eventos que ocorrem dentro do ncleo do sistema, sendo inacessveis aos processos. o caso dos eventos envolvendo o hardware, como a deteco de erros ou mudana de conguraes, e de outros eventos internos do ncleo, como a criao de sockets de rede, semforos, rea de memria compartilhada, reinicializao do sistema, etc. Um aspecto importante da coleta de dados para auditoria sua forma de representao. A abordagem mais antiga e comum, amplamente disseminada, o uso de arquivos de registro (logles). Um arquivo de registro contm uma sequncia cronolgica de descries textuais de eventos associados a uma fonte de dados, geralmente uma linha por evento. Um exemplo clssico dessa abordagem so os arquivos de registro do sistema UNIX; a listagem a seguir apresenta um trecho do contedo do arquivo /var/log/security, geralmente usado para reportar eventos associados autenticao de usurios:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
... Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep ...
8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8
23:02:09 23:19:57 23:34:14 23:57:16 00:08:16 00:35:24 00:42:19 00:49:06 00:53:40 00:53:55 01:08:43 01:12:41 01:12:41 01:12:41 01:38:26 02:18:29 02:18:29 02:18:29 09:06:33 06:06:34 06:06:34 06:06:57
espec espec espec espec espec espec espec espec espec espec espec espec espec espec espec espec espec espec espec espec espec espec
sudo: e89602174 : user NOT in sudoers ; TTY=pts/1 ; USER=root ; COMMAND=/bin/su userhelper[20480]: running /sbin/halt with user_u:system_r:hotplug_t context sshd[6302]: pam_unix(sshd:auth): failure; rhost=210.210.102.173 user=root sshd[6302]: Failed password for root from 210.103.210.173 port 14938 ssh2 sshd[6303]: Received disconnect from 210.103.210.173: 11: Bye Bye gdm[9447]: pam_unix(gdm:session): session opened for user rodr by (uid=0) gdm[857]: pam_unix(gdm:session): session closed for user rafael3 userhelper[11031]: running /sbin/halt with user_u:system_r:hotplug_t context gdm[12199]: pam_unix(gdm:session): session opened for user rafael3 by (uid=0) gdm[12199]: pam_unix(gdm:session): session closed for user rafael3 gdm[9447]: pam_unix(gdm:session): session closed for user rodr sshd[14125]: Accepted password for rodr from 189.30.227.212 port 1061 ssh2 sshd[14125]: pam_unix(sshd:session): session opened for user rodr by (uid=0) sshd[14127]: subsystem request for sftp sshd[14125]: pam_unix(sshd:session): session closed for user rodr sshd[17048]: Accepted password for e89062004 from 20.0.0.56 port 54233 ssh2 sshd[17048]: pam_unix(sshd:session): session opened for user e89062004 by (uid=0) sshd[17048]: pam_unix(sshd:session): session closed for user e89062004 sshd[25002]: Postponed publickey for mzr from 159.71.224.62 port 52372 ssh2 sshd[25001]: Accepted publickey for mzr from 159.71.224.62 port 52372 ssh2 sshd[25001]: pam_unix(sshd:session): session opened for user mzr by (uid=0) su: pam_unix(su-l:session): session opened for user root by mzr(uid=500)
A infra-estrutura tradicional de registro de eventos dos sistemas UNIX constituda por um daemon9 chamado syslogd (System Log Daemon). Esse daemon usa um socket local
Processo que executa em segundo plano, sem estar associado a uma interface com o usurio, como um terminal ou janela.
9
Coleta de dados 54
e um socket UDP para receber mensagens descrevendo eventos, geradas pelos demais sub-sistemas e aplicaes atravs de uma biblioteca especca. Os eventos so descritos por mensagens de texto e so rotulados por suas fontes em servios (AUTH, KERN, MAIL, etc) e nveis (INFO, WARNING, ALERT, etc). A partir de seu arquivo de congurao, o processo syslogd registra a data de cada evento recebido e decide seu destino: armazenar em um arquivo, enviar a um terminal, avisar o administrador, ativar um programa externo ou enviar o evento a um daemon em outro computador so as principais possibilidades. A gura 19 apresenta os principais componentes dessa arquitetura.
terminal servio de e-mail servio SSH servio de autenticao
root:~> syslog: system reboot syslog: shutdown now terminal
syslogd
eventos
rede
servio de impresso
kernel logger eventos do ncleo
logfiles
Illenihild ubitatquin Illenihild ullamscientiam ubitatquin habet(Nadaduvi Illenihild ullamscientiam daquemnadasabe ubitatquin habet(Nadaduvi )Illenihildubi ullamscientiam daquemnadasabe tatquinullamsc habet(Nadaduvi )Illenihildubi ientiamhabet(N daquemnadasabe tatquinullamsc adaduvidaquemn )Illenihildubi ientiamhabet(N adasabe)Illeni tatquinullamsc adaduvidaquemn hildubitatquin ientiamhabet(N adasabe)Illeni ullamscientiam adaduvidaquemn hildubitatquin habet(Nadaduvi adasabe)Illeni ullamscientiam hildubitatquin habet(Nadaduvi ullamscientiam habet(Nadaduvi
syslogd
ncleo
Figura 19: O servio de logs em UNIX. Os sistemas Windows mais recentes usam uma arquitetura similar, embora mais sosticada do ponto de vista do formato dos dados, pois os eventos so descritos em formato XML (a partir do Windows Vista). O servio Windows Event Log assume o papel de centralizador de eventos, recebendo mensagens de vrias fontes, entre elas os componentes do subsistema de segurana (LSASS e SRM, Seo 5.6.3), as aplicaes e o prprio ncleo. Conforme visto anteriormente, o componente LSASS gera eventos relativos autenticao dos usurios, enquanto o SRM registra os acessos a cada objeto de acordo com as regras de auditoria denidas em sua SACL (System ACLs). Alm disso, aplicaes externas podem se registrar junto ao sistema de logs para receber eventos de interesse, atravs de uma interface de acesso baseada no modelo publish/subscribe. Alm dos exemplos aqui apresentados, muitos sistemas operacionais implementam arquiteturas especcas para auditoria, como o caso do BSM (Basic Security Module) do sistema Solaris e sua implementao OpenBSM para o sistema operacional OpenBSD. O sistema MacOS X tambm prov uma infra-estrutura de auditoria, na qual o administrador pode registrar os eventos de seu interesse e habilitar a gerao de registros. Alm da coleta de eventos do sistema medida em que eles ocorrem, outras formas de coleta de dados para auditoria so freqentes. Por exemplo, ferramentas de segurana
Anlise de dados 55
podem vasculhar o sistema de arquivos em busca de arquivos com contedo malicioso, ou varrer as portas de rede para procurar servios suspeitos.
6.2
Anlise de dados
Uma vez registrada a ocorrncia de um evento de interesse para a segurana do sistema, deve-se proceder sua anlise. O objetivo dessa anlise sobretudo identicar possveis violaes da segurana em andamento ou j ocorridas. Essa anlise pode ser feita sobre os registros dos eventos medida em que so gerados (chamada anlise online) ou sobre registros previamente armazenados (anlise oine). A anlise online visa detectar problemas de segurana com rapidez, para evitar que comprometam o sistema. Como essa anlise deve ser feita simultaneamente ao funcionamento do sistema, importante que seja rpida e leve, para no prejudicar o desempenho do sistema nem interferir nas operaes em andamento. Um exemplo tpico de anlise online so os anti-vrus, que analisam os arquivos medida em que estes so acessados pelos usurios. Por sua vez, a anlise oine realizada com dados previamente coletados, possivelmente de vrios sistemas. Como no tem compromisso com uma resposta imediata, pode ser mais profunda e detalhada, permitindo o uso de tcnicas de minerao de dados para buscar correlaes entre os registros, que possam levar descoberta de problemas de segurana mais sutis. A anlise oine usada em sistemas de deteco de intruso, por exemplo, para analisar a histria do comportamento de cada usurio. Alm disso, frequentemente usada em sistemas de informao bancrios, para se analisar o padro de uso dos cartes de dbito e crdito dos correntista e identicar fraudes. As ferramentas de anlise de registros de segurana podem adotar basicamente duas abordagens: anlise por assinaturas ou anlise por anomalias. Na anlise por assinaturas, a ferramenta tem acesso a uma base de dados contendo informaes sobre os problemas de segurana conhecidos que deve procurar. Se algum evento ou registro se encaixar nos padres descritos nessa base, ele considerado uma violao de segurana. Um exemplo clssico dessa abordagem so os programas anti-vrus: um anti-vrus tpico varre o sistema de arquivos em busca de contedos maliciosos. O contedo de cada arquivo vericado junto a uma base de assinaturas, que contm descries detalhadas dos vrus conhecidos pelo software; se o contedo de um arquivo coincidir com uma assinatura da base, aquele arquivo considerado suspeito. Um problema com essa forma de anlise sua incapacidade de detectar novas ameaas, como vrus desconhecidos, cuja assinatura no esteja na base. Por outro lado, uma ferramenta de anlise por anomalias conta com uma base de dados descrevendo o que se espera como comportamento ou contedo normal do sistema. Eventos ou registros que no se encaixarem nesses padres de normalidade so considerados como violaes potenciais da segurana, sendo reportados ao administrador do sistema. A anlise por anomalias, tambm chamada de anlise baseada em heursticas, utilizada em certos tipos de anti-vrus e sistemas de deteco de intruso, para detectar vrus ou ataques ainda desconhecidos. Tambm muito usada em sistemas de informao bancrios, para detectar fraudes envolvendo o uso das contas e cartes
Auditoria preventiva 56
bancrios. O maior problema com esta tcnica caracterizar corretamente o que se espera como comportamento normal, o que pode ocasionar muitos erros.
6.3
Auditoria preventiva
Alm da coleta e anlise de dados sobre o funcionamento do sistema, a auditoria pode agir de forma preventiva, buscando problemas potenciais que possam comprometer a segurana do sistema. H um grande nmero de ferramentas de auditoria, que abordam aspectos diversos da segurana do sistema, entre elas [Peeger and Peeger, 2006]: Vulnerability scanner: verica os softwares instalados no sistema e confronta suas verses com uma base de dados de vulnerabilidades conhecidas, para identicar possveis fragilidades. Pode tambm investigar as principais conguraes do sistema, com o mesmo objetivo. Como ferramentas deste tipo podem ser citadas: Nessus Security Scanner e SAINT (System Administrators Integrated Network Tool). Port scanner: analisa as portas de rede abertas em um computador remoto, buscando identicar os servios de rede oferecidos pela mquina, as verses do softwares que atendem esses servios e a identicao do prprio sistema operacional subjacente. O NMap provavelmente o scanner de portas mais conhecido atualmente. Password cracker: conforme visto na Seo 4.3, as senhas dos usurios de um sistema so armazenadas na forma de resumos criptogrcos, para aumentar sua segurana. Um quebrador de senhas tem por nalidade tentar descobrir as senhas dos usurios, para avaliar sua robustez. A tcnica normalmente usada por estas ferramentas o ataque do dicionrio, que consiste em testar um grande nmero de palavras conhecidas, suas variantes e combinaes, confrontando seus resumos com os resumos das senhas armazenadas. Quebradores de senhas bem conhecidos so o John the Ripper para UNIX e Cain and Abel para ambientes Windows. Rootkit scanner: visa detectar a presena de rootkits (vide Seo 2.2) em um sistema, normalmente usando uma tcnica oine baseada em assinaturas. Como os rootkits podem comprometer at o ncleo do sistema operacional instalado no computador, normalmente as ferramentas de deteco devem ser aplicadas a partir de outro sistema, carregado a partir de uma mdia externa convel (CD ou DVD). Vericador de integridade: a segurana do sistema operacional depende da integridade do ncleo e dos utilitrios necessrios administrao do sistema. Os vericadores de integridade so programas que analisam periodicamente os principais arquivos do sistema operacional, comparando seu contedo com informaes previamente coletadas. Para agilizar a vericao de integridade so utilizadas somas de vericao (checksums) ou resumos criptogrcos como o MD5 e SHA1. Essa vericao de integridade pode se estender a outros objetos do sistema, como a tabela de chamadas de sistema, as portas de rede abertas, os processos de sistema em execuo, o cadastro de softwares instalados, etc. Um exemplo clssico de ferramenta de vericao de integridade o Tripwire [Tripwire, 2003], mas existem diversas outras ferramentas mais recentes com propsitos similares.
REFERNCIAS 57
Questes
1. ... 2. ... 3. ...
Exerccios
1. ... 2. ... 3. ...
Projetos
1. ... 2. ... 3. ...
Referncias
[Amoroso, 1994] Amoroso, E. (1994). Fundamentals of Computer Security Technology. Prentice Hall PTR. [Avizienis et al., 2004] Avizienis, A., Laprie, J.-C., Randell, B., and Landwehr, C. (2004). Basic Concepts and Taxonomy of Dependable and Secure Computing. IEEE Transactions on Dependable and Secure Computing, 1(1). [Badger et al., 1995] Badger, L., Sterne, D., Sherman, D., Walker, K., and Haghighat, S. (1995). Practical Domain and Type Enforcement for UNIX. In IEEE Symposium on Security and Privacy, pages 6677. [Bell and LaPadula, 1974] Bell, D. E. and LaPadula, L. J. (1974). Secure computer systems. mathematical foundations and model. Technical Report M74-244, MITRE Corporation. [Biba, 1977] Biba, K. (1977). Integrity considerations for secure computing systems. Technical Report MTR-3153, MITRE Corporation. [Boebert and Kain, 1985] Boebert, W. and Kain, R. (1985). A practical alternative to hierarchical integrity policies. In 8th National Conference on Computer Security, pages 1827.
REFERNCIAS 58
[Bomberger et al., 1992] Bomberger, A., Frantz, A., Frantz, W., Hardy, A., Hardy, N., Landau, C., and Shapiro, J. (1992). The KeyKOS nanokernel architecture. In USENIX Workshop on Micro-Kernels and Other Kernel Architectures, pages 95112. [Bovet and Cesati, 2005] Bovet, D. and Cesati, M. (2005). Understanding the Linux Kernel, 3rd edition. OReilly Media, Inc. [Brown, 2000] Brown, K. (2000). Programming Windows Security. Addison-Wesley Professional. [Cowan et al., 2000] Cowan, C., Beattie, S., Kroah-Hartman, G., Pu, C., Wagle, P., and Gligor, V. (2000). SubDomain: Parsimonious server security. In 14th USENIX Systems Administration Conference. [di Vimercati et al., 2007] di Vimercati, S., Foresti, S., Jajodia, S., and Samarati, P. (2007). Access control policies and languages in open environments. In Yu, T. and Jajodia, S., editors, Secure Data Management in Decentralized Systems, volume 33 of Advances in Information Security, pages 2158. Springer. [di Vimercati et al., 2005] di Vimercati, S., Samarati, P., and Jajodia, S. (2005). Policies, Models, and Languages for Access Control. In Workshop on Databases in Networked Information Systems, volume LNCS 3433, pages 225237. Springer-Verlag. [Gallmeister, 1994] Gallmeister, B. (1994). POSIX.4: Programming for the Real World. OReilly Media, Inc. [Jain et al., 2004] Jain, A., Ross, A., and Prabhakar, S. (2004). An Introduction to Biometric Recognition. IEEE Transactions on Circuits and Systems for Video Technology, 14(1). [Klein et al., 2009] Klein, G., Elphinstone, K., Heiser, G., Andronick, J., Cock, D., Derrin, P., Elkaduwe, D., Engelhardt, K., Kolanski, R., Norrish, M., Sewell, T., Tuch, H., and Winwood, S. (2009). SeL4: Formal verication of an OS kernel. In 22nd ACM Symposium on Operating Systems Principles, Big Sky, MT, USA. [Lampson, 1971] Lampson, B. (1971). Protection. In 5th Princeton Conference on Information Sciences and Systems. Reprinted in ACM Operating Systems Rev. 8, 1 (Jan. 1974), pp 18-24. [Lichtenstein, 1997] Lichtenstein, S. (1997). A review of information security principles. Computer Audit Update, 1997(12):924. [Liedtke, 1996] Liedtke, J. (1996). Toward real microkernels. Communications of the ACM, 39(9):7077. [Loscocco and Smalley, 2001] Loscocco, P. and Smalley, S. (2001). Integrating Flexible Support for Security Policies into the Linux Operating System. In USENIX Annual Technical Conference, pages 2942. [Menezes et al., 1996] Menezes, A., Van Oorschot, P., and Vanstone, S. (1996). Handbook of Applied Cryptography. CRC Press.
REFERNCIAS 59
[Microsoft, 2007] Microsoft (2007). Security Enhancements in Windows Vista. Microsoft Corporation. [Mitnick and Simon, 2002] Mitnick, K. D. and Simon, W. L. (2002). The Art of Deception: Controlling the Human Element of Security. John Wiley & Sons, Inc., New York, NY, USA. [Mollin, 2000] Mollin, R. A. (2000). An Introduction to Cryptography. CRC Press, Inc., Boca Raton, FL, USA. [Neuman and Tso, 1994] Neuman, B. C. and Tso, T. (1994). Kerberos: An authentication service for computer networks. IEEE Communications Magazine, 32(9):3338. [Neuman et al., 2005] Neuman, C., Yu, T., Hartman, S., and Raeburn, K. (2005). The Kerberos Network Authentication Service (V5). RFC 4120 (Proposed Standard). Updated by RFCs 4537, 5021. [Peeger and Peeger, 2006] Peeger, C. and Peeger, S. L. (2006). Security in Computing, 4th Edition. Prentice Hall PTR. [Provos et al., 2003] Provos, N., Friedl, M., and Honeyman, P. (2003). Preventing privilege escalation. In 12th USENIX Security Symposium. [Russinovich and Solomon, 2004] Russinovich, M. and Solomon, D. (2004). Microsoft Windows Internals, Fourth Edition: Microsoft Windows Server 2003, Windows XP, and Windows 2000. Microsoft Press. [Saltzer and Schroeder, 1975] Saltzer, J. and Schroeder, M. (1975). The protection of information in computer systems. Proceedings of the IEEE, 63(9):1278 1308. [Samarati and De Capitani di Vimercati, 2001] Samarati, P. and De Capitani di Vimercati, S. (2001). Access control: Policies, models, and mechanisms. In Focardi, R. and Gorrieri, R., editors, Foundations of Security Analysis and Design, volume 2171 of LNCS. Springer-Verlag. [Sandhu et al., 1996] Sandhu, R., Coyne, E., Feinstein, H., and Youman, C. (1996). Role-based access control models. IEEE Computer, 29(2):3847. [Sandhu and Samarati, 1996] Sandhu, R. and Samarati, P. (1996). Authentication, access control, and audit. ACM Computing Surveys, 28(1). [Shapiro and Hardy, 2002] Shapiro, J. and Hardy, N. (2002). Eros: a principle-driven operating system from the ground up. Software, IEEE, 19(1):2633. [Shirey, 2000] Shirey, R. (2000). RFC 2828: Internet security glossary. [Spencer et al., 1999] Spencer, R., Smalley, S., Loscocco, P., Hibler, M., Andersen, D., and Lepreau, J. (1999). The Flask security architecture: System support for diverse security policies. In 8th USENIX Security Symposium, pages 123139. [Sun Microsystems, 2000] Sun Microsystems (2000). Trusted Solaris Users Guide. Sun Microsystems, Inc.
REFERNCIAS 60
[Tripwire, 2003] Tripwire (2003). http://www.tripwire.org.
The
Tripwire
open
source
project.
[Watson, 2001] Watson, R. (2001). TrustedBSD: Adding trusted operating system features to FreeBSD. In USENIX Technical Conference.

So Cap08

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

So Cap08

Загружено:

Авторское право:

Доступные форматы

Sistemas Operacionais VIII - Aspectos de Segurana

Prof. Carlos Alberto Maziero DAInf UTFPR http://dainf.ct.utfpr.edu.br/maziero 18 de novembro de 2011

c prof. Carlos Maziero

c prof. Carlos Maziero

5.6.4 Outros mecanismos . . . . . . . . . . . . . . . . . . . . . . . . . . Mudana de privilgios . . . . . . . . . . . . . . . . . . . . . . . . . . . .

c prof. Carlos Maziero

c prof. Carlos Maziero

Propriedades e princpios de segurana 5

Propriedades e princpios de segurana

c prof. Carlos Maziero

Propriedades e princpios de segurana 6

c prof. Carlos Maziero

c prof. Carlos Maziero

A execuo desse cdigo gera o seguinte resultado:

host:~> cc buffer-overflow.c -o buffer-overflow host:~> buffer-overflow i: 21 j: 35005211 k: 0

c prof. Carlos Maziero

c prof. Carlos Maziero

#include <unistd.h> int main() { while (1) fork() ; }

// lao infinito // reproduz o processo

c prof. Carlos Maziero

c prof. Carlos Maziero

c prof. Carlos Maziero

c prof. Carlos Maziero

processos threads transaes

outros sujeitos ou sistemas

polticas de controle de acesso

c prof. Carlos Maziero

Criptograa simtrica e assimtrica 15

Criptograa simtrica e assimtrica

c prof. Carlos Maziero

Criptograa simtrica e assimtrica 16

a chave secreta transferida atravs de um meio seguro

c prof. Carlos Maziero

Criptograa simtrica e assimtrica 17

c prof. Carlos Maziero

4: envio do texto cifrado

chave pblica chave privada

2: Alice obtm a chave pblica de Beto

1: Beto divulga sua chave pblica

Beto Carol Davi

Figura 5: Exemplo de uso da criptograa assimtrica.

c prof. Carlos Maziero

maziero:~> md5sum * 62ec3f9ff87f4409925a582120a40131 0920785a312bd88668930f761de740bf 45acbba4b57317f3395c011fbd43d68d 6c332adb037265a2019077e09a024d0c

header.tex main.pdf main.tex main.tex~

maziero:~> sha1sum * 742c437692369ace4bf0661a8fe5741f03ecb31a 9f9f52f48b75fd2f12fa297bdd5e1b13769a3139 d6973a71e5c30d0c05d762e9bc26bb073d377a0b cf1670f22910da3b9abf06821e44b4ad7efb5460

header.tex main.pdf main.tex main.tex~

c prof. Carlos Maziero

Certicado de chave pblica 20

documento assinado por Alice

6fce39f0908827 ca54cdf5889068 7f734aef674d2a

cifrar Alice Chaveiro pblico decifrar 7

chave privada chave pblica 1

chave pblica de Alice

Figura 6: Assinatura e vericao de uma assinatura digital.

Certicado de chave pblica

c prof. Carlos Maziero

Certicado de chave pblica 21

c prof. Carlos Maziero

chave pblica AC raiz

Figura 7: Infra-estrutura de chaves pblicas hierrquica.

c prof. Carlos Maziero

c prof. Carlos Maziero

c prof. Carlos Maziero