Page 1 Outline I- Introduction II- Definitions III- Common vulnerabilities and threats IV- Authentication V- Access control

Page 1

Outline

I- Introduction

II- Definitions

III- Common vulnerabilities and threats

IV- Authentication

V- Access control

Page 2

Concepts for Access Control

Subjects = active entities in the IS Users, user processes, threads

Objects = passive entities in the IS Contain information under protection (files, relation in a relational

database, directory, memory cell…)

Operations = allow the subject to act on objects Reading of a file, deletion of a directory, request in a database

A subject has permissions to carry out operations on objects

OperationCarries

out Actson

V- Access controlDefinitions

Subject Object

Page 3

V- Access controlDefinitions

Generic access control models [Lampson, 74]

« Reference Monitor » : Decision procedure that filters the acces request Enforces an access control policy

Operation(acces request)Subject Object

ReferenceMonitor

Access denied

Identification/Authentication Authorization

Page 4

Mandatory Access Control (MAC)

The system decides to accept or deny an access request to an object, and a subject cannot modify this decision

Based on rules describing the conditions to accept an access request

Example : Multi-level security models

V- Access controlAccess control paradigms

Subjects Objects

Server 1“Top Secret”

Serveur 3“Confidential”

Server 2“Secret”

Authorized read access

Subject 1“Top Secret”

Subject 2“Top Secret”

Subject 3“Confidential”

Subject 4“Confidential”

Rule: a subject can read an object if its security level is greater than the security level of the object

Top Secret > Secret > Confidential

Page 5


Discretionary Access Control (DAC) A subject can decide to accept or deny an access request to an object that

he owns

Access permissions are defined, deleted, modified, or handed over at the discretion of the owner of the object

Based on the identity of the subject requesting the access and on access permissions defined on objects

The organization delegate a part of its rights to each user (the way according to which a user delegates his rights may be controlled)

Example : Access control to files and directories in Unix

Subjects Objects

File 1: owner s1 rwx I --- I ---

File 2: owner s2 rw- I rw- I r--

s1

s2

s3

r, w, x

r, w

r, w

r

Group 1

Group 2

Page 6


DAC: context of application

Do not satisfy the least privilege principle: a user may give more permissions than necessary

A permission on an object may be handed over without its owner knowing: A gives a read right on one of its files to B, B copies this file, B being the owner of

this copy can hand over his read right to C A must trust B

Trust is not always enough: A owns a sensitive file f, B has no permission to read it B implements a Trojan, and succeeds in persuading A to execute it When A execute the Trojan, it runs with A’s permissions, and is able to copy f

Not suited to environment dealing with very sensitive information

Page 7


MAC: context of application Objective:

Control the information flow without trusting the environment Ensure a partitioning between different kind of information

Principles: Based on the content of the information, i.e. its sensitivity A sensitivity level (label) is attached to each object A subject must obtain a mandate (authorization) to access to a sensitive

information These mandates are distributed by the organization

In practical: Most widespread model: multi-level security in the military domain Bell LaPadula model

Page 8


Role Based Access Control (RBAC)

Access to an object is accepted or denied depending on the role of the subject

Example: a role of a subject corresponds to its function in an organization

May be implemented as a set of privilege

Subjects Roles Operations

Role 1

Role 2

Role 3

Op 1

Op 3

Op 2

Page 9

V- Access controlAccess operations

Access modes

Observation: examine the content of an object

Alteration: modify the content of an object

Access permission (right, attribute)

Example: permissions in Bell-LaPadula model

exec (e) write (w)

observe

alter

x

x

append (a)

x

read (r)

x

Page 10

V- Access controlAccess operations

Access permission in Multics

Permissions are different depending on the system and on the objects

Access permission in Unix

Access permission in Windows 2000 Full Control, Modify, Read & Execute, Read, and Write + Special

permissions

File permissions Directory permissions

read

execute

read & write

write

status

modify

append

search

Effect on file Effect on directory

r

w

e

list content

create or rename a file

read

write

execution search

Page 11

V- Access controlAccess control structures

Access control matrix S set of subjects s, O set of objects o D set of permissions M is a matrix whose lines (resp. columns) are indexed with subjects

(resp. objects): the cell M[s,o] contains the access permissions of s on o

Example: the modelled system contains 3 processes (s1, s2, and s3), 3 files (o1 et o2, and o3), 3 permissions

(r=read, w=write, e=execute)

o1 o2 o3

s1 r,w r,e

s2 r,w,e

s3 w

subjectsobjects

Page 12


Other interpretations of Access Control Matrix

