2
Políticas, Modelos e Mecanismos de
Segurança
 O papel do controle de acesso
 Matriz de controle de acesso
 Resultados fundamentais
 Políticas de segurança
 Modelos de segurança
 Mecanismos e implementação
(C) 2005 Gustavo Motta
©2002-2004 Matt Bishop
1
Mecanismos e implementação (1)
 Princípios de projeto (1)
• Menor privilégio
• Defaults seguros na falha
• Mecanismo econômico
• Princípio da mediação completa
• Projeto aberto
• Separação de privilégios
• Menor mecanismo possível
• Princípio da aceitação psicológica
(C) 2005 Gustavo Motta
©2002-2004 Matt Bishop
2
Mecanismos e implementação (2)
 Princípios de projeto (2)
• Simplicidade
– Reduz as possibilidade de erro
– Reduz o potencial de inconsistências numa política ou num conjunto de políticas
– Facilita o entendimento
• Restrições
– Minimizar o acesso como meio de reduzir o poder de uma entidade
 Acessar apenas informações necessárias
– Inibir a comunicação desnecessária
(C) 2005 Gustavo Motta
©2002-2004 Matt Bishop
3
Mecanismos e implementação (3)
 Princípios de projeto (3)
• Princípio do menor privilégio
– Deve-se conceder a um sujeito somente os privilégios necessários para ele executar
suas tarefas
 Se um sujeito necessita de direitos para anexar informações num objeto, mas não alterálas, deveria-se dar direitos de append para ele e não direitos para escrita
– As funções do sujeito devem controlar a concessão de direitos, não a identidade
– Direitos devem ser concedidos conforme a necessidade, sendo descartados
imediatamente após a finalização da tarefa
 Na prática, a maioria dos sistemas não tem o nível de granularidade de privilégios
requerido para aplicar este princípio precisamente
– Requer o confinamento de
menor domínio de proteção possível4
(C) processos
2005 Gustavono
Motta
©2002-2004 Matt Bishop
Mecanismos e implementação (4)
 Princípios de projeto (4)
• Princípio do defaults seguros na falha
– A menos que seja concedido acesso explícito de um sujeito para um objeto, esse
acesso deve ser negado para o objeto
– O acesso a um objeto deve ser negado por default
 Por exemplo, na falha de um login, e. g., banco fora do ar, deve-se recusar o acesso
 Na leitura de um arquivo de configuração, considerar apenas as entradas legais e
descartar todas as outras, assumindo-se um default seguro
– Caso uma ação falhe, o sistema deve retroceder para o estado seguro inicial
 Caso o servidor de e-mail não possa mais criar arquivos no diretório de spool, ele deve
fechar a conexão de rede, reportar o erro e parar. Ele não deve tentar armazenar a
mensagem noutro local, expandindo seus privilégios para tal porque um atacante pode
(C)sobrescrever
2005 Gustavo arquivos
Motta
5
usar esta facilidade para
ou esgotar os discos num ataque dos
©2002-2004 Matt Bishop
Mecanismos e implementação (5)
 Princípios de projeto (5)
• Princípio do mecanismo econômico
– Os mecanismos de segurança devem ser os mais simples possíveis
– Projetos e implementações simples, menos possibilidades existem para erros
 Quando erros ocorrem, eles são mais fáceis de serem entendidos e consertados
 Definir todas as interfaces completamente
– Interfaces para outros módulos são suspeitas
 Módulos fazem suposições implícitas sobre e-s e o estado corrente do sistema
 Suposições infundadas podem produzir resultados inesperados
» O protocolo finger assume que a resposta de um servidor é bem formada, logo um atacante que
crie uma versão do protocolo que gera uma cadeia infinita de caracteres pode provocar uma
recusa de serviço pelo esgotamento arquivos de logs ou discos
 A interação com entidades externas, como programas, sistemas, pessoas amplificam este
(C) 2005 Gustavo Motta
6
problema
©2002-2004 Matt Bishop
Mecanismos e implementação (6)
 Princípios de projeto (6)
• Princípio da mediação completa
– Requer que todos os acessos a objetos sejam efetivamente verificados para
assegurar que eles são permitidos
– Limita a implementação de caches
– A primeira verificação de autorização de acesso a um objeto é realizada
 As verificações subseqüentes para o mesmo objeto resgatam do cache o resultado da
