1 / 18

Sécurité-innocuité dans les systèmes d’exploitation et les machines virtuelles

Sécurité-innocuité dans les systèmes d’exploitation et les machines virtuelles. Tour d’horizon des mécanismes de sécurité, déclinés en terme d’authentification, de confidentialité et intégrité des données, d’isolation des fautes, et de dénie de service. Par Gilles Grimaud

brina
Download Presentation

Sécurité-innocuité dans les systèmes d’exploitation et les machines virtuelles

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Sécurité-innocuité dans les systèmes d’exploitation et les machines virtuelles Tour d’horizon des mécanismes de sécurité, déclinés en terme d’authentification, de confidentialité et intégrité des données, d’isolation des fautes, et de dénie de service. Par Gilles Grimaud Université des Sciences et Technologies de Lille http://www.lifl.fr/~grimaud/Cours

  2. Plan • Notion de sécurité-innocuité dans les systèmes d’exploitations et les machines virtuelles • Authentification / non répudiation • Stratégies d’isolation des applications • Contrôle d’accès et espace d’adressage • Isolation par adressage statique • Inférence de type est code • Capacités • Denis de Service

  3. Sécurité-innocuité Rappel : « Déf. Un système d’exploitation assure fondamentalement trois tâches distinctes : (i) gérer le matériel informatique ; (ii) simplifier la manipulation du matériel informatique ; (iii) fiabiliser le fonctionnement de l’équipement informatique. » Objectifs : • Garantir l’exploitation du matériel : E.g. Couche liaison du modèle OSI, Mémoire transactionnelle, garantie un temps de réponse, … • Fiabiliser l’exécution des programmes : • Que se passe t’il lorsqu’un programme crash ? • Un programme peut nuire (éventuellement volontairement) aux autres applications présentent sur l’ordinateur. • Un programme peut nuire au fonctionnement du système d’exploitation.

  4. Sécurité-innocuité Définitions : « La Sécurité-innocuité se décline en quatre propriétés, • Authentification / Non répudiation : Identifier un utilisateur du système, et garantir qu’il ne puisse pas « nier les faits! » • Confidentialité : Protéger l’accès aux données sensibles du système d’exploitation et des applications • Intégrité : Garantir que les données ne sont pas altérés par une application indélicate… • Disponibilité : Garantir aux applications qu’elles auront accès aux ressources dont elles ont besoin »

  5. Authentification / Non répudiation Il s’agit de pouvoir identifier un utilisateur ou un service : • Par identifiant cryptographique « système » ( problème de confidentialité/innocuité du système lui même) • Par mot de passe • Par carte à puce / système cryptographique • Par système biométrique • Par système de questions/réponses • … • Combinaison de plusieurs systèmes coût et durée variables

  6. Confidentialité - Intégrité De nombreuses stratégies peuvent être envisagé pour isoler les programmes les uns des autres. Adressage Dynamique • MMU • Mémoire virtuelle • Firewall de machine virtuelle défensive Statique • SFI : isolation de fautes logicielles Langage Dynamique • Machines virtuelles défensives • Capacités Statique • Inférence de type « safe pointer policy » • TAL • PCC

  7. Isolation des programmes et MMU Un circuit spécialisé (MMU) « surveille » les zone de mémoire accédées par le microprocesseur et déclanche une interruption matérielle en cas de d’accès illégal. Un accès est « illégal » s’il est non conforme aux règles d’accès spécifiées par le système d’exploitation sous la forme d’une table : 0x800000 Segmenttext 0x801F00 Adresse de départ longueur droits 0x802000 Segmentdata X L E 0x803000 0x800000 0x1F00 O O N Segmentdonnées sys N O 0x802000 0x1000 O 0x803100 0xBFF000 0x803000 0x100 N O N Pile 0xBFF000 0x1000 N O O 0x803100 0xC00000 0x3FFFFF O N N 0xC00000 Système

  8. Isolation des programmes et mémoire virtuelle • L’exemple des systèmes Unix Données init. Section de code Tas Pile Section de code Données init. Tas Pile Application n°2 : Application n°3 : Application n°1 : A. n°3 A. n°1 A. n°2 Programme système : Section de code Données noyau Données dans le tas du noyau (non initialisées) Pile

  9. Isolation des programmes Unix et Buffer Overflow int f(int i) { char t[8]; scanf("%s",t); return strlen(t); } int main(int ac, char **av) { f(3); Label1: return1; } int huch() { printf("Outch\n"); return1; } Pile d’appel … t[0],t[1],t[2],t[3] Variableslocales t[4],t[5],t[6],t[7] Frame de int f(int i) Base de frame précédente Adresse de retour PC &Label1: i (== 3) …

  10. SFI : Isolation logicielle des fautes • Comment isoler les défaillances logicielles (et/ou contrôler l’accès à la mémoire) sans MMU, ou bien, au cœur même d’un système d’exploitation (dans un pilote matériel par exemple?) SFI : rechercher les accès à la mémoire dans un programme machine… mov eax, 0803000h … add eax, ebx mov ebx,[eax] Contrôler que les zones mémoires accédées sont correcte statiquement, ou à défaut, injecter dans le code un test dynamique. mov eax, 0803000h … add eax, ebx cmp eax, 0801000h jle error cmp eax, 0808000h jge error mov ebx,[eax] OK statiquement Pas d’accès mémoire Code SFIajouté Accès à la mémoireimprédictible. Avant traitement Après traitement

  11. Politique des pointeurs propres On peut lire dans le RedBook de la machine virtuelle Java : • « Il est illégal de forger un pointeur à partir d’une valeur. » • « Java n’autorise pas l’arithmétique des pointeurs. » • « le ramasse miette garantie la consistance de la mémoire. » • « si l’index n’est pas dans les limites du tableau le bytecode déclanche une exception ArrayIndexOutOfBoundsException. » • « tout accès à un champs est contrôlé et l’exception IllegalAccessError est déclanchée si le droit d’accès n’est pas respecté » • « Les instances peuvent être surclassées (cast) dans leurs superclasses, ou dynamiquement souclassées, en cas d’erreur IllegalCastException. » Ceci constitue une garantie de sécurité et l’isolation des applications ! ? On ne peut pas écrire : • byte ptr[] = (byte [])0x100000; • byte ptr[] = new byte[1]; ptr+=10; byte i = ptr[0]; • byte ptr[] = new byte[1]; free(ptr); ptr[0] = (byte) 3; • byte ptr[] = new byte[1]; byte i = ptr[2]; • int i = (MaClass)o.aPrivateInt ; • …

  12. Politique des pointeurs propres Les langages de hauts niveaux reposent sur un système de type. En Java ce système de type comprend des types élémentaires et la hiérarchie des classes : top int int0 short char Ref Object uRef Object uRef Derived Refarray Object Ref Derived boolarray intarray xxxarray Refarray derived Java = héritage simple sauf null : sous-classe de toutes les références  null

  13. Politique des pointeurs propres static void m(int i) { C1 o; if(i==4) o =new C2(); else o =new C3(); o.doit(); } C1 Comment la machine virtuelle peut vérifier le bytecode généré par le compilateur java ?  ByteCode verifier C2 C3 Local[0] Local[1] Stack[0] Stack[1] Bytecodes java int unused - - iload_0 int unused int - Ifeq #4,L1 compilation int unused - - new C2 dup int unused C2 - invokspecial C2.<init>()V int unused C2 C2 store_1 int unused C2 C2 Goto L2 int C2 - - L1: new C3 int unused - - int unused C3 - dup invokspecial C3.<init>()V int unused C3 C3 int unused C3 - store_1 int C3 - - nop int C1 - - L2: invokvirtual C1.doIt()V

  14. 01011000 01011000 01011000 Preuve de programme et les « stackmap » de la KVM Proof Carrying Code : « Faire la preuve d’un programme c’est comme trouver la sortie d’un labyrinthe. Une fois que quelqu'un l’a trouvé, il peut donner la séquence des mouvements aux autres, qui sortiront alors bien plus facilement. A condition que les indications soient correctes… » Producteur de code Consommateur de Code reject applet preuve Preuve de byte code byte code Vérifieur de type Générateur de preuve Vérifieur chargeur- Structurel byte code

  15. Preuve de programme et les « stackmap » de la KVM Quel est le plan du labyrinthe dans le cas de l’inférence de type ? (Quel est le plan du labyrinthe dans le cas de l’inférence de type ?) Bytecodes java Local[0] Local[1] Stack[0] Stack[1] iload_0 int unused - - Ifeq #4,L1 int unused int - new C2 int unused - - dup int unused C2 - invokspecial C2.<init>()V int unused C2 C2 store_1 int unused C2 C2 Goto L2 int C2 - - L1: new C3 int unused - - dup int unused C3 - invokspecial C3.<init>()V int unused C3 C3 store_1 int unused C3 - int C3 - - nop L2: invokvirtual C1.doIt()V int C1 - - class2classMaClass.class ajout d’un attribut « stackmap » dans l’attribut « code » de chaque méthode.

  16. Les capacités Inférence de type  sécurité statique « une fois pour toute » mais aussi « rigide » ! interface InterfaceDeMaClasse void m1() void m2() class class class MaClasse CapaciteDeMaClasse ClassExterne n 1 void m1()void m2() void m1()void m2() instanceOf instanceOf instanceOf Contrôled’accès

  17. Disponibilité et Dénie de Service Un système d’exploitation devrait pouvoir : « Garantie l’accessibilité des ressources des données et des traitements à une application lorsqu’elle en a besoin. » Une attaque en DoS consiste à chercher à saturer les l’accès aux ressources d’un système. int main (void) { while (1) fork(); }

  18. Disponibilité et Dénie de Service Les attaques de serveurs en DoS :Saturer de requête la machine visée de tel sorte qu’elle devienne incapable de serveur les utilisateurs « réels ». • « Brut force flooding » : • « SYN flooding » : • « Slash attack » : • « Windows overflow » : • …

More Related