4.4 Analyse des propriétés de sécurité
4.4.2.3 Bell&Lapadula restrictif
La règle de détectionconf_blprpermet d’énumérer toutes les violations de la propriété de confi-dentialité de BLPrestrictif (cf. prop. 3.3.12, page 81). Tout comme la règle précédente, cette règle requiert, comme paramètres, un ensemble de contextes SChabpossédant un attribut de type habilita-tionet elle renvoie un ensemble de signatures constitué d’interactions.
conf_blpr(SChab) début
IT:=∅;
pour chaque sc1∈ SChabfaire pour chaque sc2∈ SChabfaire
pour chaque it ∈ enum_interaction(sc1, sc2, Gint)faire si is_read_like(it.eo) et hab(sc1) < hab(sc2) alors
IT:= IT∪ it; fin
si is_add_like(it.eo) et hab(sc1) > hab(sc2) alors IT:= IT∪ it;
fin
si is_write_like(it.eo) et hab(sc1)6= hab(sc2) alors IT:= IT∪ it; fin fin fin fin Retourne IT ; fin
Nous définissons ainsi trois conditions permettant d’extraire les interactions dans le graphe d’in-teractions violant les trois lois du modèle BLPrestrictif. La première correspond aux interactions de lecture entre sujets et objets dont le niveau d’habilitation du sujet hab(sc1) est inférieur à celui de l’objet hab(sc2). La seconde correspond aux interactions d’ajouts entre sujets et objets dont le niveau d’habilitation du sujet hab(sc1) est supérieur à celui de l’objet hab(sc2). La dernière correspond aux interactions d’exécution où le niveau d’habilitation du sujet appelant hab(sc1) est différent de celui de l’appelé hab(sc2). Chaque signature est alors composée d’une interaction validant l’une des trois conditions précédentes.
4.4.2.4 Cohérence d’accès aux données
La règle de détectionconf_datapermet d’énumérer toutes les violations de la propriété de cohé-rence d’accès aux données(cf. prop. 3.3.13, page 81). Cette règle prend en paramètres deux contextes de sécurité scsourceet sccible. Les signatures correspondent alors à des accès à l’information possibles
entre ces deux contextes auxquels aucun transfert d’informations directe n’est associé.
conf_data(scsource, sccible, Gc) début
COM B:=∅;
pour chaque cmb = enum_accesinf(scsource, sccible, Gint, Gf lux, Gc)faire si cmb 6= ∅ et enum_interaction(sccible, scsource, Gcf lux)==∅ alors
COM B:= COM B∪ cmb; fin
fin
Retourne COMB; fin
Cette règle de recherche vérifie que pour chaque accès à l’information cmb, un transfert d’infor-mations est possible. Dans le cas contraire, chaque accès à l’information est alors ajouté à l’ensemble des violations (COMB).
La propriété de cohérence d’accès aux données d’un système (prop. 3.3.14) est alors appliquée par appels successifs à cette règle de recherche (un appel par couple passé en paramètres). Ceci permet alors, via la définition de deux ensembles de contextes SCsource et SCcible, d’énumérer toutes les violations possibles des éléments de SCsourcesur les éléments de SCcible.
Exemple Pour l’exemple de politique de contrôle d’accès (cf. listing 4.1, page 92), nous pouvons définir les ensembles de contextes suivants :
SCuser={scuser_d, scuser_info_t}
SCadmin={scadmin_d, scadmin_info_t}
La règle conf_data(SCuser, SCadmin) applique la propriété de cohérence d’accès aux données de l’administrateur pour les utilisateurs. Ainsi, l’utilisateur n’ayant pas un accès direct aux fichiers d’in-formations scadmin_info_t, la corrélation suivante sera considérée comme illégale et correspondra donc à une signature :
scuser_d−−−→ sctrans webserv_d∧ scadmin_info_t > scwebserv_d
4.4.3 Abus de privilèges
Le dernier ensemble de règles de détection correspond aux propriétés d’abus de privilèges définies dans la section 3.3.3. Chaque règle de détection renvoie un ensemble de signatures correspondant à un abus de privilèges autorisé par la politique de contrôle d’accès. Le tableau B.3 (page 192) reprend, pour chaque règle de détection, les conditions recherchées, le type de graphe utilisé et le type de signature renvoyé. Dans cette partie, nous détaillons le fonctionnement de chaque règle de détection d’abus de privilèges.
4.4.3.1 Séparation de privilèges
La règle de détection duties_seppermet d’énumérer toutes les violations de la propriété de sé-paration de privilèges(cf. prop. 3.3.16, page 83). Rappelons que cette propriété a pour objectif de prévenir toute modification puis exécution, directe ou par séquence, d’un objet par un sujet. Chaque
4.4. ANALYSE DES PROPRIÉTÉS DE SÉCURITÉ 121 signature est donc constituée d’une séquence de deux interactions ou de deux corrélations d’accès à un privilège.
duties_sep(Gc) début
SEQ:=∅; CM B:=∅;
pour chaque sc1∈ SCSfaire pour chaque sc2∈ SCOfaire
pour chaque it1∈ enum_interaction(sc1, sc2, Gint)faire pour chaque it2∈ enum_interaction(sc1, sc2, Gint)faire
si is_write_like(it1.eo) et is_execute_like(it2.eo)alors SEQ:= SEQ∪ {it1, it2};
fin fin fin
pour chaque eo1∈ IS faire pour chaque eo2∈ IS faire
si is_write_like(eo1) et is_execute_like(eo2)alors
pour chaque seq1∈ enum_accespriv(sc1, sc2, eo1, Gint, Gc)faire pour chaque seq2∈ enum_accespriv(sc1, sc2, eo2, Gint, Gc)faire
CM B:= CM B∪ {seq1, seq2}; fin fin fin fin fin fin fin Retourne SEQ ∪ CMB; fin
Chaque signature correspond à la possibilité pour un contexte sujet de modifier puis exécuter un contexte objet, violant ainsi la propriété de séparation de privilèges. La première partie de cette règle analyse le graphe d’interactions afin d’extraire les arcs étiquetés par les opérations élémentaires de modification et d’exécution. La seconde partie de cette règle énumère les accès aux privilèges de modification et d’exécution.
Notons que cette règle peut être raffinée pour prendre en paramètres qu’un ensemble de contextes SCdaemonafin de n’appliquer cette propriété qu’à cet ensemble, tel qu’énoncé dans la propriété 3.3.17 (page 83).
Notons finalement que cet algorithme n’est pas celui réellement implanté. Pour faciliter son écri-ture, dans ce manuscrit de thèse, nous considérons en effet tous les couples possibles d’opérations élementaires lors de la seconde énumération et nous ne considérons pas la combinaison d’un accès à un privilège et d’une interaction.
Exemple Pour l’exemple de politique de contrôle d’accès (cf. listing 4.1, page 92), nous pouvons définir les ensembles de contextes suivants :
SCsysteme ={sclogin_d, scssh_d, scapache_d, scwebserv_d}
Ainsi, la règleduties_sep(SCsysteme) n’applique cette propriété qu’aux services système. Dans cet exemple de politique de contrôle d’accès, les contextes scapache_det scwebserv_dpeuvent violer la propriété de séparation de privilèges. Ainsi les deux signatures suivantes permettront ce type d’abus :
scwebserv_d−−−→ scwrite var_www_t, scwebserv_d−−−−→ scexecute var_www_t
De même pour les combinaisons d’accès aux privilèges :
seq1= scuser_d−−−→ sctrans apache_d, scapache_d−−−→ scwrite var_www_t
seq2= scuser_d−−−→ sctrans apache_d, scapache_d−−−−→ scexecute var_www_t
4.4.3.2 Absence de changement de contexte
La règle de détection bad_transition permet d’énumérer toutes les violations de la propriété d’absence de changement de contexte (cf. prop. 3.3.19, page 84). Rappelons que cette propriété a pour objectif de prévenir tout changement d’un contexte sc1vers un contexte sc2. Cette règle prend donc en paramètres deux contextes sc1et sc2et renvoie un ensemble de signatures constitué de tran-sitionset de séquences de transitions.
bad_transition(sc1, sc2) début
Retourne enum_interaction(sc1, sc2, Gtrans)∪ enum_sequence(sc1, sc2, Gctrans); fin
Exemple Sur un système, nous pouvons interdire que le domaine administrateur ou les services Web soit accessibles suite à une connexion ssh. Ainsi toutes les opérations de maintenance devront être réalisées localement (vialogin). Si nous reprenons l’exemple de politique de contrôle d’accès (cf. listing 4.1, page 92), les règles suivantes permettent d’appliquer cette propriété au système :
bad_transition(scssh_d, scadmin_d) bad_transition(scssh_d, scapache_d) bad_transition(scssh_d, scwebserv_d)
Par exemple, ces règles renverront :
scssh_d−−−→ sctrans user_d−−−→ sctrans admin_d
scssh_d−−−→ sctrans user_d−−−→ sctrans admin_d−−−→ sctrans apache_d
scssh_d−−−→ sctrans user_d−−−→ sctrans webserv_d
4.4.3.3 Exécutables de confiance
La règle de détection tpepermet d’énumérer toutes les violations de la propriété d’exécutables de confiance(cf. prop. 3.3.20, page 84). Rappelons que cette propriété a pour objectif de prévenir toute exécution d’une application non présente dans l’ensemble T P E. Cette règle prend donc en pa-ramètres un ensemble de contextes de confiance T P E et renvoie un ensemble de signatures constitué
4.4. ANALYSE DES PROPRIÉTÉS DE SÉCURITÉ 123 d’interactions.
tpe(T P E) début
IT:=∅;
pour chaque sc1∈ SCSfaire pour chaque sc2∈ SCOfaire
si sc26∈ T P E alors
pour chaque it ∈ enum_interaction(sc1, sc2, Gint)faire si is_execute(it.eo) alors IT:= IT∪ it; fin fin fin fin fin Retourne IT ; fin
Une signature correspond ainsi à une interaction it dont le contexte cible n’appartient pas à l’en-semble T P E et qui est exécutable.