chap. 18 protection chapitre 18

51
Chap. 18 Protection Protection Chapitre 18 Chapitre 18 http://w3.uqo.ca/luigi/ http://w3.uqo.ca/luigi/ http://www.fotosearch.com/IGS236/is102-015/

Upload: violette-thiery

Post on 04-Apr-2015

114 views

Category:

Documents


4 download

TRANSCRIPT

Page 1: Chap. 18 Protection Chapitre 18

Chap. 18

ProtectionProtection

Chapitre 18Chapitre 18

http://w3.uqo.ca/luigi/http://w3.uqo.ca/luigi/http://www.fotosearch.com/IGS236/is102-015/

Page 2: Chap. 18 Protection Chapitre 18

Chap. 18

Concepts importants du chapitreConcepts importants du chapitre

Niveaux de protection, anneaux en Multics Domaines d’exécution Besoin de connaître Protection sur les descripteurs des segments Matrices d’accès

Copier, modifier, octroyer les droits d’accès Implémentation des droits d’accès:

Listes d’accès aux objets Liste de capacité des processus Compromis, solutions mixtes

Page 3: Chap. 18 Protection Chapitre 18

Chap. 18

Le problème de la protectionLe problème de la protection

S’assurer qu’un objet ne puisse être accédé que par les processus qui sont autorisés dans la façon autorisée

Importante pour la protection des données des usagers, pour le bon fonctionnement du système entier:

vulnérabilité des SE qui ont des mauvais mécanismes de protection

Page 4: Chap. 18 Protection Chapitre 18

Chap. 18

Exigences, besoins. Exemple 1Exigences, besoins. Exemple 1

Niveaux de protection: un programme de correction, écrit par un prof, exécute des progs. d ’étudiants.

Nous avons 3 niveaux de protection: Système d ’exploitation

Doit être protégé par rapport aux programmes usagers Peut les affecter (R,W,X?)

Programme du prof Doit être protégé par rapport aux progrs. étudiants Peut les affecter

Programme étudiant Doit être protégé par rapport aux programmes d’autres

étudiants

Page 5: Chap. 18 Protection Chapitre 18

Chap. 18

Exigences, besoins. Exemple 2Exigences, besoins. Exemple 2

Nous avons vu que les systèmes d’exploitation modernes sont organisés par couches de fonctionnalités Il est souhaitable de pouvoir protéger les

couches les plus internes (les plus critiques) contre les plus externes

P.ex le noyau contre les programmes d’application

Page 6: Chap. 18 Protection Chapitre 18

Chap. 18

Exigences, besoins. Exemple 3Exigences, besoins. Exemple 3

Protection par rapport aux domaines d’exécution dans lesquelles l’usager se trouve Quand j’exécute un programme de traitement de

texte, j’aurai accès à certaines données Fichiers .doc, .txt …

Quand j’exécute mon application de courriel, j’aurai accès à d’autres données

Fichiers .pst …

Pour éviter la corruption de données .pst, il devrait être empêché de les ouvrir par les logiciels conçus pour .txt

Page 7: Chap. 18 Protection Chapitre 18

Chap. 18

Principe Principe besoin de connaîtrebesoin de connaître (need to know) (need to know)

On ne devrait permettre à une entité que d’accéder à l’info dont elle a vraiment besoin Si un processus invoque une procédure, cette

procédure doit avoir accès à ses paramètres, mais ne devrait pas être capable d ’accéder aux variables du processus

Dans un hôpital, Un statisticien aura accès aux données disant les types

de maladies, mais pas aux noms des patients Un médecin aura accès aux infos concernant ses

patients, mais pas accès aux infos concernant d’autres patients

Page 8: Chap. 18 Protection Chapitre 18

Chap. 18

Mécanismes Mécanismes

Comment trouver des mécanismes parfaitement adaptés aux besoins dons nous avons parlé?

Ce qui suit présente quelques uns des mécanismes connus

Page 9: Chap. 18 Protection Chapitre 18

Chap. 18

Machines virtuellesMachines virtuelles Le concept de protection de base dans l’infonuagique (cloud

computing) Chaque machine virtuelle se comporte comme un ordi

séparé donc en principe ses données ne peuvent pas être saisies de la part d’une autre machine virtuelle

Chaque usager aura donc sa propre machine virtuelle

