Sistemas Operacionais VIII - Aspectos de Segurança

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(GNUFree 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 Introduo 4
2 Conceitos bsicos 4
2.1 Propriedades e princpios de segurana . . . . . . . . . . . . . . . . . . . 5
2.2 Ameaas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3 Vulnerabilidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4 Ataques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.5 Malwares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.6 Infraestrutura de segurana . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3 Fundamentos de criptograa 14
3.1 Cifragem e decifragem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2 Criptograa simtrica e assimtrica . . . . . . . . . . . . . . . . . . . . . . 15
3.3 Resumo criptogrco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.4 Assinatura digital . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.5 Certicado de chave pblica . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4 Autenticao 22
4.1 Usurios e grupos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.2 Tcnicas de autenticao . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.3 Senhas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.4 Senhas descartveis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.5 Desao-resposta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.6 Certicados de autenticao . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.7 Tcnicas biomtricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.8 Kerberos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.9 Infra-estruturas de autenticao . . . . . . . . . . . . . . . . . . . . . . . . 31
5 Controle de acesso 32
5.1 Polticas, modelos e mecanismos de controle de acesso . . . . . . . . . . 33
5.2 Polticas discricionrias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.2.1 Matriz de controle de acesso . . . . . . . . . . . . . . . . . . . . . 35
5.2.2 Tabela de autorizaes . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.2.3 Listas de controle de acesso . . . . . . . . . . . . . . . . . . . . . . 36
5.2.4 Listas de capacidades . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.3 Polticas obrigatrias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.3.1 Modelo de Bell-LaPadula . . . . . . . . . . . . . . . . . . . . . . . 39
5.3.2 Modelo de Biba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.3.3 Categorias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.4 Polticas baseadas em domnios . . . . . . . . . . . . . . . . . . . . . . . . 41
5.5 Polticas baseadas em papis . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.6 Mecanismos de controle de acesso . . . . . . . . . . . . . . . . . . . . . . 43
5.6.1 Infra-estrutura bsica . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.6.2 Controle de acesso em UNIX . . . . . . . . . . . . . . . . . . . . . 44
5.6.3 Controle de acesso em Windows . . . . . . . . . . . . . . . . . . . 46
c prof. Carlos Maziero SUMRIO 3
5.6.4 Outros mecanismos . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.7 Mudana de privilgios . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6 Auditoria 52
6.1 Coleta de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.2 Anlise de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.3 Auditoria preventiva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
c prof. Carlos Maziero 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.
1 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.
2 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
c prof. Carlos Maziero 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 segu-
rana 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 se-
gurana 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.
c prof. Carlos Maziero 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 infor-
mao 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.
c prof. Carlos Maziero Ameaas 7
2.2 Ameaas
Como ameaa, pode ser considerada qualquer ao que coloque em risco as pro-
priedades 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 ope-
racional 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, im-
plementao, 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:
umerro 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 umusurio ouda 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
c prof. Carlos Maziero 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 #include <stdio.h>
2 #include <stdlib.h>
3
4 int i, j, buffer[20], k; // declara buffer[0] a buffer[19]
5
6 int main()
7 {
8 i = j = k = 0 ;
9
10 for (i = 0; i<= 20; i++) // usa buffer[0] a buffer[20] <-- erro!
11 buffer[i] = random() ;
12
13 printf ("i: %d\nj: %d\nk: %d\n", i, j, k) ;
14
15 return(0);
16 }
A execuo desse cdigo gera o seguinte resultado:
1 host:~> cc buffer-overflow.c -o buffer-overflow
2 host:~> buffer-overflow
3 i: 21
4 j: 35005211
5 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 sucessiva
1
, 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.
1
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.
c prof. Carlos Maziero 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.
Almdos 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 com-
ponentes 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. Almdisso, os ataques a umsistema 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 exploramvulnerabilidades emprogramas 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
c prof. Carlos Maziero Ataques 10
interrupo
fonte destino
atacante
interceptao
fonte destino
atacante
modificao
fonte destino
atacante
fabricao
fonte destino
atacante
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 #include <unistd.h>
2
3 int main()
4 {
5 while (1) // lao infinito
6 fork() ; // reproduz o processo
7 }
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
c prof. Carlos Maziero 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 ativi-
dades 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 replicao
2
. 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 aopersonagemda mitologia grega, umcavalode 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
2
De forma anloga, um vrus biolgico precisa de uma clula hospedeira, pois usa o material celular
como suporte para sua existncia e replicao.
c prof. Carlos Maziero 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 : umprograma 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 compu-
tador 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 conside-
rados 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
c prof. Carlos Maziero 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 umsistema 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.
c prof. Carlos Maziero Fundamentos de criptograa 14
I11enihi1d
ubiaquin
u11amscieniam
habe(Nadaduvi
daquemnadasabe
)I11enihi1dubi
aquinu11amsc
ieniamhabe(N
adaduvidaquemn
adasabe)I11eni
hi1dubiaquin
u11amscieniam
habe(Nadaduvi
autenticao
controle
de acesso
autenticao controle de acesso usurios recursos
I11enihi1d
ubiaquin
u11amscieniam
habe(Nadaduvi
daquemnadasabe
)I11enihi1dubi
aquinu11amsc
ieniamhabe(N
adaduvidaquemn
adasabe)I11eni
hi1dubiaquin
u11amscieniam
habe(Nadaduvi
I11enihi1d
ubiaquin
u11amscieniam
habe(Nadaduvi
daquemnadasabe
)I11enihi1dubi
aquinu11amsc
ieniamhabe(N
adaduvidaquemn
adasabe)I11eni
hi1dubiaquin
u11amscieniam
habe(Nadaduvi
outros
sujeitos
ou
sistemas
registros
arquivos
processos
threads
transaes
humanos
sistemas
externos
dados de
auditoria
dados de
autenticao
polticas
de controle
de acesso
evento evento
auditoria auditoria
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).
3 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
c prof. Carlos Maziero 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: Reunir todos os generais para o ataque
mensagem cifrada com k = 1: Sfvojs upept pt hfofsbjt qbsb p bubrvf
mensagem cifrada com k = 2: Tgwpkt vqfqu qu igpgtcku rctc q cvcswg
mensagem cifrada com k = 3: Uhxqlu wrgrv rv jhqhudlv sdud r dwdtxh
Para decifrar uma mensagemno 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 Au-
guste 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 princ-
pios, 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 2
128
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
k
0
= x () k
0
= 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.
cifrar decifrar
texto aberto
texto cifrado
chave secreta
texto aberto
6d034072696a6e6461656c2d31
3238002000636263006d63727970
742d7368613100157290d14234f6
fce39f0908827c54cdf58890687f
7368613100ff56dfb2015aae6f33
86a6acbd051a33562699a2d97623
ca974d8cc5d986b6c48fba534eab
2eb4d39273910b72c869c54521c1
c5df85cb3a37d2aaa6f19b560ead
a9eb92c5e8e95
I11e nihi1 dubia qui
nu11am scieniam habe
(Nada duvida quem nada sabe)
chave secreta
a chave secreta transferida
atravs de um meio seguro
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
k
= x () k = kv(u)
{ { x }
kv(u)
}
1
k
= x () k = kp(u)
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.
cifrar decifrar
texto aberto
texto cifrado
chave pblica
texto aberto
chave privada
6d034072696a6e6461656c2d31
3238002000636263006d63727970
742d7368613100157290d14234f6
fce39f0908827c54cdf58890687f
7368613100ff56dfb2015aae6f33
86a6acbd051a33562699a2d97623
2eb4d39273910b72c869c54521c1
a9eb92c5e8e95
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 Beto
3
. 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.
3
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.
c prof. Carlos Maziero Resumo criptogrco 18
3: cifrar 5: decifrar
Beto
texto aberto
chave pblica chave privada
Alice Beto Carol Davi
Chaveiro pblico
Alice
6d034072696a6e6461656c2d31
3238002000636263006d63727970
742d7368613100157290d14234f6
fce39f0908827c54cdf58890687f
7368613100ff56dfb2015aae6f33
86a6acbd051a33562699a2d97623
2eb4d39273910b72c869c54521c1
a9eb92c5e8e95
texto cifrado
texto aberto
1: Beto divulga
sua chave pblica
2: Alice obtm a chave
pblica de Beto
4: envio do texto cifrado
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.
Emtermos matemticos, os resumos criptogrcos so umtipo 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 dgitos
4
.
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
0
geram o mesmo valor de resumo (hash(x) =
hash(x
0
) para x , x
0
). 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
4
Em 2005, um grupo de pesquisadores alemes fatorizou um inteiro com 200 dgitos, usando 80
processadores Opteron calculando durante mais de de cinco meses.
c prof. Carlos Maziero 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 maziero:~> md5sum *
2 62ec3f9ff87f4409925a582120a40131 header.tex
3 0920785a312bd88668930f761de740bf main.pdf
4 45acbba4b57317f3395c011fbd43d68d main.tex
5 6c332adb037265a2019077e09a024d0c main.tex~
6
7 maziero:~> sha1sum *
8 742c437692369ace4bf0661a8fe5741f03ecb31a header.tex
9 9f9f52f48b75fd2f12fa297bdd5e1b13769a3139 main.pdf
10 d6973a71e5c30d0c05d762e9bc26bb073d377a0b main.tex
11 cf1670f22910da3b9abf06821e44b4ad7efb5460 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
0
= hash(d) e compar-lo com o resumo
obtido da assinatura, decifrada usando a chave pblica de u (r
00
= {s}
1
kp(u)
). Se ambos
forem iguais (r
0
= r
00
), 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 kp
a
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 kv
a
, obtendo uma assinatura
digital s;
4. A assinatura s e o documento original d, em conjunto, constituem o documento
assinado por Alice: [d, s];
c prof. Carlos Maziero Certicado de chave pblica 20
5. Beto obtm o documento assinado por Alice ([d
0
, s
0
], com d
0
= d e s
0
= s se ambos
estiverem ntegros);
6. Beto recalcula o resumo digital r
0
= hash(d
0
) do documento, usando o mesmo
algoritmo empregado por Alice;
7. Beto obtm a chave pblica kp
a
de Alice e a usa para decifrar a assinatura s
0
do
documento, obtendo um resumo r
00
(r
00
= r se s foi realmente cifrado com a chave
kv
a
e se s
0
= s) ;
8. Beto compara o resumo r
0
do documento com o resumo r
00
obtido da assinatura
digital; se ambos forem iguais (r
0
= r
00
), o documento foi assinado por Alice e est
ntegro, assim como sua assinatura.
hash
I11e nihi1
dubia qui
nu11am
scieniam
habe
(Nada duvida
quem
nada sabe)
Chaveiro pblico
Alice Beto Carol Davi
6fce39f0908827
ca54cdf5889068
7f734aef674d2a
resumo
I11e nihi1
dubia qui
nu11am
scieniam
habe
(Nada duvida
quem
nada sabe)
3423a2e67ba6fc
5b432c2d9f0588
4aef7f7362a74d
documento
assinado
por Alice
chave
pblica
chave
privada
chave pblica de Alice
Alice
cifrar
hash
decifrar
6fce39f0908827
ca54cdf5889068
7f734aef674d2a
6fce39f0908827
ca54cdf5889068
7f734aef674d2a
sim
2
3
5 4
6
8
7
1
r'=r'' ?
assinatura
vlida
r'
r''
s r
s'
d
d'
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]:
c prof. Carlos Maziero 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 considera-
das 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].
5
Deve-se ressaltar que um certicado pode pertencer a um usurio humano, a um sistema computaci-
onal ou qualquer mdulo de software que precise ser identicado de forma inequvoca.
c prof. Carlos Maziero Autenticao 22
AC raiz
j s f h d k d s k f d s j h k s d
f h
kds l k ds ljk lsd lsd
29-05-2009
f h
29-05-2009
f h
29-05-2009 j s f h d k d s k f d s j h k s d
f h
29-05-2009
f h
29-05-2009 j s f h d k d s k f d s j h k s d
f h
29-05-2009
f h
29-05-2009
ACs
secundrias
chave pblica
identificao
assinatura
Figura 7: Infra-estrutura de chaves pblicas hierrquica.
4 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
c prof. Carlos Maziero 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 intrinse-
camente 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.
c prof. Carlos Maziero Senhas 24
Muitos sistemas implementam somente a autenticao por login/senha (SYK). Siste-
mas 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 implemen-
tam 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 sim-
ples (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.
Aautenticao 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
0
; o sistema ento calcular novamente seu resumo r
0
= hash(s
0
) e ir compar-lo
ao resumo previamente armazenado (r
0
= 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.
Casoumintrusotenha acessoaos resumos das senhas dos usurios, ele noconseguir
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 comaqueles presentes
no arquivo de senhas. Caso detecte algum resumo coincidente, ter encontrado a senha
correspondente. Oataque 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.
c prof. Carlos Maziero 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 Lam-
port [Menezes et al., 1996]. Ele consiste em criar uma sequncia de senhas
s
0
, s
1
, s
2
, , s
n
com s
0
aleatrio e s
i
= hash(s
i1
) 8i > 0, sendo hash(x) uma fun-
o de resumo criptogrco conhecida. O valor de s
n
informado ao servidor
previamente. Ao acessar o servidor, o cliente informa o valor de s
n1
. O servidor
pode ento comparar hash(s
n1
) com o valor de s
n
previamente informado: se
forem iguais, o cliente est autenticado e ambos podem descartar s
n
. O servidor
armazena s
n1
para validar a prxima autenticao, e assim sucessivamente. Um
intruso que conseguir capturar uma senha s
i
no poder us-la mais tarde, pois
no conseguir calcular s
i1
= hash
1
(s
i
).
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
c prof. Carlos Maziero 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
0
) e compara o resultado obtido r
0
= hash(s
0
+ d) com
a resposta r fornecida pelo cliente. Se ambos os resultados forem iguais, os segredos
so iguais (r = r
0
) s = s
0
) e o cliente considerado autntico. A gura 9 apresenta os
passos desse algoritmo.
solicita acesso
desafio(d)
resposta(r)
aceito/recusado
requisies (caso aceito)
r=hash(s+d)
r'=hash(s'+d)
aceito se r'=r
(implica s'=s)
t
define d
aleatrio
senha s senha s'
Cliente Servidor
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.
c prof. Carlos Maziero 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 cripto-
grco. 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 cripto-
graa 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 sooprincipal mecanismousadopara 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 identic-
lo 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 indiv-
duos 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;
c prof. Carlos Maziero Kerberos 28
Mensurabilidade: a caracterstica em questo deve ser facilmente mensurvel em
termos quantitativos.
As caractersticas biomtricas usadas em autenticao podem ser fsicas ou comporta-
mentais. 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
impresso digital padro de voz retina e ris
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 autenti-
cao 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
sensor
extrator de
caractersticas
sistema biomtrico
humanos
base de
dados
comparador autenticador
dados
biomtricos
caractersticas
relevantes
resultado (identificao ou autenticao)
senha
carto
etc.
identidade
coleta/registro
dados
biomtricos
usurios
cadastrados
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).
T2
client
server
Key Distribution Center
Authentication
Service
Ticket
Granting
Service
users/keys
database
1
2
3
4
5
6
T1
T1
T2
Figura 12: Viso geral do servio Kerberos.
No Kerberos, cada cliente c possui uma chave secreta k
c
registrada no servidor de
autenticao AS. Da mesma forma, cada servidor s tambm tem sua chave k
s
registrada
no AS. As chaves so simtricas, usando cifragem DES, e somente so conhecidas por
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 m
1
contm sua identidade (c), a identidade do servio desejado (tgs), um prazo de
validade solicitado (ts) e um nmero aleatrio (n
1
) que ser usado para vericar se
a resposta do AS corresponde ao pedido efetuado:
m
1
= [c tgs ts n
1
]
2. A resposta do AS (mensagem m
2
) contm duas partes: a primeira parte contm
a chave de sesso a ser usada na comunicao com o TGS (k
ctgs
) e o nmero
aleatrio n
1
, ambos cifrados com a chave do cliente k
c
registrada no AS; a segunda
parte um ticket cifrado com a chave do TGS (k
tgs
), contendo a identidade do
cliente (c), o prazo de validade do ticket concedido pelo AS (tv) e uma chave de
sesso k
ctgs
, a ser usada na interao com o TGS:
m
2
= [{k
ctgs
n
1
}
k
c
T
ctgs
] onde T
ctgs
= {c tv k
ctgs
}
k
tgs
O ticket T
ctgs
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 m
2
, o cliente tem acesso chave de sesso k
ctgs
e ao
ticket TGT. Todavia, esse ticket cifrado com a chave k
tgs
e portanto somente o
TGS poder abr-lo.
3. A seguir, o cliente envia uma solicitao ao TGS (mensagem m
3
) 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 k
ctgs
, o ticket
TGT recebido em m
2
, a identidade do servidor s e um nmero aleatrio n
2
:
m
3
= [{c t}
k
ctgs
T
ctgs
s n
2
]
4. Aps vericar a validade do ticket TGT, o TGS devolve ao cliente uma mensagem
m
4
contendo a chave de sesso k
cs
a ser usada no acesso ao servidor s e o nmero
aleatrio n
2
informado em m
3
, ambos cifrados com a chave de sesso k
ctgs
, e um
ticket T
cs
cifrado, que deve ser apresentado ao servidor s:
m
4
= [{k
cs
n}
k
ctgs
T
cs
] onde T
cs
= {c tv k
cs
}
k
s
5. O cliente usa a chave de sesso k
cs
e o ticket T
cs
para se autenticar junto ao
servidor s atravs da mensagem m
5
. Essa mensagem contm a identidade do
cliente (c) e a data atual (t), ambos cifrados com a chave de sesso k
cs
, o ticket T
cs
recebido em m
4
e o pedido de servio ao servidor (request), que dependente da
aplicao:
m
5
= [{c t}
k
cs
T
cs
request]
c prof. Carlos Maziero Infra-estruturas de autenticao 31
6. Ao receber m
5
, o servidor s decifra o ticket T
cs
para obter a chave de sesso k
cs
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 k
cs
:
m
6
= [{reply}
k
cs
]
Enquanto o ticket de servio T
cs
for vlido, o cliente pode enviar solicitaes ao
servidor sem a necessidade de se reautenticar. Da mesma forma, enquanto o ticket T
ctgs
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 k
ctgs
e k
cs
circularamemaberto atravs da rede. Almdisso, 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 autenticaosocoerentes
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 infra-
estruturas 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);
c prof. Carlos Maziero 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.
API padronizada
l
o
g
i
n
/
s
e
n
h
a
c
e
r
t
i
f
i
c
a
d
o
s
e
n
d
e
r
e
o

