Universidade de São Paulo Instituto de Ciências Matemáticas e de Computação Departamento de Sistemas de Computação SSC541 - SISTEMAS OPERACIONAIS I Aula.

Apresentação em tema: "Universidade de São Paulo Instituto de Ciências Matemáticas e de Computação Departamento de Sistemas de Computação SSC541 - SISTEMAS OPERACIONAIS I Aula."— Transcrição da apresentação:

1 Universidade de São Paulo Instituto de Ciências Matemáticas e de Computação Departamento de Sistemas de Computação SSC541 - SISTEMAS OPERACIONAIS I Aula 22 – Projeto de Sistema Operacional Profa. Sarita Mazzini Bruschi Regina Helena Carlucci Santana Marcos José Santana Slides adaptados de Luciana A. F. Martimiano baseados nos livros Sistemas Operacionais Modernos de A. Tanenbaun

2 Projeto de Sistemas Operacionais O que considerar no projeto de um sistema operacional novo? Quais os passos a serem seguidos? Pouca literatura Muita diversidade Muita complexidade

3 Projeto de Sistemas Operacionais Tanenbaum – capítulo 13 (3a edição) The Common Man's Guide to Operating System Design http://cdsmith.twu.net/professional/osdesign.html On building systems that will fail – Corbató 91

4 Projeto de Sistemas Operacionais Definição dos Objetivos; Projeto de Interface (interação); Implementação; Desempenho; Planejamento; Equipe; Exemplo: MINIX; Tendências em SO;

5 Projeto de Sistemas Operacionais - Objetivos Geralmente, projetar um sistema é uma tarefa difícil; Projetar um Sistema Operacional não foge a essa regra é uma tarefa crítica; Importante: os projetistas devem saber claramente o que querem; no entanto, isso nem sempre é uma tarefa fácil;

6 Projeto de Sistemas Operacionais - Objetivos Propósitos podem variar dependendo do tipo de sistema; mas, alguns são comuns: Definir abstrações; Prover primitivas; Garantir isolamento (privacidade); Gerenciamento de hardware;

7 Projeto de Sistemas Operacionais - Objetivos Definir abstrações: uma das tarefas mais difíceis; Processos; Threads; Arquivos; Modelo de gerenciamento de memória; Estrutura de Dados (??);

8 Projeto de Sistemas Operacionais - Objetivos Prover primitivas: quais operações primitivas são implementadas para manipular as abstrações; Chamadas de sistema; Exemplo Para abstração de arquivo – quais primitivas? Obvias – ler, abrir, escrever, fechar.... Concatenar? Comparar? Compartilhar?

9 Projeto de Sistemas Operacionais - Objetivos Garantir isolamento (privacidade): se múltiplos usuários podem ter acesso ao sistema ao mesmo tempo, o sistema deve garantir que os usuários só terão acessos permitidos; segurança; Modularidade do sistema módulos isolados para garantir desempenho e independência de falhas; Não perder flexibilidade Compartilhar informações

10 Projeto de Sistemas Operacionais - Objetivos Gerenciamento de Hardware: o sistema deve cuidar dos controladores de interrupções e barramento; permitir que os drivers possam gerenciar dispositivos de E/S, tais como: disco, impressoras, etc... Facilidade de acesso a informação: Ex. disco = coleção de blocos = Qual interface? Qual barramento? Compatibilidade: Ex. disco scsi, ide, etc.

11 Projeto de Sistemas Operacionais - Objetivos Objetivos específicos Propósito geral – Windows, Unix Sistemas Embutidos Recursos limitados Tarefas específicas Ex. software em um celular Sistemas de Tempo Real Tempo de resposta é crítico Antes tarde do que nunca é inaceitável Mais complexos

12 Projeto de Sistemas Operacionais - Objetivos Objetivos específicos Sistemas Distribuídos Todo um sistema deve atuar como um sistema operacional único Transparência Comunicação Compartilhamento de dados Sistemas Tolerantes a Falhas Mecanismos de recuperação em caso de falhas Esconder as falhas