Page 10: Chap. 18 Protection Chapitre 18

Chap. 18

Mécanismes de protection de baseMécanismes de protection de base

Modes superviseur – usager (bit dans UCT) L’UCT passe en mode superviseur par effet d’une interruption,

qui peut être provoquée par une application P.ex. appel au système

Elle passe en mode usager par requête du SE Instructions privilégiées – peuvent être exécutées

seulement en mode superviseur interruption si un usager cherche à les exécuter Les instructions importantes pour la protection sont

privilégiées Le fait que les instructions d’E/S sont protégées

permet la protection des fichiers

Page 11: Chap. 18 Protection Chapitre 18

Chap. 18

Protection de zones de mémoire principaleProtection de zones de mémoire principale

Contrôle d’adresses générées pas la MMU bornes inférieures, supérieures ne peuvent pas être modifiées en mode usager les tentatives d’accéder à une adresse au delà des bornes

causent une interruption

Page 12: Chap. 18 Protection Chapitre 18

Chap. 18

Partage et protection de segments (ou de Partage et protection de segments (ou de pages)pages)

Deux processus qui partagent un programme

Mais les données de l’un sont protégées par rapport à l’autre

Page 13: Chap. 18 Protection Chapitre 18

Chap. 18

Protection de segments partagésProtection de segments partagés

Tabl. segms. Proc. 1

Protection sur le chemin d`accès entre processus et segment

Le contrôle d ’accès est effectué chaque fois qu’une adresse est calculée (donc besoin de matériel qui fasse ceci)

Tabl. segms. Proc. 2

R,W

R

Segment

partagé

Les deux proc partagent un segment, cependant Proc. 2 ne peut que le lire

Lim. Base

Page 14: Chap. 18 Protection Chapitre 18

Chap. 18

Couches dans les systèmes de protectionCouches dans les systèmes de protection

Couche 1: Chiffrement Couche 2: Contrôle d’identité Couche 3: Contrôle d’accès Couche 4: Contrôle de flux Couche 5: Protection de l’intimité

(privacy)

Page 15: Chap. 18 Protection Chapitre 18

Chap. 18

Couche 1: ChiffrementCouche 1: Chiffrement

Tout le système de sécurité dépend de la capacité de chiffrer certaines informations critiques pour les garder sécrètes Mots de passe Certains fichiers

Page 16: Chap. 18 Protection Chapitre 18

Chap. 18

Couche 2: Contrôle de l’identitéCouche 2: Contrôle de l’identité

Aussi, tout système de sécurité dépend de la capacité d’identifier les personnes, processus, etc. qui interviennent dans un système,

Ainsi que de déterminer leurs droits et prérogatives sur les différentes ressources du système

Cette couche utilise les fonctionnalités de la couche chiffrement

Page 17: Chap. 18 Protection Chapitre 18

Chap. 18

Couche 3: Contrôle d’accèsCouche 3: Contrôle d’accès

Cette couche gère les requêtes des personnes, processus etc. qui demandent accès aux différentes ressources, données etc.

Pour lire, écrire, exécuter, etc. Intercepte les requêtes des usagers, et

autorise ou nie l’accès Cette couche utilise les fonctionnalités de

la couche du contrôle de l’identité, pour déterminer qui est qui et qui peut faire quoi

Page 18: Chap. 18 Protection Chapitre 18

Chap. 18

Couche 4: Contrôle de fluxCouche 4: Contrôle de flux

Cette couche détermine qui peut avoir accès à quelle information dans un système Ex: un employé ne peut pas avoir accès au

salaire d’un autre employé, ni directement ni indirectement

Elle utilise les fonctionnalités de contrôle d’accès

Page 19: Chap. 18 Protection Chapitre 18

Chap. 18

Couche 5: Protection de la vie privée (Privacy) Couche 5: Protection de la vie privée (Privacy)

Cette couche se préoccupe d’implémenter les exigences de protection de la vie privée des individus

P.ex. dans un réseau social certains individus pourraient demander que certaines informations (disons date de naissance) ne soient pas accessibles à autres individus

Utilise les fonctionnalités du contrôle de flux

Page 20: Chap. 18 Protection Chapitre 18

Chap. 18

Modèles de protectionModèles de protection

Page 21: Chap. 18 Protection Chapitre 18

Chap. 18

Modèles MAC et DACModèles MAC et DAC

Modèles MAC: Mandatory Access Control Le SE, programmé par un administrateur,

détermine qui peut faire accès à quelles informations et pour faire quoi

Accès aux informations selon les qualifications (credentials) de l’usager qui cherche à faire accès

Application: systèmes d’haute sécurité Modèles DAC: Discretionary Access Control

L’usager a le contrôle d’accès à ses données Peut déterminer qui peut accéder à quoi

Page 22: Chap. 18 Protection Chapitre 18

Chap. 18

Systèmes MAC et leurs implémentationsSystèmes MAC et leurs implémentations

Page 23: Chap. 18 Protection Chapitre 18

Chap. 18

Exemple d’application militaireExemple d’application militaire

•Le soldat simple ne peut pas savoir (lire) ce que le général sait,

•Mais il peut l’informer (écrire)

• No read up, no write down•Read down, write up

Page 24: Chap. 18 Protection Chapitre 18

Chap. 18

Modèle Bell-La Padula: un système MACModèle Bell-La Padula: un système MAC

Les Objets (données, fichiers) sont classifiés en catégories de secret P.ex. Public, Classifié, Secret, Très Secret

Les Sujets sont classifiés en catégories d’habilitation (clearance) par rapport aux données auxquelles ils peuvent avoir accès: P.ex. Soldat dans Public, Capitan dans Classifié, Colonel dans

Secret, Général dans Très Secret Règles:

Un sujet ne peut pas lire dans une catégorie plus élevée No read up – read down permis

Un sujet peut ne peut pas écrire dans une catégorie moins élevée

No write down – write up permis

Page 25: Chap. 18 Protection Chapitre 18

Chap. 18

ExerciceExercice

Prouver que ce mécanisme empêche vraiment la circulation de l’information dans la direction non souhaitée Non seulement de manière directe, mais aussi

de manière indirecte

Page 26: Chap. 18 Protection Chapitre 18

Chap. 18

ImplémentationsImplémentations

Multics a implémenté ce concept déjà à partir des années 196X

Les systèmes Intel ont fourni du matériel pour ceci à partir des modèles x86 Mais les implémentations logiciel ont tardé

Linux implémente maintenant un modèle de protection à anneaux Le nombre de niveaux varie

Page 27: Chap. 18 Protection Chapitre 18

Chap. 18

Multics: Anneaux de protection Multics: Anneaux de protection (`peau d’oignon`)(`peau d’oignon`)

Extension du concept de mode superviseur-usager (chaque mode est un anneau)

Chaque anneau est un domaine de protection Les anneaux les plus internes sont les plus

essentiels, les plus privilégiés, et les plus protégés

Page 28: Chap. 18 Protection Chapitre 18

Chap. 18

Affectation de processus aux anneauxAffectation de processus aux anneaux

Exemple: anneau 0: noyau du SE anneau 1: fonction d’administration système anneau 2: programme de correction du prof anneau 3: programme de l`étudiant