Modelling of a programming language Subjects = procedures/modules Objects = procedures/variables Permissions = ability to execute some functions

Modelling of a LAN Subjets = host stations Objects = host stations Permissions = protocols

Other notions of permissions

Evaluation of a boolean expression

Contextual information

Access based on the history of previous access

Hôtes Station1 Station2 Station3

Station1 ftp ftp,mail

Station2 ftp,nfs ftp,nfs

Station3 mail ftp ftp,nfs

Compt Inc_ctr Dcr_ctr

Inc_ctr +

Dcr_ctr -

Manager call call

Page 13


Implement a matrix is costly, in practical:

Use of access control list, or

Use of capacities

Access control list (ACL) : column representation

Each object comes with a list specifying all subjects (or user group) and their permissions

Used in Multics, Windows 2000

To know the permissions of a specific user (in case of a revocation): it is necessary to scan all ACLs

s1 r,wo1 s2 r,w,eo2 s3 wo3 s1 r,e

Page 14


Capacities: line representation

Use of tickets t=(o,P), where o is an object, and P a set of permissions: a subject holding t can access to o with permissions in P

A subject holding a capacity must not be able to modify it, or to build a new capacity

A subject may transfer the capacity to another subject

Used in micro-kernel L4, Capsicum, …

For a specific object it is difficult to know the set of subjects that can access to it

Requires mechanisms to revoke capacities

o2 r,w,es2 o3 ws3o3 r,es1 o1 r,w

Page 15


Protection bits Column representation with a structuration into groups Impossible to specify the access permissions of a particular user

Interdiction (negative permission) Define which subject cannot access to an object If added to protections: permits to refine permissions

Protection ring Each subject and object is associated with a ring number,

n°0 corresponds to the strongest protection Access control is decided according to a comparison of ring numbers of subject and object Used in Multics, intel80386/80486 processors

Privilege set of permissions focuses on the operations (system administrator, …)

0 1

2

3

Page 16

IV- Fonctions de sécurité2. Contrôle d’accès Contrôle d’accès multi-niveaux

Contrôle d’accès multi-niveaux

Pour certaines politiques de sécurité, il est nécessaire de considérer différents « niveaux » de sécurité

Niveaux de sécurité Niv ensemble des niveaux : les objets sont classifiés en fonction de leur

sensibilité : Exemples

Niv est complètement ordonné, T>S>C>NC et R>Prop>Sens>Pub

Top Secret (T)

Secret (S)

Confidentiel (C)

Non Classifié (NC)

Domainemilitaire

Restreint (R)

Propriétaire (Prop)

Sensible (Sens)

Publique (Pub)

Domainecommercial

Page 17


Catégories de sécurité

Cat : ensemble des catégories, permet de partitionner les objets de manière non hiérarchique

Principe du besoin d’en savoir (« need to know ») : l’information n’est tranférée qu’aux sujets qui en ont besoin

Exemples

Ensemble non ordonné Les parties de Cat sont partiellement ordonnées par

Dept. ADept. B

Dept. C

Domainecommercial

Domainemilitaire

US EUR

ASIE

Page 18


Labels de sécurité

L’ensemble des labels de sécurité : LS=NivP(Cat)

Exemple de label : (T,{US,EUR})

Relation d’ordre partielle induite : dom (« domine »)

(niv1,ens_cat1) dom (niv2,ens_cat2) ssi niv1 niv2 et ens_cat2 ens_cat1

Exemple : (T,{US,EUR}) dom (S,{US})

(LS,dom) est un treillis (dom est une relation d’ordre partielle et il

existe une borne inf et une borne sup pour chaque couple (l1,l2) de

LS)

Exercice : construire le treillis pour Niv={C,S} et Cat={US,EUR}

Page 19


(C,)

(C,{US}) (C,{EUR})(S,)

(S,{US}) (S,{EUR})(C,{US,EUR})

(S,{US,EUR})

Treillis des labels de sécurité

Exemple : Niv={C,S}, Cat={US,EUR}

Page 20


Habilitation : label de sécurité associé à un sujet

Classification : label de sécurité associé à un objet

Les sujets sont habilités à un niveau de sécurité pour un ensemble de catégories donné

Les sujets sont classifiés selon un niveau de sécurité et un ensemble de catégories donné

Sécurité multi-niveaux : permet de définir des politiques MAC en

compartimentant l’information.

Page 21


Implémentation des labels dans Unix System V/MLS

Nombre fixe de labels de sécurité et ensemble fixe de catégories

Administration des labels, catégories et labels par l’administrateur système

Sujets = processus UNIX, objets= fichiers et répertoires UNIX