13 Projeto de Sistemas Operacionais - Objetivos Por que é tão difícil projetar um Sistema Operacional? Nove motivos importantes: 1. Sistemas Operacionais têm se tornado programas muito grandes; forte interação entre os subsistemas (Ex.: sistema de arquivos com sistema de memória); UNIX mais de 1 milhão de linhas de código; Win2000 +/- 29 milhões de linhas de código;

14 Projeto de Sistemas Operacionais - Objetivos 2. Sistemas Operacionais devem gerenciar concorrência; Múltiplos usuários e múltiplos dispositivos ativos; Problemas: deadlocks; 3. Sistemas Operacionais devem gerenciar compartilhamento de informações e recursos; 4. Sistemas Operacionais devem lidar com acessos não autorizados intrusão; crackers;

15 Projeto de Sistemas Operacionais - Objetivos 5. Sistemas Operacionais devem evoluir rapidamente ou devem estar preparados para evoluírem com facilidade novas tecnologias de hardware; 6. Projetistas dos Sistemas Operacionais não têm uma idéia clara de como o sistema será utilizado; Na década de 70 nem se pensava em Web 7. Geralmente, Sistemas Operacionais devem ser projetados para serem portáveis, ou seja, devem executar sob qualquer plataforma de hardware; 8. Gerenciar um grande número de dispositivos de E/S; 9. Novas versões de Sistemas Operacionais devem ser compatíveis com versões antigas;

16 Projeto de Sistemas Operacionais - Interface Projeto de Interface: Interação Usuário-Sistema Operacional chamadas de sistema; Princípios: Simplicidade Completude Eficiência

17 Projeto de Sistemas Operacionais - Interface Simplicidade: em Sistemas Operacionais vale o seguinte ditado: menos é melhor do que mais; Quanto mais simples, melhor; A perfeição é alcançada não quando não há mais o que acrescentar, mas sim quando não há mais o que tirar. Saint-Exupéry (escritor) Importante enfatizar o valor da simplicidade, já que a complexidade pode trazer dificuldades e criar erros. Uma funcionalidade deve ter um mínimo de mecanismo e um máximo de clareza Corbató;

18 Projeto de Sistemas Operacionais - Interface Completude: o usuário deve ser capaz de realizar as tarefas que deseja; Quais as consequências se uma nova característica não for inserida?

19 Projeto de Sistemas Operacionais - Interface Eficiência Chamadas ao sistema devem ser eficientes; Os programadores devem ter idéia da eficiência das chamadas ao sistema;

20 Projeto de Sistemas Operacionais - Interface Dois tipos de clientes para o SO: Usuário Interagem com os programas aplicativos Interface gráfica Programadores Escrevem os aplicativos Interface do sistema – paradigmas de execução (algorítmico ou orientado a eventos) e dados;

21 Como o usuário interage com o sistema: GUI (Graphical User Interface) : baseado no paradigma WIMP (Window, Icon, Menu, Pointing device or Pull-down) Comandos Entrada de voz Escrita à mão Projeto de Sistemas Operacionais - Interface

22 Chamadas de Sistema: devem ser o mais geral possível: Ex.1: se arquivos, processos ou dispositivos de E/S são tratados pelo SO como arquivos/objetos, então uma simples chamada read pode ser utilizada para leitura; Ex.2: Criação de processos Unix – Fork/Exec – total de 3 parâmetros Win32 – createProcess – total de 10 parâmetros Projeto de Sistemas Operacionais Interface do Sistema

23 Projeto de Sistemas Operacionais - Implementação Estrutura do sistema: Sistema em Camadas; Sistema Cliente/Servidor Micronúcleo; Partes do SO executam como servidores no espaço do usuário; Sistema Modular;