autorização anterior
 Caso os direitos de acesso do usuário sejam modificados nesse meio tempo, o
mecanismos de controle de acesso não perceberá
– Exemplos
 Descritores de arquivos, que incluem as LCAs, são cacheados no UNIX
 O DNS mantém um cache com informações de mapeamento nome de servidor –
Gustavocom
Mottaa associação de um IP forjado
7
endereço IP, que pode(C)
ser2005
adulterado
©2002-2004 Matt Bishop
Mecanismos e implementação (7)
 Princípios de projeto (7)
• Princípio do projeto aberto
– A segurança de um mecanismo não deve depender do sigilo sobre o seu projeto ou
implementação
– Não significa que o código fonte e projeto devam ser públicos
 Sigilo aumenta a segurança, mas a segurança de um mecanismo não deveria ser afetada
pela descoberta de sua implementação ou projeto
 Descobrir uma implementação pode não ser muito difícil
» Modo como o sistema funciona
» Engenharia reversa
» Dumpster diving
 Não se aplica ao sigilo de informações que não envolvem implementação ou projeto
» Chaves de criptografia
» Senhas
(C) 2005 Gustavo Motta
©2002-2004 Matt Bishop
8
Mecanismos e implementação (8)
 Princípios de projeto (8)
• Princípio do projeto aberto
– Exemplo
 CCS (Content Scrambling System) é um algoritmo de criptografia que protege filmes em
discos de DVD contra cópias não autorizadas
 Layout de chaves do DVD
» Ka
» hash(Kd)
» E(Kd, Kpi)
» ...
» E(Kd, Kpi)
» E(Kt, Kd)
 Baseava-se num algoritmo frágil, que, quando descoberto em 1999, frustrou as
expectativas da indústria
filmes
(C) de
2005
Gustavo Motta
©2002-2004 Matt Bishop
9
Mecanismos e implementação (9)
 Princípios de projeto (9)
• Princípio da separação de privilégio
– Um sistema não deve conceder permissão baseada numa única condição
– Equivalente ao princípio da separação de responsabilidades
 Para valores maiores que R$ 1.000,00, uma compra deve ser autorizada por duas pessoas
» As duas condições correspondem às autorizações dadas por duas pessoas distintas
– Exige um controle de acesso com granularidade fina sobre recursos
– Defesa em profundidade
 Castelos medievais
– Exemplo: assumir a conta do root no Unix de Berkeley
 Conhecer a senha do root
 Ser um usuário com GID 0
(C) 2005 Gustavo Motta
©2002-2004 Matt Bishop
10
Mecanismos e implementação (10)
 Princípios de projeto (10)
• Princípio do menor mecanismo comum
– Mecanismos usados para acessar recursos não devem ser compartilhados
– Informações podem fluir por canais compartilhados
 Canais ocultos
– Isolamento
 Uso de máquinas virtuais atende a este princípio
» KVM/370 – versão incrementada da IBM VM/370
 Sandboxes
» Java virtual machine
– Exemplos
 Percentual de CPU utilizados, de discos, etc
(C) 2005
Gustavo
 Criação de arquivos com
nomes
fixos Motta
©2002-2004 Matt Bishop
11
Mecanismos e implementação (11)
 Princípios de projeto (11)
• Princípio da aceitação psicológica
– Um mecanismo de segurança não deve tornar o acesso a um recurso mais difícil do
que aquele obtido sem o mecanismo
– Deve-se ocultar a complexidade introduzida pelos mecanismos de segurança
– Facilidade instalação, configuração e uso
– Fatores humanos são críticos
(C) 2005 Gustavo Motta
©2002-2004 Matt Bishop
12
Mecanismos e implementação (12)
 Princípios de projeto (12)
• Conclusão
– Os princípios para projetos são a base para todos os mecanismos relativos a
segurança
– Requer
 Bom entendimento do objetivo do mecanismo e do ambiente onde será usado
 Análise e projeto cuidadoso
 Implementação cuidadosa
(C) 2005 Gustavo Motta
©2002-2004 Matt Bishop
13
Mecanismos e implementação (13)
 Mecanismos de controle de acesso (1)