Implémentation des labels : initialement utilisation de bits de l’identifiant de groupe, GID, codé sur 16 bits (versions suivantes : GID pointeur vers une structure contenant notamment les labels, insertion des labels dans les structures de nœuds d’indexes ou i-node)

Chaque utilisateur a un label défini au login, les processus associés héritant de ce label. Une commande permet à l’utilisateur de changer explicitement son label

Labels flottants : plage de label

Label de sécurité Catégories de sécurité GID

Bits 15 - 13 12 - 9 8 - 0

Label de sécurité

Page 22


Multi-niveaux sans distinction niveaux/catégories

Exemple : labels pour un firewall

Séparation stricte entre « l’intérieur » et « l’extérieur » d’un réseau

Privé

Interne Externe

Publique

Page 23

IV- Fonctions de sécurité3. Modèles de contrôle d’accès Modèle de Bell LaPadula

Historique BLP : modèle basé sur une machine à état conçu au MITRE [BLP73]

Sous contrat avec l’ « Air Force » Dans le cadre du développement de l’OS Multics

Un des modèles de sécurité les plus influents depuis 30 ans La politique du modèle BLP avait été intégrée dans les critères TSECs

Caractéristiques Capture les aspects confidentialité du contrôle d’accès Modèle multi-niveaux : l’information ne peut circuler d’un niveau donné

à un niveau inférieur BLP et Matrice de contrôle d’accès :

BLP utilise une matrice de contrôle d’accès pour décrire les contrôles d’accès discrétionnaires.

Page 24


Principe : Modèle = machine à états

éléments de base (sujets, objets, permissions, labels de sécurité)

état composé : d’une matrice des permissions d’accès d’un ensemble des accès en cours d’un ensemble d’affectations de labels de sécurité pour chaque sujet et

objet (calculées avec les fonctions de niveaux détaillées dans la suite)

la sécurité est définie par un ensemble de propriétés sur les états: SS-property + *-property + ds-property (+ tranquility)

ensemble de règles : règles de transition sur les états

Page 25


Model elements:

Set of subjects S, set of objects O

Set of permission P Observation without altération : read (r) Observation and alteration : write (w) Alteration without observation : append (a) No observation, no altération : execute (e)

An access control matrix built from S, O and P

Set of labels L with a partial order dom

Page 26


Model elements

Label function l l : S U O L , assigns a label to each subject and object

F, set of couples (s,l(s)) and (o,l(o)) for every subject s and object o

Set of current access, CA whose elements are triplets

(s,o,p) with s a subject, o an object and p a permission

States of the model : CA M F

A state of the model is described by the set of current access, an access control matrix and the assignment of labels to subject and object

Page 27


MAC policy in BLP

Simple security property (ss): a state of the model satisfies the property (ss) if for every current access (s,o,p) in AC with p {r,w} (observation) then l(s) dom l(o)

no read-up

A Trojan may still be able to copy the content of a sensitive file in a file with a lower label that a malicious user with a lower label can read it

Hence the following property

*-property (star-property, confinement property): a state of the model satisfies the *-property, if for every current access (s,o,p) in AC with p {w,a} (alteration) then l(o) dom l(s)

no write down

Page 28


BLP MAC policy

Label L1(L1 dom L2)

Label L2 O2

O1S1

S2

obs alt

obs alt

obs,alt

O3

Label L3 (L3 non comparable with L1 nor L2)

obs,alt

S3

obs,alt

obs,alt

No direct information flow from a higher object (o1) to a lower object (o2)!

Page 29


BLP DAC policy

The third proprerty deals with discretionary access

ds-property: a state of the model satisfies the property (ds) if for every current access (s,o,p) in AC, p appears in the cell [s,o] of access control matrix M.

Basic security theorem

A state is secure if properties (ss), (*), and (ds) are satistfied.

A transition from a state e1 to e2 is secure if e1 and e2 are secure

Theorem: if the initial state of a system is secure, and if each of its transitions is also secure, then all reachable state is secure.

Proof: induction on the sequence of transition Independent from BLP properties

Page 30


Un sujet s1 de label l1 ne peut pas envoyer de message à un sujet s2 de label l2 inférieur à l1 !

Solution : on distingue deux habilitations pour les sujets fm : S LS , détermine l’ « habilitation maximale » d’un sujet fc : S LS , détermine l’« habilitation courante » d’un sujet (fc(s) fm(s))

Deux interprétations

on diminue temporairement le label de s1 on considère que les connaissances d’un sujet se limitent à l’état courant si le sujet est un processus (sans mémoire), il ne peut accéder à un niveau

