s curit innocuit dans les syst mes d exploitation et les machines virtuelles n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Sécurité-innocuité dans les systèmes d’exploitation et les machines virtuelles PowerPoint Presentation
Download Presentation
Sécurité-innocuité dans les systèmes d’exploitation et les machines virtuelles

Loading in 2 Seconds...

play fullscreen
1 / 18

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


  • 148 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Sécurité-innocuité dans les systèmes d’exploitation et les machines virtuelles' - brina


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
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

Université des Sciences et Technologies de Lille

http://www.lifl.fr/~grimaud/Cours

slide2
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
s curit innocuit
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.
s curit innocuit1
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

»

authentification non r pudiation
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

confidentialit int grit
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
isolation des programmes et mmu
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

isolation des programmes et m moire virtuelle
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

isolation des programmes unix et buffer overflow
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)

sfi isolation logicielle des fautes
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

politique des pointeurs propres
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 ;
politique des pointeurs propres1
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

politique des pointeurs propres2
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

preuve de programme et les stackmap de la kvm

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

preuve de programme et les stackmap de la kvm1
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.

les capacit s
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

disponibilit et d nie de service
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();

}

disponibilit et d nie de service1
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 » :