Chaque segment d’un processus est affecté à un anneau À un moment donné, un processus se trouve dans un anneau Quand un proc. se trouve dans un anneau n, il peut

accéder librement aux segments dans l ’anneau n, ou anneaux extérieurs

il ne peut pas accéder aux segments dans les anneaux intérieurs

Page 29: Chap. 18 Protection Chapitre 18

Chap. 18

Mécanisme d’anneauxMécanisme d’anneaux

L’UCT a un registre qui contient le numéro de l’anneau où elle est en train d ’exécuter

Un proc qui exécute dans un anneau peut accéder aux données dans les anneaux plus externes. cependant ses capacités peuvent être limitées par rapport à

certains fichiers (R,W,E) comme discuté (need to know) L’appel aux procédure plus externes et relativement libre,

cependant il faut `copier` les params dans une zone où il puissent être lus en exécutant dans un anneau qui a moins de capacités

Il faut aussi se préoccuper que les paramètres puissent être rendus disponibles au niveau plus externe

L’appel aux procédures plus internes est contrôlé par le SE par des règles rigoureuses: v. manuel

Page 30: Chap. 18 Protection Chapitre 18

Chap. 18

Intégrité et diffusion de l’informationIntégrité et diffusion de l’information

Le système Bell-LaPadula se préoccupe de limiter l’accès aux informations