• Lista de controle de acesso (LCA)
• Capabilities
• Chave e cadeado
– Segredo compartilhado
• Controle de acesso baseado em anel
• Lista de controle de acesso propagada
(C) 2005 Gustavo Motta
©2002-2004 Matt Bishop
14
Mecanismos e implementação (14)
 Mecanismos de controle de acesso (2)
• Lista de controle de acesso (1)
– Cada objeto protegido tem um conjunto de pares associado
 Cada par contém um sujeito e um conjunto de direitos de acesso
 O sujeito só pode acessar o objeto de acordo com esses direitos
(C) 2005 Gustavo Motta
©2002-2004 Matt Bishop
15
Mecanismos e implementação (15)
 Mecanismos de controle de acesso (3)
• Lista de controle de acesso (2)
– Exemplo: colunas da matriz de controle de acesso
arquivo1 arquivo2 arquivo3
André
rx
r
Bia
rwxo
r
Carlos
rx
rwo
rwo
w
LCAs:
 arquivo1: { (André, rx) (Bia, rwxo) (Carlos, rx) }
 arquivo2: { (André, r) (Bia, r) (Carlos, rwo) }
 arquivo3: { (André, rwo) (Carlos, w) }
(C) 2005 Gustavo Motta
©2002-2004 Matt Bishop
16
Mecanismos e implementação (16)
 Mecanismos de controle de acesso (4)
• Lista de controle de acesso (3)
– Permissões default
– Normal: se não for explicitada, não tem direitos sobre o objeto
 Princípio do default seguro na falha
– Quando há muitos usuários, pode-se usar grupos ou casamento de padrões para
conceder permissões default
 Exemplo: UNICOS: LCA formadas por (user, group, rights)
» Caso user pertença a group, ele possui os direitos rights sobre o objeto protegido
» ‘*’ é o padrão para qualquer user, group
(Ana, *, r): Ana pode ler o objeto, qualquer que seja o seu grupo
(*, caixa, w): qualquer membro do grupo caixa pode escrever no objeto
(C) 2005 Gustavo Motta
©2002-2004 Matt Bishop
17
Mecanismos e implementação (17)
 Mecanismos de controle de acesso (5)
• Lista de controle de acesso (4)
– Abreviações
 LCAs podem ser longas … logo, os usuários podem ser combinados para reduzi-las
» Unix: 3 classes de usuários: proprietário, grupo do proprietário, os outros usuários
» rwx rwx rwx
outros
grupo
proprietário
» A propriedade é atribuída com base no processo criador
Alguns sistemas: se um diretório tem permissão setgid, o grupo do arquivo lá criado é
herdado do grupo do diretório (SunOS, Solaris)
(C) 2005 Gustavo Motta
©2002-2004 Matt Bishop
18
Mecanismos e implementação (18)
 Mecanismos de controle de acesso (6)
• Lista de controle de acesso (5)
– Abreviações + LCAs
 Abreviações como a do Unix carecem de uma granularidade fina
» Qualquer um, menos fulano
» Ana que conceder o direito de leitura para Joana, de escrita para Carolina, de leitura e escrita
para Dúnia e de execução para Elisa
» Isto não pode ser feito apenas com três classes de permissão
 Estender listas abreviadas com LCAs
» O objetivo é encurtar as LCAs
 LCAs sobrepõem as abreviações
» A forma exata varia
 Exemplo: IBM AIX
» As permissões básicas são abreviações, as permissões estendidas são LCAs com usuário, grupo
(C) 2005
Gustavo
Motta proibir, o acesso está proibido
19
» LCAs podem adicionar
direitos,
mas quando
©2002-2004 Matt Bishop
Mecanismos e implementação (19)
 Mecanismos de controle de acesso (7)
• Lista de controle de acesso (6)
– Abreviações + LCAs: exemplo no IBM AIX
attributes:
base permissions
owner(bishop):
rw-
group(sys):
others:
r----
extended permissions enabled
specify
rw-
u:holly
permit
-w-
u:heidi, g=sys
permit
rw-
u:matt
deny
-w-
u:holly, g=faculty
(C) 2005 Gustavo Motta
©2002-2004 Matt Bishop
20
Mecanismos e implementação (20)
 Mecanismos de controle de acesso (8)
• Lista de controle de acesso (7)
– Modificações das LCAs
 Quem pode fazer isto?