24 Projeto de Sistemas Operacionais - Implementação Nomenclatura: login names, nomes de arquivos, nomes de dispositivos, identificação de processos, etc; Ortogonalidade: habilidade de combinar conceitos separados e independentes; simplicidade e completude; Fork/exec do Unix para criação de processo Cria novo espaço de endereçamento

25 Projeto de Sistemas Operacionais - Desempenho Sistemas Operacionais mais antigos (MS-DOS e UNIX v7) realizavam boot mais rápido que os sistemas atuais; Sistemas Operacionais atuais carregam/realizam muito mais informações/tarefas durante o processo de boot; Ex.: Dispositivos Plug and Play sempre que o sistema está realizando boot, ele faz a checagem se existe um novo hardware a ser instalado, consumindo tempo!!!

26 Projeto de Sistemas Operacionais - Desempenho O que deve ser otimizado? Caching Gerenciamento de memória troca de páginas Working Set

27 Projeto de Sistemas Operacionais - Planejamento Idealizar um Sistema Operacional não é uma tarefa trivial como implementar um simples programa que, por exemplo, faz controle de uma vídeo locadora!!! Tarefas de planejamento são extremamente importantes; O mais fácil é a implementação!!!

28 Projeto de Sistemas Operacionais Equipe Equipe Projetos grandes são completamente diferentes de pequenos projetos produtividade menor; Nem todas as tarefas podem ser realizadas em paralelo; Aumentar o número de envolvidos em um projeto de software atrasado faz com que ele se atrase ainda mais;

29 Projeto de Sistemas Operacionais – Equipe Liderança Distribuir as tarefas; Coordenar as tarefas das diferente equipes; Ex.: Linus Torvalds kernel do Linux; Richard Stallman GNU C ; Equipe de programadores competentes DESAFIO;

30 Projeto de Sistemas Operacionais - Resumindo O que o Sistema Operacional deve fazer; SO deve ser simples, completo e eficiente; Interface com o usuário, paradigmas de execução e dados devem estar claramente definidos; SO deve estar bem estruturado; SO deve ser bem projetado;

31 Projeto de Sistemas Operacionais - Resumindo Sistema Modular módulos são integrados gradualmente ao sistema; Testes de integração são contínuos minimiza erros de projeto; Características mínimas características mais complexas;

32 Universidade de São Paulo Instituto de Ciências Matemáticas e de Computação Departamento de Sistemas de Computação SSC541 - SISTEMAS OPERACIONAIS I Aula 22 – Segurança Profa. Sarita Mazzini Bruschi Regina Helena Carlucci Santana Marcos José Santana Slides adaptados de Luciana A. F. Martimiano baseados nos livros Sistemas Operacionais Modernos de A. Tanenbaun

33 Segurança Ambiente de segurança; Criptografia; Conceitos básicos; Autenticação de usuário; Ataques; Internos; Externos; Mecanismos de proteção; Sistemas Confiáveis;

34 Segurança Valor da informação segurança; SO proteger as informações contra acessos não autorizados; Ambiente de segurança: conceitos importantes: Ameaças (threats); Intrusão; Perda acidental de dados;

35 Segurança - Ameaças ObjetivoAmeaças Confidencialidade de dados Exposição dos dados Integridade de dadosAlteração dos dados Disponibilidade do sistemaNegação de serviço (denial of service) Três objetivos e ameaças gerais

36 Segurança - Intrusão Intruso: pessoa que intencionalmente invade um sistema para causar danos; Ações: Passiva: intrusos apenas lêem dados sem autorização; Ativa: intrusos realizam modificações sem autorização maliciosos;

37 Segurança – Perda de dados Causas comuns para as perdas acidentais de dados: Atos da natureza: fogo, terremoto; Erros de hardware/software: defeito físico em dispositivos, defeito no programa; Erros humanos: perda de fita ou disco; Backups;