I
P
b
i
o
m
e
t
r
i
a
.
.
.
aplicaes e/ou servios
Figura 13: Estrutura genrica de uma infra-estrutura de autenticao.
5 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
c prof. Carlos Maziero 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 estive-
rem 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].
c prof. Carlos Maziero 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 discricion-
rias, 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 imple-
mentao 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 hs, o, +ai ou hs, o, ai, 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 si
6
.
6
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].
f ile
1
f ile
2
program
1
socket
1
Alice read read execute write
write write
remove
Beto read read read
write write
remove
Carol read execute read
write
Davi read append read 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 discrici-
onrias 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 = {s
1
, s
2
, . . . , s
m
}, um conjunto de objetos O = {o
1
, o
2
, . . . , o
n
} e
um conjunto de aes possveis sobre os objetos A = {a
1
, a
2
, . . . , a
p
}, cada elemento M
i j
da matriz de controle de acesso um sub-conjunto (que pode ser vazio) do conjunto de
aes possveis, que dene as aes que s
i
2 S pode efetuar sobre o
j
2 O:
8s
i
2 S, 8o
j
2 O, M
i j
A
Por exemplo, considerando um conjunto de sujeitos S = {Alice, Beto, Carol, Davi},
um conjunto de objetos O = { f ile
1
, f ile
2
, program
1
, socket
1
} 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.
f ile
1
f ile
2
program
1
socket
1
Alice read read execute write
write write
remove
owner
Beto read read read
write write owner
remove
owner
Carol read execute read
write
Davi read write read 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 ile
1
) = { Alice : (read, write, remove, owner),
Beto : (read, write),
Davi : (read) }
ACL( f ile
2
) = { Alice : (read, write),
Beto : (read, write, remove, owner),
Carol : (read),
Davi : (write) }
ACL(program
1
) = { Alice : (execute),
Sujeito Objeto Ao
Alice f ile
1
read
Alice f ile
1
write
Alice f ile
1
remove
Alice f ile
1
owner
Alice f ile
2
read
Alice f ile
2
write
Alice program
1
execute
Alice socket
1
write
Beto f ile
1
read
Beto f ile
1
write
Beto f ile
2
read
Beto f ile
2
write
Beto f ile
2
remove
Beto f ile
2
owner
Beto program
1
read
Beto socket
1
owner
Carol f ile
2
read
Carol program
1
execute
Carol socket
1
read
Carol socket
1
write
Davi f ile
1
read
Davi f ile
2
write
Davi program
1
read
Davi socket
1
read
Davi socket
1
write
Davi socket
1
owner
Tabela 3: Tabela de autorizaes
Beto : (read, owner),
Carol : (execute),
Davi : (read) }
ACL(socket
1
) = { Alice : (write),
Carol : (read, write),
Davi : (read, write, owner) }
Esta forma de implementao a mais freqentemente usada em sistemas opera-
cionais, 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 ile
1
: (read, write, remove, owner),
f ile
2
: (read, write),
program
1
: (execute),
socket
1
: (write) }
CL(Beto) = { f ile
1
: (read, write),
f ile
2
: (read, write, remove, owner),
program
1
: (read, owner) }
CL(Carol) = { f ile
2
: (read),
program
1
: (execute),
socket
1
: (read, write) }
CL(Davi) = { f ile
1
: (read),
f ile
2
: (write),
program
1
: (read),
socket
1
: (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
c prof. Carlos Maziero 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 consig-
nado.
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(s
i
)) 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:
c prof. Carlos Maziero 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, oupropriedade simples de integridade): impede
que um sujeito escreva em objetos acima de seu nvel de integridade, preservando-
os 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, umsujeito comintegridade alta (A)
somente pode ler objetos com integridade alta (A) ou de sistema (S). Formalmente,
temos:
request(s, o, read) () i(s) i(o)
c prof. Carlos Maziero Polticas baseadas em domnios 41
A poltica obrigatria denida atravs do modelo de Biba evita violaes de integri-
dade, 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 compar-
timentos. 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 cate-
gorias {suporte, f inanceiro} s pode acessar objetos rotulados como {suporte, f inanceiro},
{suporte}, { f inanceiro} ou {}. Formalmente: sendo C(s) o conjunto de categorias associa-
das 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
Odomnio de segurana de umsujeito 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 emuma 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 2 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
c prof. Carlos Maziero 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(s
i
, s
j
, interaction) () interaction 2 DIT[domain(s
i
), 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
tipagemimplcita: todos os objetos que satisfazemumcerto critrio (como por exemplo ter
como caminho /usr/local/*) so automaticamente classicados em um dado tipo. Da
mesma forma, os domnios podemser 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 umconjunto 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 permitemdesacoplar os usurios das permisses. Por isso, umconjunto 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.
Existemvrios modelos para a implementao de polticas baseadas empapis, 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.
c prof. Carlos Maziero Mecanismos de controle de acesso 43
professor
usurios
outros
sujeitos
ou
sistemas
registros
arquivos
diretor
aluno
suporte
papis permisses objetos ativaes
I11enihi1d
ubiaquin
u11amscieniam
habe(Nadaduvi
daquemnadasabe
)I11enihi1dubi
aquinu11amsc
ieniamhabe(N
adaduvidaquemn
adasabe)I11eni
hi1dubiaquin
u11amscieniam
habe(Nadaduvi
I11enihi1d
ubiaquin
u11amscieniam
habe(Nadaduvi
daquemnadasabe
)I11enihi1dubi
aquinu11amsc
ieniamhabe(N
adaduvidaquemn
adasabe)I11eni
hi1dubiaquin
u11amscieniam
habe(Nadaduvi
I11enihi1d
ubiaquin
u11amscieniam
habe(Nadaduvi
daquemnadasabe
)I11enihi1dubi
aquinu11amsc
ieniamhabe(N
adaduvidaquemn
adasabe)I11eni
hi1dubiaquin
u11amscieniam
habe(Nadaduvi
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 com-
pem 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.
mediador
monitor de
referncias
sujeitos objetos
outros
sujeitos
ou
sistemas
arquivos
processos
threads
transaes
base de
polticas
sujeito,
objeto,
ao
deciso
base de
objetos
base de
sujeitos
informaes externas
(horrio, etc)
acessos
aes
nega
permite
eventos
I11enihi1d
ubiaquin
u11amscieniam
habe(Nadaduvi
daquemnadasabe
)I11enihi1dubi
aquinu11amsc
ieniamhabe(N
adaduvidaquemn
adasabe)I11eni
hi1dubiaquin
u11amscieniam
habe(Nadaduvi
para os registros
de auditoria
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)
proprietrio
grupo
data/hora da ltima modificao
nome
tamanho em bytes
nmero de ligaes
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 emleitura, 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 emmemria. 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. Oprocesso 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 permitemdenir permisses para usurios e grupos especcos almdo 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 host:~> ll
2 -rw-r--r-- 1 maziero prof 2450791 2009-06-18 10:47 main.pdf
3
4 host:~> getfacl main.pdf
5 # file: main.pdf
6 # owner: maziero
7 # group: maziero
8 user::rw-
9 group::r--
10 other::r--
11
12 host:~> setfacl -m diogo:rw,rafael:rw main.pdf
13
14 host:~> getfacl main.pdf
15 # file: main.pdf
16 # owner: maziero
17 # group: maziero
18 user::rw-
19 user:diogo:rw-
20 user:rafael:rw-
21 group::r--
22 mask::rw-
23 other::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. Aautenticao 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.
I11enihi1d
ubiaquin
u11amscieniam
habe(Nadaduvi
daquemnadasabe
)I11enihi1dubi
aquinu11amsc
ieniamhabe(N
adaduvidaquemn
adasabe)I11eni
hi1dubiaquin
u11amscieniam
habe(Nadaduvi
usurio sujeito
processo
ou
thread
recurso
Token ID
Owner SID
Group1 SID
Group2 SID
...
Flags
Privileges
...
logon Security
Reference
Monitor
access
token
AT SD
security
descriptor
solicitao
de acesso
acesso
autorizado
Revision number
Owner SID
Group SID
Flags
DACL
...
ACE
ACE
ACE
ACE
SACL
...
ACE
ACE
ACE
ACE
Local
Security
Authority
Subsystem
eventos
registros
de
auditoria
eventos
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, desenvol-
vido 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 Man-
datory 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, ca-
pacidades 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
EROSderiva de desenvolvimentos anteriores feitos nosistema operacional KeyKOS
para a plataforma S/370 [Bomberger et al., 1992].
Em 2009, o sistema operacional experimental SeL4, que estende o sistema micro-
ncleo 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
c prof. Carlos Maziero 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 imple-
mentada 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 necessitampara realizar aes administrativas; essas permisses
podemser descartadas pelo processo assimque 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 iden-
tidade, 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, rece-
bem 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 admi-
nistrativas 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 Capabilities
7
), denidos no padro POSIX 1003.1e [Gallmeister, 1994]. Nessa
7
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.
arquivo executvel
I11enihi1d
ubiaquin
u11amscieniam
habe(Nadaduvi
daquemnadasabe
)I11enihi1dubi
aquinu11amsc
ieniamhabe(N
adaduvidaquemn
adasabe)I11eni
hi1dubiaquin
u11amscieniam
habe(Nadaduvi
Permisses e proprietrio/grupo do arquivo
I11enihi1d
ubiaquin
u11amscieniam
habe(Nadaduvi
daquemnadasabe
)I11enihi1dubi
aquinu11amsc
ieniamhabe(N
adaduvidaquemn
adasabe)I11eni
hi1dubiaquin
u11amscieniam
habe(Nadaduvi
I11enihi1d
ubiaquin
u11amscieniam
habe(Nadaduvi
daquemnadasabe
)I11enihi1dubi
aquinu11amsc
ieniamhabe(N
adaduvidaquemn
adasabe)I11eni
hi1dubiaquin
u11amscieniam
habe(Nadaduvi
flag setuid habilitado
flag setgid habilitado
processo pai processo filho
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 podemser 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)
c prof. Carlos Maziero 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 creden-
ciais 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 imper-
sonation 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].
6 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 conseqncias
8
[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.
c prof. Carlos Maziero Coleta de dados 53
pginas no encontradas, erros de autenticao, pedidos de operaes no supor-
tadas, 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 repre-
sentao. A abordagem mais antiga e comum, amplamente disseminada, o uso de
arquivos de registro (logles). Umarquivo de registro contmuma 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 Sep 8 23:02:09 espec sudo: e89602174 : user NOT in sudoers ; TTY=pts/1 ; USER=root ; COMMAND=/bin/su
3 Sep 8 23:19:57 espec userhelper[20480]: running /sbin/halt with user_u:system_r:hotplug_t context
4 Sep 8 23:34:14 espec sshd[6302]: pam_unix(sshd:auth): failure; rhost=210.210.102.173 user=root
5 Sep 8 23:57:16 espec sshd[6302]: Failed password for root from 210.103.210.173 port 14938 ssh2
6 Sep 8 00:08:16 espec sshd[6303]: Received disconnect from 210.103.210.173: 11: Bye Bye
7 Sep 8 00:35:24 espec gdm[9447]: pam_unix(gdm:session): session opened for user rodr by (uid=0)
8 Sep 8 00:42:19 espec gdm[857]: pam_unix(gdm:session): session closed for user rafael3
9 Sep 8 00:49:06 espec userhelper[11031]: running /sbin/halt with user_u:system_r:hotplug_t context
10 Sep 8 00:53:40 espec gdm[12199]: pam_unix(gdm:session): session opened for user rafael3 by (uid=0)
11 Sep 8 00:53:55 espec gdm[12199]: pam_unix(gdm:session): session closed for user rafael3
12 Sep 8 01:08:43 espec gdm[9447]: pam_unix(gdm:session): session closed for user rodr
13 Sep 8 01:12:41 espec sshd[14125]: Accepted password for rodr from 189.30.227.212 port 1061 ssh2
14 Sep 8 01:12:41 espec sshd[14125]: pam_unix(sshd:session): session opened for user rodr by (uid=0)
15 Sep 8 01:12:41 espec sshd[14127]: subsystem request for sftp
16 Sep 8 01:38:26 espec sshd[14125]: pam_unix(sshd:session): session closed for user rodr
17 Sep 8 02:18:29 espec sshd[17048]: Accepted password for e89062004 from 20.0.0.56 port 54233 ssh2
18 Sep 8 02:18:29 espec sshd[17048]: pam_unix(sshd:session): session opened for user e89062004 by (uid=0)
19 Sep 8 02:18:29 espec sshd[17048]: pam_unix(sshd:session): session closed for user e89062004
20 Sep 8 09:06:33 espec sshd[25002]: Postponed publickey for mzr from 159.71.224.62 port 52372 ssh2
21 Sep 8 06:06:34 espec sshd[25001]: Accepted publickey for mzr from 159.71.224.62 port 52372 ssh2
22 Sep 8 06:06:34 espec sshd[25001]: pam_unix(sshd:session): session opened for user mzr by (uid=0)
23 Sep 8 06:06:57 espec su: pam_unix(su-l:session): session opened for user root by mzr(uid=500)
24 ...
A infra-estrutura tradicional de registro de eventos dos sistemas UNIX constituda
por um daemon
9
chamado syslogd (System Log Daemon). Esse daemon usa um socket local
9
Processo que executa em segundo plano, sem estar associado a uma interface com o usurio, como
um terminal ou janela.
c prof. Carlos Maziero 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.
eventos
I11enihi1d
ubiaquin
u11amscieniam
habe(Nadaduvi
daquemnadasabe
)I11enihi1dubi
aquinu11amsc
ieniamhabe(N
adaduvidaquemn
adasabe)I11eni
hi1dubiaquin
u11amscieniam
habe(Nadaduvi
I11enihi1d
ubiaquin
u11amscieniam
habe(Nadaduvi
daquemnadasabe
)I11enihi1dubi
aquinu11amsc
ieniamhabe(N
adaduvidaquemn
adasabe)I11eni
hi1dubiaquin
u11amscieniam
habe(Nadaduvi
ncleo
servio de
autenticao
servio
de e-mail
kernel
logger
servio de
impresso
servio
SSH
syslogd
I11enihi1d
ubiaquin
u11amscieniam
habe(Nadaduvi
daquemnadasabe
)I11enihi1dubi
aquinu11amsc
ieniamhabe(N
adaduvidaquemn
adasabe)I11eni
hi1dubiaquin
u11amscieniam
habe(Nadaduvi
syslogd
logfiles
eventos do
ncleo
terminal
rede
roo:~>
sys1og: sysem reboo
sys1og: shudown now
terminal
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 implemen-
tam 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
c prof. Carlos Maziero 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, possivel-
mente 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 admi-
nistrador 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 emsistemas
de informao bancrios, para detectar fraudes envolvendo o uso das contas e cartes
c prof. Carlos Maziero 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
Almda 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 emumcomputador 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
podemcomprometer 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 inte-
gridade do ncleo e dos utilitrios necessrios administrao do sistema. Os
vericadores de integridade so programas que analisamperiodicamente os princi-
pais 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.
c prof. Carlos Maziero 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 Transacti-
ons 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.
[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,
3
rd
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 Informa-
tion 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.
[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. andTso, T. (1994). Kerberos: Anauthentication
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. andPeeger, 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 Vimer-
cati, 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.
[Tripwire, 2003] Tripwire (2003). The Tripwire open source project.
http://www.tripwire.org.
[Watson, 2001] Watson, R. (2001). TrustedBSD: Adding trusted operating system
features to FreeBSD. In USENIX Technical Conference.

Sistemas Operacionais VIII - Aspectos de Segurança

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Sistemas Operacionais VIII - Aspectos de Segurança

Transféré par

Droits d'auteur :

Formats disponibles

Sistemas Operacionais

VIII - Aspectos de Segurana

Vous aimerez peut-être aussi