» Concede-se o direito own para o criador, que permite alterar a lista
» O sistema R prover um modificador grant (semelhante ao copy flag) que permite que um direito
seja transferido, de modo que o direito de propriedade não é necessário
A transferência de direitos para outros modifica a LCA
 As LCAs se aplicam aos usuários privilegiados (root ou administradores)?
» Solaris: listas abreviadas não, mas ACLs sim
» Outros produtos: varia
(C) 2005 Gustavo Motta
©2002-2004 Matt Bishop
21
Mecanismos e implementação (21)
 Mecanismos de controle de acesso (9)
• Lista de controle de acesso (8)
– Modificações das LCAs
 As LCAs suportam grupos e casamento de padrão?

Na forma clássica: não; na prática, quase sempre
•
AIX: as permissões base concederam apenas direito de leitura para o grupo sys. A linha
permit
-w-
u:heidi, g=sys
adiciona direito de escrita para heidi quando neste neste grupo
•
UNICOS:
– ana : caixa : r
 Usuário ana no grupo caixa pode ler o arquivo
– ana : * : r
 Usuário ana em qualquer grupo pode ler o arquivo
– * : caixa : r
(C) 2005 Gustavo Motta
 Qualquer
usuário
no grupo
©2002-2004
Matt
Bishopcaixa pode ler o arquivo
22
Mecanismos e implementação (22)
 Mecanismos de controle de acesso (10)
• Lista de controle de acesso (9)
– Modificações das LCAs
 Como são resolvidas as permissões contraditórias - conflitos?

Proibir o acesso se alguma permissão proíbe o acesso
•
AIX: se alguma permissão proíbe o acesso, independente dos direitos já
concedidos, o acesso é negado

Permitir o acesso se alguma permissão concede o acesso

Aplicar a primeira permissão encontrada
•
Roteadores Cisco: aplica a primeira entrada da LCA que case com o pacote de
entrada. Caso nenhuma se aplique, o pacote é rejeitado
–
(C)
2005é Gustavo
Motta o princípio do default seguro na falha
Note que por
default
negado, seguindo
©2002-2004 Matt Bishop
23
Mecanismos e implementação (23)
 Mecanismos de controle de acesso (11)
• Lista de controle de acesso (10)
– Modificações das LCAs
 Quando há permissões default, elas são modificadas pelas LCAs ou são usadas
apenas quando a LCA não menciona um sujeito explicitamente?

Aplica entrada da LCA, caso não seja possível, aplica o default
•
Roteador Cisco: aplica a regra da controle de acesso da ACL, caso não exista, usa a
regra default (proibir o acesso)

Defaults estendidos por ACLs
•
AIX: permissões estendidas aumentam as permissões base
(C) 2005 Gustavo Motta
©2002-2004 Matt Bishop
24
Mecanismos e implementação (24)
 Mecanismos de controle de acesso (12)
• Lista de controle de acesso (11)
– Revogação de direitos - Questão
 Como se removem os direitos de um sujeito sobre um arquivo?
» O proprietário remove as entradas relativas ao sujeito da LCA, ou apenas direitos específicos,
conforme o caso
 O que fazer quando não há proprietário?
» Depende do sistema
» Sistema R: restaura para o estado de proteção anterior a concessão do direito
Pode significar remover os direitos concedidos em cascata
(C) 2005 Gustavo Motta
©2002-2004 Matt Bishop
25
Mecanismos e implementação (25)
 Mecanismos de controle de acesso (13)
• Lista de controle de acesso (12)
– Exemplo: LCA do Windows NT
 Conjuntos de direitos de acesso diferentes
» Básicos: leitura, escrita, execução, exclusão, modificar permissão, tomar a
propriedade
» Genérico: nenhum acesso, leitura (leitura/execução), modificação
(leitura/escrita/execução/exclusão), controle total (todos), acesso especial (poder
para atribuir qualquer direito básico)
» Diretório: nenhum acesso, leitura (leitura/execução de arquivos no diretório), listar,
adição, adição e leitura, modificação (criação, adição, leitura, execução e escrita de
(C)de
2005
Gustavo Mottacontrole total, direitos especiais
arquivos; exclusão
subdiretórios),
©2002-2004 Matt Bishop
26
Mecanismos e implementação (26)
 Mecanismos de controle de acesso (14)