38 Segurança – Criptografia Criptografia codificar texto para que acessos não autorizados não possam ser realizados; Plaintext Ciphertext; (texto puro)(texto cifrado) Algoritmos de codificação e decodificação; Sempre públicos O segredo desses algoritmos está nos parâmetros utilizados chaves;

39 Segurança – Criptografia Criptografia moderna está relacionada com os seguintes objetivos: Confidencialidade informação não pode ser compreendia por alguém que não tem autorização para tal; Integridade informação não pode ser alterada enquanto estiver armazenada ou enquanto estiver sendo enviada sem que uma eventual modificação não seja realizada; Irretratabilidade uma ação não pode ser negada; Autenticação o remetente e o destinatário devem conhecer a identificação um do outro;

40 Segurança – Criptografia ED Plaintext KEKE KDKD Algoritmo de Codificação Algoritmo de Decodificação C=E(P, K E ) Ciphertext Plaintext Chaves P=D(C, K D ) Princípio de Kerckhoffs: ideia de que todos os algoritmos são públicos e o segredo está na chave (filósofo Auguste Kerchkhoffs – século XIX)

41 Segurança – Criptografia Tipos de criptografias: Chave-secreta ou chave-simétrica: Pode utilizar substituição do alfabeto: Exemplo: Rot13 usado por Júlio César para se comunicar com suas tropas Chaves com 128bits, 256bits, 512bits, 1024bits, 2048bits; Vantagem: fácil de gerenciar; Desvantagem: Tanto o destinatário quanto o remetente devem conhecer a chave-secreta; Quando se tem a chave de codificação é fácil descobrir a chave de decodificação;

42 Segurança – Criptografia ROT13

43 Segurança – Criptografia Plaintext: A BCDEFGHIJKLMNOPQRSTUVWXYZ K E : QWERTYU IOPASDFGHJKLZXCVBNM ED ATTACK KEKE KDKD Algoritmo de Codificação Algoritmo de Decodificação C=E(P, K E ) QZZQEA Chaves P=D(C, K D ) ATTACK QZZQEA

44 Segurança – Criptografia ED ATTACK KEKE KDKD Algoritmo de Codificação Algoritmo de Decodificação C=E(P, K E ) QZZQEA ATTACK Chaves P=D(C, K D ) Plaintext: ABCDEFGHIJKLMNOPQRSTUVWXYZ K E : QWERTYUIOPASDFGHJKLZXCVBNM K D : KXVMCNOPHQRSZYIJADLEGWBUFT Chave de Decodificação

45 Segurança – Criptografia ED ATTACK KEKE KDKD Algoritmo de Codificação Algoritmo de Decodificação C=E(P, K E ) QZZQEA ATTACK Chaves P=D(C, K D ) Plaintext: ABCDEFGHIJKLMNOPQRSTUVWXYZ K D : KXVMCNOPHQRSZYIJADLEGWBUFT QZZQEA ATTACK

46 Segurança – Criptografia Chave-pública: usado para sanar a desvantagem da chave-secreta; Chaves distintas são utilizadas pelos algoritmos; Par (chave-pública, chave-secreta); Geração da chave é automática; Para enviar uma mensagem, o remetente codifica a mensagem com a chave-pública do destinatário; Como somente o destinatário possui a chave-secreta correspondente, somente ele poderá ler a mensagem (decodificar); RSA (Rivest-Shamir-Adleman, 1977) utilizado pelo Internet Explorer e Netscape; PGP (Pretty Good Privacy) email codificado;

47 Segurança – Criptografia ED (K secreta, K pública ) Algoritmo de Codificação Algoritmo de Decodificação (K pública ) Plaintext Ciphertext Plaintext RSA utiliza os números primos para gerar as chaves;