Dans d’autres systèmes, la préoccupation pourrait être surtout de sauvegarder l’intégrité de l’information P.ex. qu’un subordonné, pouvant écrire en

haut, pourrait modifier les directives provenant de là

Page 31: Chap. 18 Protection Chapitre 18

Chap. 18

Système BibaSystème Biba

Le système Biba se préoccupe justement de protéger l’intégrité des infos des niveaux supérieurs

Règles: Un sujet ne peut pas écrire dans une catégorie

plus élevée No write up – write down permis

Un sujet peut ne peut pas lire dans une catégorie moins élevée

No read down – read up permis Persuadez-vous que les information plus sécrètes

ne peuvent pas être corrompues

Page 32: Chap. 18 Protection Chapitre 18

Chap. 18

Domaines d’applicationDomaines d’application

Il est clair que Bell-LaPadula et Biba ne peuvent pas simultanément être en vigueur pour les mêmes sujets et données

Cependant chacun a son domaine d’application dans une entreprise, p.ex.: Les subordonnés peuvent écrire en haut les statistiques de

vente, les gérants ne peuvent pas les changer (Bell-LaPadula)

Les gérants peuvent écrire en bas les politiques de vente, les subordonnés ne peuvent pas les changer

On peut donc penser à une répartition d’une organisation: Partie où on applique BLP et partie où on applique Biba

Page 33: Chap. 18 Protection Chapitre 18

Chap. 18

Systèmes DAC:Systèmes DAC: Discretionary Access Control Discretionary Access Control

Page 34: Chap. 18 Protection Chapitre 18

Chap. 18

Domaines d’exécutionDomaines d’exécution

Page 35: Chap. 18 Protection Chapitre 18

Chap. 18

Domaines d’exécution: modèle abstraitDomaines d’exécution: modèle abstrait

Nous avons dans un systèmes des ‘domaines d’exécution’ qui déterminent ce qu’un processus peut faire quand il se trouve dans chaque domaine

L’impression de O4 peut être effectuée dans domaine D2 ou D3, pas D1

Page 36: Chap. 18 Protection Chapitre 18

Chap. 18

Changement de domaines d’exécutionChangement de domaines d’exécution

À chaque moment dans son exécution, un processus (ou usager...) se trouve dans un domaine d’exécution

En exécutant, un proc peut passer d’un domaine à un autre

L’impression de O4 peut être effectuée dans domaine D2 ou D3, pas D1

Page 37: Chap. 18 Protection Chapitre 18

Chap. 18

Réalisation de domaines Réalisation de domaines

Un usager peut être associé à un domaine changement de domaine au moment de changement

d’usager Un processus peut être associé à un domaine

changement de domaine au moment de changement de processus

Une procédure ou méthode peut être un domaine changement de domaine au moment de changement

de procédure ou méthode

Page 38: Chap. 18 Protection Chapitre 18

Chap. 18

Méthode de la matrice d’accèsMéthode de la matrice d’accès

Indique les capacités d’un processus exécutant dans un domaine Di sur différents objets

capacités du dom. D2

capacités sur le fichier F2

Page 39: Chap. 18 Protection Chapitre 18

Chap. 18

La matrice d’accès sépare le mécanisme des critèresLa matrice d’accès sépare le mécanisme des critères

Mécanismes Le SE fournit la matrice d’accès et les règles Assure que la matrice ne soit manipulée que

par des agents autorisés et que les règles soient respectées

Critères (politiques, policies) sont dictés par les usagers quels domaines peuvent accéder à quel objet

avec quelles capacités

Page 40: Chap. 18 Protection Chapitre 18

Chap. 18

Extensions de la méthode de la matrice Extensions de la méthode de la matrice d’accèsd’accès

Page 41: Chap. 18 Protection Chapitre 18

Chap. 18

Changement de domaine comme capacitéChangement de domaine comme capacité

Un usager qui se trouve dans le domaine D2 peut changer au domaine D3 ou D4.

Page 42: Chap. 18 Protection Chapitre 18

Chap. 18

Capacité de copier les droits d’accèsCapacité de copier les droits d’accès

Un processus peut avoir le droit de recopier un droit d’accès d ’un domaine à un autre (signalé par *) p.ex. un proc exécutant dans domaine D2 peut copier son

droit d ’accès sur fichier F2 à un autre domaine

Après modif

Page 43: Chap. 18 Protection Chapitre 18