• Lista de controle de acesso (13)
– Exemplo: LCA do Windows NT
 Acesso a arquivos
» Caso o usuário não esteja em nenhuma LCA nem seja membro de grupo
presente na LCA: acesso proibido
» Alguma entrada da LCA proíbe explicitamente o acesso : acesso proibido
» Faça a união de todos os direitos que concedem o acesso para o usuário: o
usuário tem este conjunto de direitos sobre o arquivo
(C) 2005 Gustavo Motta
©2002-2004 Matt Bishop
27
Mecanismos e implementação (27)
 Mecanismos de controle de acesso (15)
• Capabilities (1)
– Cada sujeito tem um conjunto de pares associado
 Cada par contém um objeto protegido e um conjunto de direitos de acesso
 O sujeito só pode acessar o objeto de acordo com esses direitos
(C) 2005 Gustavo Motta
©2002-2004 Matt Bishop
28
Mecanismos e implementação (28)
 Mecanismos de controle de acesso (16)
• Capabilities – lista-C (2)
– Exemplo: linhas da matriz de controle de acesso
arquivo1 arquivo2 arquivo3
André
rx
r
Bia
rwxo
r
Carlos
rx
rwo
rwo
w
LCAs:
 André: { (arquivo1, rx) (arquivo2, r) (arquivo3, rwo) }
 Bia: { (arquivo1, rwxo) (arquivo2, r)}
 Carlos: { (arquivo1, rx) (arquivo2, rwo) (arquivo3, w)}
(C) 2005 Gustavo Motta
©2002-2004 Matt Bishop
29
Mecanismos e implementação (29)
 Mecanismos de controle de acesso (17)
• Capabilities – lista-C (3)
– Semântica
 Semelhante a um bilhete aéreo
» A simples posse indica os direitos que o sujeito tem sobre o objeto
» O objeto é identificado pela capability
O nome do objeto deve ser capaz de identificá-lo unicamente – referência,
localização, etc.
 Deve-se prevenir que processos possam forjar capabilities
» Do contrário, um usuário poderia modificar os direitos codificados na capability ou no objeto a
(C) 2005 Gustavo Motta
30
que se refere
©2002-2004 Matt Bishop
Mecanismos e implementação (30)
 Mecanismos de controle de acesso (18)
• Capabilities – lista-C (4)
– Implementação
 Arquitetura rotulada
» Bits protegem palavras individuais na memória
»
Bit setado – processo pode ler, mas não pode modificar a memória (palavra)
 Proteções baseadas em páginas ou segmentos
»
Colocam-se as capabilities em páginas (segmentos) que o processo pode ler, mas não modificar
 O acesso é feito indiretamente via apontadores
»
De outro modo, ele poderia
usar uma
cópia da
capability, que poderia ser adulterada
(C) 2005
Gustavo
Motta
©2002-2004 Matt Bishop
31
Mecanismos e implementação (31)
 Mecanismos de controle de acesso (20)
• Capabilities – lista-C (6)
– Implementação
–
Criptografia
 Associa a cada capability um código verificador criptografado com uma chave conhecida do SO
 Quando o processo apresenta a capability, o SO valida o código verificador
 Exemplo: Amœba, um sistema distribuído baseado em capabilities
»
Uma capability tem a forma (nome, servidor_criador, direitos, código-verificador) e é concedido ao
proprietário de um objeto
» código-verificador é um número randômico de 48-bits; também armazenado na tabela correspondente ao
servidor_criador
»
Para validação, o sistema compara o código-verificador da capability com aquele armazenado na tabela
servidor_criador
»
Um atacante precisa saber o número randômico para adulterar a capability, logo, o sistema é vulnerável à
(C) 2005 Gustavo Motta
32
descoberta da capability
©2002-2004 Matt Bishop
Mecanismos e implementação (32)
 Mecanismos de controle de acesso (21)
• Capabilities – lista-C (7)
– Cópia de capabilities
 Implica na capacidade de conceder direitos
» Usa-se um copy flag para prevenir um processo de distribuir capabilities de forma
indiscriminada
» Um processo não pode copiar uma capability para outro processo, a menos que o copy flag
esteja presente
» O copy flag pode ser desligado a critério do processo ou do núcleo
(C) 2005 Gustavo Motta
©2002-2004 Matt Bishop
33
Mecanismos e implementação (33)
 Mecanismos de controle de acesso (22)