48 Segurança – Criptografia Assinatura digital: assinatura eletrônica que pode ser utilizada para identificar o remetente de uma mensagem ou para assinar um documento; além disso, pode garantir que o conteúdo original de uma mensagem/documento não foi alterado; Utiliza algoritmos de Hash: MD5 (Message Digest 5): resultado de 16 bytes; SHA-1(Secure Hash Algorithm): resultado de 20 bytes; Também utiliza chave-pública e chave-secreta; Destinatário deve conhecer a chave-pública do remetente; Certificado digital: cartão eletrônico com informações tais como: nome, número serial, chave-pública;

49 Segurança – Autenticação Autenticação do usuário sistema determina quem é o usuário; Princípios: O que o usuário sabe; O que o usuário tem; O que o usuário é; Dependendo do resultado acima, diferentes propriedades são definidas; Root (superusuário); Usuários comuns; Usuários com tarefas especiais backups;

50 Segurança – Autenticação Tipos de autenticação: Senhas; Questões; Certificado digital; Letras; Objetos físicos; Biometria; Restrições: Horários permitidos; Logs registram os logins realizados; Criar grupos diferentes de pessoas, com diferentes direitos;

51 Segurança – Ataques Cavalo de Tróia (Trojan Horse) caracterizado por um programa inocente que executa ações indesejadas no sistema; código malicioso: Modificação de dados; Remoção de dados; Destruir o sistema de arquivos ou o HD;

52 Segurança – Ataques Login Spoofing: relacionado com o cavalo de tróia; Ex.: simula uma tela de login; Spam; Buffer Overflow: processo/programa tenta armazenar mais dados em um buffer do que ele suporta; um dos ataques mais comuns;

53 Segurança – Ataques Denial of Service (negação de serviço): consumir recursos até causar uma parada no sistema (serviços de email, servidor de arquivos); main () {while (1) fork();} Vírus: muito comum; Vírus de boot; Vírus residente em memória; Vírus de Macro/Drivers; Vírus de Executável;

54 Segurança - Princípios de Projeto Projeto deve ser público; Ser simples, coerente; Fácil para o usuário; O default deve ser sem acesso algum; Processos devem ter o mínimo de privilégios possíveis; Mecanismos de proteção devem ser simples, uniformes e devem estar nos níveis mais baixos do SO;

55 Segurança Mecanismos de Proteção Mecanismos que garantem as políticas de segurança estabelecidas; Característica importante: Domínios de proteção; Mecanismos: Matriz de Proteção; Lista de controle de acesso (ACL); Capabilities;

56 Segurança Mecanismos de Proteção Domínios de Proteção diferentes objetos precisam ser protegidos: Hardware: CPU, memória, disco; Software: processos, arquivos, semáforos, bases de dados; Cada objeto possui um nome e um conjunto finito de operações que podem ser realizadas sobre esse objeto: Leitura/escrita arquivos; Up/down semáforos;

57 Segurança Mecanismos de Proteção Assim, o sistema deve estabelecer quais objetos têm acesso (leitura/escrita/execução) a quais objetos; Domínio par (objeto, direitos); Um objeto pode estar presente em diferentes domínios com diferentes direitos;

58 Segurança Mecanismos de Proteção É possível que um objeto (processo, por exemplo) tenha diferentes acessos em diferentes domínios: Chamadas de sistema: modo usuário modo kernel; Matriz de proteção pouca utilizada devido ao espaço ocupado e ao fato de ser muito esparsa;

59 Segurança Mecanismos de Proteção Read Write Read Write Execute Read Write Arquivo1 PlotterImpressora Arquivo4 Arquivo3 Arquivo2 D1 D3 D2

60 Segurança Mecanismos de Proteção Lista de Controle de Acesso (ACL) técnica que associa a cada objeto aos domínios/usuários que têm acesso (e quais acessos) a esse objeto (lista ordenada); ACL pode ter entradas para usuários individuais ou para grupos de usuários; ABC processo Dono (owner) Usuário Kernel F1 F2 Arquivos A: RW; B:R B: R; C:RWX ACL Forma básica de ACL