Chap. 18

Droits de propriétaireDroits de propriétaire

Droit d ’un propriétaire de changer les droits d’autres sur les objets qui lui appartiennent si (i,j) contient owner, un proc dans Di peut ajouter ou enlever

des droits dans la colonne j

Page 44: Chap. 18 Protection Chapitre 18

Chap. 18

Implantation des matrices d’accèsImplantation des matrices d’accès

Difficile à implanter de façon que chaque accès de mémoire puisse être contrôlé

Tableau global. Désavantages: grand, éparpillé, doit être paginé

Par colonne: chaque objet est associé à une liste d’accès (qui peut faire quoi sur l ’objet) facile à mettre à jour à partir de l ’objet difficile à mettre à jour à partir des domaines

Par ligne: chaque domaine est associé à une liste de ses capacités facile et difficile: contraire du précédent

etc: v. discussion dans manuel

Page 45: Chap. 18 Protection Chapitre 18

Chap. 18

Mécanismes serrure-clé (lock-key): Mécanismes serrure-clé (lock-key): un compromisun compromis

Chaque objet a une liste de patrons de bit unique: ses serrures

Chaque domaine a aussi une liste de patrons de bits unique: ses clés

Un processus qui exécute dans un domaine a accès à un objet seulement si une des clés du domaine correspond à une des serrures sur l’objet

Serrures et clés sont gérées par le SE

Page 46: Chap. 18 Protection Chapitre 18

Chap. 18

Solutions mixtes: exempleSolutions mixtes: exemple

Les objets ont des listes d’accès Quand un processus cherche à accéder à un objet

(p.ex. un fichier) le SE cherche sur la liste d’accès de l`objet si le domaine du proc a droit d’accès à l’objet

Si oui, la capacité d’accéder à l’objet est ajoutée à la liste des capacités du processus Dans le cas de segmentation, quand un nouveau

segment est ajouté à un proc, on crée une entrée additionnelle dans le tableau des segments, avec la protection appropriée

Page 47: Chap. 18 Protection Chapitre 18

Chap. 18

Fonctionnement possibleFonctionnement possible

Le tableau de segments d’un proc qui a droit d’accès à 2 segms

R

R,W

R

R,W R,W

X

Le proc a demandé accès à un 3ème segment pour l’exécuter. Le SE contrôle qu’il a droit, si oui il ajoute le droit d’accès au tableau des segments du processus

lim base

Page 48: Chap. 18 Protection Chapitre 18

Chap. 18

Solutions basées sur les langages de Solutions basées sur les langages de programmationprogrammation

Les langages de programmation peuvent inclure des énoncés qui déterminent les droits de protection. p.ex. en Java contrôle d ’accès aux méthodes et variables

Considérations: Fiabilité J :un système basé sur les mécanismes d ’un

langage de programmation est moins fiable que un système basé sur le noyau du SE

Efficacité J : un système qui utilise le noyau, le matériel, etc. sera normalement plus efficace

Flexibilité +: un système basé sur un langage de programmation sera plus flexible et plus adapté aux besoins de l ’usager

Cependant, le langage de programmation peut faire appel au noyau.

Page 49: Chap. 18 Protection Chapitre 18

Chap. 18

ConclusionConclusion

Les exigences de protection peuvent être très complexes

La méthode de la matrice d’accès est puissante et générale, mais son implantation efficace est problématique

Les systèmes réels cherchent à approximer le résultats désirés par des solutions mixtes

Page 50: Chap. 18 Protection Chapitre 18

Chap. 18

Concepts importants du chapitreConcepts importants du chapitre

Niveaux de protection Modèle de protection à couches: 5 couches Protection de diffusion et d’intégrité:

Bell-LaPadula, Biba Implémentation de Bell-LaPadula dans système Multics Domaines d’exécution Besoin de connaître Protection sur les descripteurs des segments Matrices d’accès

Copier, modifier, octroyer les droits d’accès Implémentation des droits d’accès:

Listes d’accès aux objets Liste de capacité des processus Compromis, solutions mixtes

Page 51: Chap. 18 Protection Chapitre 18

Chap. 18

Par rapport au livre: Chap 18Par rapport au livre: Chap 18

Sauf Protection en Unix Mécanismes spécifiques: Hydra, CAP etc. Section 18.6: connaissance générale