• Capabilities – lista-C (8)
– Amplificação de capabilities
 Permite o aumento temporário de privilégios
 Necessário na programação modular com tipos abstratos de dados
» O módulo tem operações para empilhar e desempilhar dados na pilha
module stack ... endmodule.
» Uma variável x é declarada com o tipo stack
var x: stack;
» Apenas o módulo stack pode alterar ou ler x
O processo não possui esta capability, mas necessita dela quando referencia x
» Solução: conceder ao (C)
processo
capabilities
módulo
2005 as
Gustavo
Motta enquanto ele está executando operações no34
©2002-2004 Matt Bishop
Mecanismos e implementação (34)
 Mecanismos de controle de acesso (23)
• Capabilities – lista-C (9)
– Revogação de capabilities
 Requer a varredura de todas as listas-C para remover as capabilities relativas a um objeto
» Custo elevado
 Alternativa: uso da indireção
» Cada objeto possui uma entrada numa tabela global de objetos
» Nomes nas capabilities indicam a entrada na tabela, não o objeto real
- Para revogar, remove-se a entrada na tabela
- Pode-se ter múltiplas entradas para um mesmo objeto para permitir o controle de
diferentes conjuntos de direitos e/ou grupos de usuários para cada objeto
» Exemple: Amoeba: o proprietário pode requerer a mudança do número randômico na tabela
2005 Gustavo
- Todas as(C)
capabilities
para oMotta
objeto passam a ser inválidas
©2002-2004 Matt Bishop
35
Mecanismos e implementação (35)
 Mecanismos de controle de acesso (24)
• Capabilities – lista-C (10)
– Limites
• Problemas podem ocorrer caso não se possa controlar a cópia de capabilities
Hei di (Hi gh)
C-Lis t
r*lough
Lough (Low)
Hei di (Hi gh)
C-Lis t
r*lough
Lough (Low)
rw*lough
rw*lough
rw*lough
Lou (Low)
C-Lis t
rw*lough
Lou (Low)
C-Lis t
rw*lough
A capability para escrever no arquivo lough é Low, e Heidi é High, ela pode
ler (cópias) a capability; portanto, ela pode escrever num arquivo Low,
violando a propriedade-*!(C) 2005 Gustavo Motta
©2002-2004 Matt Bishop
36
Mecanismos e implementação (36)
 Mecanismos de controle de acesso (25)
• Capabilities × listas de controle de acesso
– Ambas são teoricamente equivalentes
 Dado um sujeito, quais objetos ele pode acessar e com quais direitos?
• Capabilities respondem com facilidade
 Dado um objeto, quais sujeitos pode acessá-lo e com quais direitos?
• LCAs respondem com facilidade
– Anteriormente, havia maior interesse em responder a segunda questão, razão pela
qual os sistemas baseados em LCAs se tornaram mais comum que aqueles baseados
em capabilities
 Isto pode mudar à medida
(C) 2005
que Gustavo
a primeira
Motta
questão torne-se mais importante
©2002-2004 Matt Bishop
37
Mecanismos e implementação (37)
 Mecanismos de controle de acesso (26)
• Chave e cadeado (1)
– Combina características LCAs e de capabilities
– Associa uma informação (cadeado) com um objeto e outra informação (chave) com
um sujeito
 A chave controla o que o sujeito pode acessar e como
 O sujeito apresenta a chave; caso ela corresponda a algum cadeado do objeto, o acesso é
concedido
– Isto pode ser dinâmico
 LCAs e C-Lists em geral são estáticas, devendo ser atualizadas manualmente
 Chaves e cadeados podem
(C) 2005
mudar
Gustavo
baseadas
Mottaem restrições no sistema ou em outros38fatores
©2002-2004 Matt Bishop
Mecanismos e implementação (38)
 Mecanismos de controle de acesso (27)
• Chave e cadeado (2)
– Implementação criptográfica
 A chave de criptografar é o cadeado
 A chave de decriptografar é a chave
