A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

©2002-2004 Matt Bishop (C) 2005 Gustavo Motta1 2 Políticas, Modelos e Mecanismos de Segurança O papel do controle de acesso Matriz de controle de acesso.

Apresentações semelhantes


Apresentação em tema: "©2002-2004 Matt Bishop (C) 2005 Gustavo Motta1 2 Políticas, Modelos e Mecanismos de Segurança O papel do controle de acesso Matriz de controle de acesso."— Transcrição da apresentação:

1 © Matt Bishop (C) 2005 Gustavo Motta1 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 Mecanismos e implementação

2 © Matt Bishop (C) 2005 Gustavo Motta2 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

3 © Matt Bishop (C) 2005 Gustavo Motta3 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

4 © Matt Bishop (C) 2005 Gustavo Motta4 Mecanismos e implementação (3) Princípios de projeto (3) Princípio do menor privilégioPrincípio do menor privilégio privilégios –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 funções –As funções do sujeito devem controlar a concessão de direitos, não a identidade descartados –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 menor domínio de proteção –Requer o confinamento de processos no menor domínio de proteção possível

5 © Matt Bishop (C) 2005 Gustavo Motta5 Mecanismos e implementação (4) Princípios de projeto (4) Princípio do defaults seguros na falhaPrincí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 negado por default –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 retroceder para o estado seguro inicial –Caso uma ação falhe, o sistema deve retroceder para o estado seguro inicial Caso o servidor de 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 usar esta facilidade para sobrescrever arquivos ou esgotar os discos num ataque dos

6 © Matt Bishop (C) 2005 Gustavo Motta6 Mecanismos e implementação (5) Princípios de projeto (5) Princípio do mecanismo econômicoPrincí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 todascompletamente Definir todas as interfaces completamente –Interfaces para outros módulos são suspeitas suposições implícitas 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 problema

7 © Matt Bishop (C) 2005 Gustavo Motta7 Mecanismos e implementação (6) Princípios de projeto (6) Princípio da mediação completaPrincípio da mediação completa efetivamente verificados –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 – endereço IP, que pode ser adulterado com a associação de um IP forjado

8 © Matt Bishop (C) 2005 Gustavo Motta8 Mecanismos e implementação (7) Princípios de projeto (7) Princípio do projeto abertoPrincí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

9 © Matt Bishop (C) 2005 Gustavo Motta9 Mecanismos e implementação (8) Princípios de projeto (8) Princípio do projeto abertoPrincí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 »K a »hash(K d ) »E(K d, K pi ) »... »E(K d, K pi ) »E(K t, K d ) Baseava-se num algoritmo frágil, que, quando descoberto em 1999, frustrou as expectativas da indústria de filmes

10 © Matt Bishop (C) 2005 Gustavo Motta10 Mecanismos e implementação (9) Princípios de projeto (9) Princípio da separação de privilégioPrincípio da separação de privilégio numa única condição –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

11 © Matt Bishop (C) 2005 Gustavo Motta11 Mecanismos e implementação (10) Princípios de projeto (10) Princípio do menor mecanismo comumPrincí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 Criação de arquivos com nomes fixos

12 © Matt Bishop (C) 2005 Gustavo Motta12 Mecanismos e implementação (11) Princípios de projeto (11) Princípio da aceitação psicológicaPrincí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

13 © Matt Bishop (C) 2005 Gustavo Motta13 Mecanismos e implementação (12) Princípios de projeto (12) ConclusãoConclusã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

14 © Matt Bishop (C) 2005 Gustavo Motta14 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

15 © Matt Bishop (C) 2005 Gustavo Motta15 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

16 © Matt Bishop (C) 2005 Gustavo Motta16 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 arquivo1arquivo2arquivo3 Andrérxrrwo Biarwxor Carlosrxrwow LCAs: arquivo1: { (André, rx) (Bia, rwxo) (Carlos, rx) } arquivo2: { (André, r) (Bia, r) (Carlos, rwo) } arquivo3: { (André, rwo) (Carlos, w) }

17 © Matt Bishop (C) 2005 Gustavo Motta17 Mecanismos e implementação (16) Mecanismos de controle de acesso (4) Lista de controle de acesso (3) –Permissões default não –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

18 © Matt Bishop (C) 2005 Gustavo Motta18 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)

19 © Matt Bishop (C) 2005 Gustavo Motta19 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 »LCAs podem adicionar direitos, mas quando proibir, o acesso está proibido

20 © Matt Bishop (C) 2005 Gustavo Motta20 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):r-- others:--- extended permissions enabled specifyrw-u:holly permit-w-u:heidi, g=sys permitrw-u:matt deny-w-u:holly, g=faculty