supérieur

on identifie un sous-ensemble de sujets de confiance de S qui peuvent violer la propriété *

cette approche est plus adaptée si les sujets sont des personnes physiques (avec une mémoire)

un sujet de confiance s peut se connecter avec une habilitation fc(s)

Page 31


BLP initialement conçu pour des transitions ne modifiant pas les labels de sécurité

Une transition diminuant le label de sécurité d’un objet viole la propriété de confinement (propriété *)

-> pb de la déclassification : définir un ensemble d’entité de confiance qui suppriment les informations sensibles avant de déclassifier

Propriété de tranquillité forte : les labels de sécurité ne changent pas

Autre possibilité : les labels de sécurité ne peuvent être diminués

Page 32


BLP a joué un rôle important dans la conception d’OS sécurisés

Used in Security-Enhanced Linux (SELinux), set of Kernel modifications and user-space tools that can be added to various Linux distributions

Limitations

Ne traite pas d’intégrité (choix)

Modèle rigide L’organisation garde une forte emprise sur le contrôle et la distribution

de l’information Beaucoup d’opérations sûres ne sont pas permises

Reste vulnérable aux canaux cachés Covert channel: information flow that is not controlled by any security

mechanism Canal de stockage / canal temporel Exple : noms d’objets, attaque par DPA (differential power analysis)

Page 33


Covert channel in BLP

Subject s2 wants to read the content of object o1 such that l(o1) dom l(s2)

Assume that s2 succeeded in installing a Trojan s1 with label l(s1)=l(o1), with s1 and s2 synchronized

Direct access forbidden in BLP

For each bit of o1 Trojan s1 reads the bit, and if bit=0, S1 does nothing, otherwise S1

creates a special file “Bit” with label l(s1) Subject s2 tries to read the file Bit ; if s2 receives a message “no such

file” s2 records 0, otherwise s2 receives a message “access forbidden” and records 1

s1 et s2 iterate n times

s1 can send to s2, n bits of information contained in o1

Informing a subject that an operation is forbidden is an information flow!

Page 34

IV- Fonctions de sécurité3. Modèles de contrôle d’accès Modèle de Biba

Modèle de Biba (1977)

Modèle multi-niveaux pour l’intégrité : éviter la contamination d’entités « saines » d’un niveau donné, par des entités « corrompues » de niveaux inférieurs

L’information ne peut s’écouler que du haut vers le bas

Treillis de labels d’intégrité (NI, domine)

fs et fo assignent les labels d’intégrité resp. à un sujet et à un objet

Les droits d’accès sont : read, write et execute

Notion de confiance implicite Plus haut est le label d’intégrité d’un sujet, plus on accorde de la confiance dans

le bon déroulement de son exécution Un objet avec un label d’intégrité donné est plus fiable qu’un objet avec un label

inférieur

Page 35


Plusieurs politiques

Politique d’intégrité stricte (duale de BLP) : labels statiques Propriété d’intégrité simple : un sujet s peut modifier un objet o

ssi fs(s) domine fo(o)

Propriété d’intégrité * : un sujet s peut observer un objet o ssi fo(o) domine fs(s)

Formulation alternative de la propriété d’intégrité *

Propriété d’intégrité * (faible): un sujet s peut observer un objet o ssi pour tout objet o’ qu’il est en train modifier fo(o) domine fo(o’)

Politique « Ligne de flottaison basse » : labels dynamiques Propriété Low watermark object : si un sujet s modifie un objet o

alors le label d’intégrité de o devient inf(fs(s),fo(o))

Propriété Low watermark subject : si un sujet observe un objet o alors le label d’intégrité de s devient inf(fs(s),fo(o))

Page 36


Chemin de transfert d’information : séquence d’objets o1, …, on+1, et de sujets s1, …, sn, tels que si r oi et si w oi+1 (1≤i≤n)

Succession de read et de write permettant de transférer une donnée d’un objet o1 dans un objet on+1

Théorème : s’il existe un chemin de transfert d’information entre des objets o1 et on+1, alors les deux politiques précédentes garantissent que f(o1) domine f(on+1) (pour n > 1).

Page 37


Propriété d’invocation : opération entre sujetsun sujet s peut exécuter un sujet s’ ssi fs(s) domine fs(s’)

Ajoutée aux 2 premières politiques d’intégrité : un sujet contaminé ne peut accèder indirectement à un objet sain en invoquant un sujet sain

Politique « en anneau » : Propriété simple : un sujet s peut écrire dans un objet o ssi fs(s)