61 Segurança Mecanismos de Proteção Capabilities: a cada domínio/usuário é associada uma lista de objetos que esse domínio/usuário pode acessar (e quais acessos); ABC processo Dono (owner) Usuário Kernel F1 F2 F2: RWXF1: R F2: R F1: RW C-list

62 Segurança – Sistemas Confiáveis Muito $$$ é gasto com danos causados por vírus, perda de dados, invasão, etc; Duas questões importantes: É possível desenvolver sistemas computacionais seguros? Se é possível, por que esses sistemas não são desenvolvidos?

63 Segurança – Sistemas Confiáveis É possível construir sistemas seguros, no entanto, infelizmente, não existem sistemas 100% seguros; Muitas vezes, implementar características de segurança torna o sistema lento, complexo quanto mais características, mais problemas, mais bugs, mais erros de segurança; Ex.: páginas WEB HTML puro é mais seguro do que os Applets;

64 Segurança – Sistemas Confiáveis Sistemas confiáveis são desenvolvidos utilizando requisitos formais de segurança; Todo sistema confiável deve possuir um TCB (Trusted Computing Base) conjunto de hardware e software que auxiliam nas regras de segurança; Basicamente, um TCB consiste de hardware, uma parte do kernel do SO, e a maioria (ou todos) os programas de usuários que têm direitos de root (superusuário);

65 Segurança – Sistemas Confiáveis Funções do SO que devem fazer parte do TCB: Criação de processo; Chaveamento de processo; Mapeamento de memória; Parte do gerenciamento de arquivos e dispositivos de E/S;

66 Segurança – Sistemas Confiáveis Monitor de referência: responsável por tratar as chamadas ao sistema envolvendo segurança; decide se as chamadas podem ou não ser executadas; Usuário Kernel Processo do usuário Kernel TCB Monitor Chamadas de sistema

67 Segurança – Sistemas Confiáveis Livro Laranja (Orange Book): Diretrizes de Segurança; Criado pelo Departamento de defesa dos EUA em 1985 (DoD 5200.28); http://www.radium.ncsc.mil/tpep/library/rain bow http://www.radium.ncsc.mil/tpep/library/rain bow Divide os Sistemas em sete níveis de acordo com suas propriedades de segurança; Níveis: D, C1, C2, B1, B2, B3 e A1;

68 Segurança – Sistemas Confiáveis Critérios: Políticas de segurança: Controle de acesso; Reuso de objetos; Accountability (responsabilidade): Identificação e autenticação; Auditoria;

69 Segurança – Sistemas Confiáveis Critérios: Assurance (garantia): Arquitetura do sistema; Integridade do sistema; Projeto formal; Documentação: Manuais de segurança; Documentos de projeto e teste;

70 Segurança – Sistemas Confiáveis Nível D requisitos mínimos de proteção; MS-DOS; Windows95; Windows98*; WindowsME;

71 Segurança – Sistemas Confiáveis Nível C ambientes com usuários cooperativos; C1 requer login de autenticação; usuários podem estabelecer quais arquivos podem ser acessados por quais usuários (controle discretionary); ACL; TCB; Versões mais antigas do UNIX; C2 além das características de C1, o sistema deve possuir um mínimo de auditoria (logs de eventos); controle de acesso; WinNT 4.0, Windows2000, Oracle 7, Novell Netware;

72 Segurança – Sistemas Confiáveis Nível B: algumas políticas de segurança são impostas (mandatory); B1 C2; integridade dos dados; controle do fluxo de informações dos usuários e objetos do sistema; B2 B1; além de controlar o fluxo, o sistema deve ter sido projetado de maneira top-down e modular; modelo formal de TCB; B3 B2; possuir ACL tanto para usuários quanto para grupos; auditoria; recuperação de problemas; Nível A1: Funcionalidade igual ao B3; Modelo formal do sistema de proteção;