21 © Matt Bishop (C) 2005 Gustavo Motta21 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? 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)? As LCAs se aplicam aos usuários privilegiados (root ou administradores)? »Solaris: listas abreviadas não, mas ACLs sim »Outros produtos: varia

22 © Matt Bishop (C) 2005 Gustavo Motta22 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? 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 Qualquer usuário no grupo caixa pode ler o arquivo

23 © Matt Bishop (C) 2005 Gustavo Motta23 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? 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 –Note que por default é negado, seguindo o princípio do default seguro na falha

24 © Matt Bishop (C) 2005 Gustavo Motta24 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? 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

25 © Matt Bishop (C) 2005 Gustavo Motta25 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

26 © Matt Bishop (C) 2005 Gustavo Motta26 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 arquivos; exclusão de subdiretórios), controle total, direitos especiais

27 © Matt Bishop (C) 2005 Gustavo Motta27 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 acesso proibido »Caso o usuário não esteja em nenhuma LCA nem seja membro de grupo presente na LCA: acesso proibido acesso proibido »Alguma entrada da LCA proíbe explicitamente o acesso : acesso proibido usuário tem este conjunto de direitos sobre o arquivo »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

28 © Matt Bishop (C) 2005 Gustavo Motta28 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

29 © Matt Bishop (C) 2005 Gustavo Motta29 Mecanismos e implementação (28) Mecanismos de controle de acesso (16) Capabilities – lista-C (2) –Exemplo: linhas da matriz de controle de acesso arquivo1arquivo2arquivo3 Andrérxrrwo Biarwxor Carlosrxrwow LCAs: André: { (arquivo1, rx) (arquivo2, r) (arquivo3, rwo) } Bia: { (arquivo1, rwxo) (arquivo2, r)} Carlos: { (arquivo1, rx) (arquivo2, rwo) (arquivo3, w)}

30 © Matt Bishop (C) 2005 Gustavo Motta30 Mecanismos e implementação (29) Mecanismos de controle de acesso (17) Capabilities – lista-C (3) –Semântica bilhete aéreo 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 que se refere

31 © Matt Bishop (C) 2005 Gustavo Motta31 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

32 © Matt Bishop (C) 2005 Gustavo Motta32 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 à descoberta da capability

33 © Matt Bishop (C) 2005 Gustavo Motta33 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

34 © Matt Bishop (C) 2005 Gustavo Motta34 Mecanismos e implementação (33) Mecanismos de controle de acesso (22) Capabilities – lista-C (8) –Amplificação de capabilities temporário 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 processo as capabilities enquanto ele está executando operações no módulo

35 © Matt Bishop (C) 2005 Gustavo Motta35 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 - Todas as capabilities para o objeto passam a ser inválidas

36 © Matt Bishop (C) 2005 Gustavo Motta36 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 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-*!

37 © Matt Bishop (C) 2005 Gustavo Motta37 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? Dado um objeto, quais sujeitos pode acessá-lo e com quais direitos? –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 que a primeira questão torne-se mais importante Capabilities respondem com facilidade Capabilities respondem com facilidade LCAs respondem com facilidade LCAs respondem com facilidade

38 © Matt Bishop (C) 2005 Gustavo Motta38 Mecanismos e implementação (37) Mecanismos de controle de acesso (26) Chave e cadeado (1) –Combina características LCAs e de capabilities cadeadochave –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 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 mudar baseadas em restrições no sistema ou em outros fatores

39 © Matt Bishop (C) 2005 Gustavo Motta39 Mecanismos e implementação (38) Mecanismos de controle de acesso (27) Chave e cadeado (2) –Implementação criptográfica chave de criptografarcadeado A chave de criptografar é o cadeado chave de decriptografarchave A chave de decriptografar é a chave »Criptografa o objeto o; armazena E k (o) »Usa-se a chave k do usuários para computar D k (E k (o)) »Qualquer um de n sujeitos pode acessar o: armazena-se o = (E 1 (o), …, E n (o))or-access »Requer o consentimento de n sujeitos para acessar o: armazena-se o = (E 1 (E 2 (…(E n (o))…))and-accesss

40 © Matt Bishop (C) 2005 Gustavo Motta40 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

41 © Matt Bishop (C) 2005 Gustavo Motta41 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 eq telnet access-list 100 dynamic test timeout 180 permit ip any host \ 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 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 - Excluída da LCA depois deste prazo

42 © Matt Bishop (C) 2005 Gustavo Motta42 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

43 © Matt Bishop (C) 2005 Gustavo Motta43 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 »Esquemas criptográficos são mais comuns

44 © Matt Bishop (C) 2005 Gustavo Motta44 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


Carregar ppt "©2002-2004 Matt Bishop (C) 2005 Gustavo Motta1 2 Políticas, Modelos e Mecanismos de Segurança O papel do controle de acesso Matriz de controle de acesso."

Apresentações semelhantes


Anúncios Google