domine fo(o) Propriété * : tout sujet s peut lire tout objet, indépendamment des

labels d’intégrité Propriété d’invocation : un sujet s exécuter un sujet s’, ssi fs(s’)

domine fo(s)

Inverse de la propriété d’invocation : le sujet invoqué devra effectuer des vérifications de consistence afin de s’assurer qu’il reste sain

exemples : LOMAC dans Free Bsd (module implémentant la politique « Ligne de flottaison basse »)

Page 38

IV- Fonctions de sécurité3. Modèles de contrôle d’accès RBAC

Principe

Se base sur le fait que les utilisateurs jouent un rôle précis dans l’organisation dont on peut déduire les permissions (privilèges)

Permet de représenter la structure d’une organisation sous-forme hiérarchique

Modèle RBAC = Role-Based Access Control

Premiers travaux : NIST, 1992

Modèle de base : RBAC96

Modèle d’administration des rôles : ARBAC97

Page 39


Eléments du modèle U : ens. d’utilisateurs R : rôles (fonctionnel, organisationnel, event participation à un projet) P : permissions S : sessions (les utilisateurs doivent toujours commencer par activer

une session), activée par un seul utilisateur, qui peut activer plusieurs rôles

AU : affectation des utilisateurs aux rôles (relation plusieurs-à-plusieurs) AP : affection des permissions aux rôles (relation plusieurs-à-plusieurs)

Page 40


Permissions

Users Rôles Opérations Objets

Sessions

User <-> Sessions(un à plusieurs)

AS(plusieurs à plusieurs)

AU AP

Page 41


Hiérarchie de rôles

Calquée sur la hiérarchie de l’organisation

Héritage des permissions d’un rôle vers les rôles séniors écriture rapide de la politique de contrôle d’accès

Plusieurs interprétations : spécialisation/généralisation : Ingénieur-> Ingénieur qualité ou Ingénieur

production hiérarchie organisationnelle : Directeur, Chef de projet, Ingénieur hiérarchie fonctionnelle : Ingénieur, ingénieur Devlpt, Employé

Page 42


Personnel

Personnel enseignantPersonnel administratif Personnel recherche

Secrétaire Chargé d’enseignement

Ingénieurde recherche

Maître de conférences

Professeur

Chef dedépartement

Page 43


Contraintes

Ajout de contraintes (expressions logiques) sur les affectations

Contraintes sur AU (utilisateurs <-> rôles) Un utilisateur ne peut cumuler certains rôles (séparation des fonctions ou des

pouvoirs) Contraintes de cardinalité

Contraintes sur AP (rôles <-> permissions) Certaines permissions ne peuvent être affectées à certains rôles (interdictions) Certaines permissions ne peuvent être affectées à plusieurs rôles Un rôle ne peut pas cumuler certaines permissions (séparation des tâches)

Contraintes sur AS (sessions <-> rôles) Contraintes sur l’activation des roles

Contraintes sur la hiérarchie de rôle

Page 44


ARBAC = administrative RBAC

Définit les règles et mécanismes pour gérer RBAC

Auto-administration

Une autorité centrale définit la hiérarchie de rôles, les permissions associées aux rôles les contraintes

L’affectation des utilisateurs aux rôles est décentralisée

On ajoute RA : rôles administratifs, RAR= PA : permissions administratives, PAP=

Administration de l’affection des rôles aux utilisateurs, et des permissions aux rôles

Page 45


On peut simuler les modèles DAC et MAC dans RBAC

Gestion des autorisations souple :

Assignement des rôles aux utilisateurs

Assignement des autorisations d’accès aux objets, aux rôles

Principe du moins privilège

Séparation des fonctions et des tâches

Modélisation partielle de l’organisation

Les rôles restent internes à une organisation

Aucun mécanisme de délégation

Page 46

IV- Fonctions de sécurité3. Modèles de contrôle d’accès Conclusion

Autres modèles : modèles pour les politiques de sécurité dans le monde médical modèles pour la disponibilité

Aucun modèle unique permettant d’exprimer toutes les exigences que peut contenir une politique de sécurité

Modélisation de l’organisation Structuration des utilisateurs Séparation des tâches et des fonctions Délégation et transfert de droits Administration de la politique de sécurité …

Besoin de nouveaux modèles de sécurité plus « dynamiques » : configurables et personnalisables suivant des profils d’utilisateurs, des flux dépendant du contexte, de la localisation, … Contrôle d’usage (UCON) : obligations

Documents

Page 1 Outline I- Introduction II- Definitions III- Common vulnerabilities and threats IV- Authentication V- Access control