» Criptografa o objeto o; armazena Ek(o)
» Usa-se a chave k do usuários para computar Dk(Ek(o))
» Qualquer um de n sujeitos pode acessar o: armazena-se
o = (E1(o), …, En(o))
or-access
» Requer o consentimento de n sujeitos para acessar o: armazena-se
o = (E1(E2(…(En(o))…))
(C) 2005 Gustavo Motta
©2002-2004 Matt Bishop
and-accesss
39
Mecanismos e implementação (39)
 Mecanismos de controle de acesso (29)
• Chave e cadeado (3)
– Exemplo: IBM 370
 Processos recebem uma chave de acesso e páginas têm uma chave de memória e um bit
de fetch
» Bit de fetch zerado: acesso apenas de leitura
» Bit de fetch 1, chave de acesso 0: o processo pode escrever na página (qualquer uma)
» Bit de fetch 1, chave de acesso casa com a chave de memória: o processo pode escrever na
página
» Bit de fetch 1, chave de acesso diferente de zero e não casa com a chave de memória : nenhum
acesso é permitido (C) 2005 Gustavo Motta
©2002-2004 Matt Bishop
40
Mecanismos e implementação (40)
 Mecanismos de controle de acesso (30)
• Chave e cadeado (4)
– Exemplo: roteador Cisco
 Listas de controle de acesso dinâmicas
access-list 100 permit tcp any host 10.1.1.1 eq telnet
access-list 100 dynamic test timeout 180 permit ip any host \
10.1.2.3 time-range my-time
time-range my-time
periodic weekdays 9:00 to 17:00
line vty 0 2
login local
autocommand access-enable host timeout 10
 Limita o acesso para 10.1.2.3 no intervalo 9AM–5PM
» Adiciona uma entrada temporária para a conexão para o servidor, uma vez que o usuário tenha
fornecido nome e senha válidos para o roteador
» Conexões válidas por 180 minutos
(C) 2005 Gustavo Motta
- Excluída©2002-2004
da LCA depois
prazo
Mattdeste
Bishop
41
Mecanismos e implementação (41)
 Mecanismos de controle de acesso (31)
• Chave e cadeado (5)
– Verificação de tipos
 Exemplo: a chamada de sistema para escrita no Unix não funciona para o objeto
diretório, mas funciona para os que são arquivos
 Exemplo: separação dos espaços de Instruções & Dados do PDP-11
 Exemplo: reação contra ataques de overflow na pilha pela colocação da pilha em
segmentos/páginas do tipo não executável
» Deste modo, códigos carregados ilicitamente não podem ser executados
» Embora não impeça outras formas desse tipo de ataque
(C) 2005 Gustavo Motta
©2002-2004 Matt Bishop
42
Mecanismos e implementação (42)
 Mecanismos de controle de acesso (32)
• Chave e cadeado (6)
– Compartilhamento de segredos
 Implementa a separação de privilégios
 Usa um esquema baseado num limiar (t, n)
» Os dados que se pretende acessar é dividido em n partes
» Quaisquer t partes são suficientes para derivar o dado original
 Or-access combinado com o and-access podem realizar esta tarefa
» Para um limiar (3, 10), supondo que cada uma das 10 pessoas têm uma chave de criptografia
própria, faz-se a combinação (or-access) 3 a 3 de cada um deles, e usa-se a chave de cada
pessoa numa combinação para criptografar a informação numa forma and-access
» Aumenta o número de representações do dados rapidamente, à medida que n e t crescem
(C) 2005 Gustavo Motta
43
» Esquemas criptográficos
são
mais
comuns
©2002-2004 Matt Bishop
Mecanismos e implementação (43)
 Mecanismos de controle de acesso (33)
• Chave e cadeado (7)
– Compartilhamento de segredos
 Esquema de Shamir: usa um limiar (t, n) para compartilhar uma chave criptográfica
» Baseado nos polinômios de Lagrange
» Idéia: considera-se o polinômio p(x) de grau t – 1, definindo-se o termo p(0) para ser a chave
» Computa-se o valor de p em n pontos, excluíndo-se x = 0, para distribuir com as n pessoas
» Pela regras da álgebra, são necessários valores de p em quaisquer t pontos distintos para derivar
o polinomial e, conseqüentemente, o termo constante – a chave
(C) 2005 Gustavo Motta
©2002-2004 Matt Bishop
44