Mandatory Access Control On Distributed Systems: A Metapolicy Framework

1. Mandatory Access Control On Distributed Systems:A Metapolicy Framework Mathieu Blanc Commissariat à l’Énergie Atomique Laboratoire d’Informatique Fondamentale d’Orléans mathieu.blanc@cea.fr

2. Objectifs • Environnement distribué • Réseaux à grande échelle • Déploiement d’applications distribuées • Clusters de calcul ouverts • Systèmes de confiance • Politique de sécurité définie par l’administrateur • Contrôle d’accès obligatoire par un mécanisme centralisé • Modèles : MAC, RBAC • Exemples de mise en œuvre : SELinux, grsecurity… • Orientation • Propriétés globales à tout le système réparti (application de techniques de preuve) • Contrôle entièrement réparti (localité améliore la sécurité) • Tolérance aux pannes • Performances • Non interférence (Confidentialité, Intégrité)

3. Etat de l’art • Mécanismes statiques • Conçus pour des systèmes autonomes (standalone) • Faible prise en compte de l’aspect distribué • La politique toute entière est rechargée lors d’une modification • Mise à jour par un administrateur : manque d’autonomie • Exemples : SELinux, grsecurity • Mécanismes s’appuyant sur des échanges réseau • Prise en compte de l’aspect distribué • Repose souvent sur un composant central • Faible tolérance aux pannes (vulnérabilité aux attaques réseau) • Déploiement à grande échelle parfois difficile • Exemples : DSI, OrBAC, multipolitiques • Evolutions possibles de la politique mais sans mécanisme de contrôle avancé (repose sur des échanges, pas de langage de contrôle permettant des évolutions réparties, résolution de conflits)

4. Nouvelle approche • Contrôle décentralisé des évolutions • Meilleure tolérance aux pannes • Déploiement à grande échelle possible • Prise en compte des aspects distribués • Sécurité des applications distribuées • Supporte aussi le contrôle des communications • Propriétés de sécurité • Garantie d’un ensemble de propriétés de sécurité globales • Prévention d’évolutions contraires aux objectifs de sécurité (basée sur des techniques de preuves) • Temps de calcul borné (bonnes performances) • Nœuds autonomes • Possibilité de créations locales de nouveaux contextes et de nouvelles règles • Modifications ne nécessitent aucun échange réseau • Meilleures performances • Possibilité de décision locale face à une menace

5. Nouvelle approche • Architecture de méta-politique • Une méta-politique commune à tous les nœuds • Politique de sécurité initiale • Politique de contrôle des modifications • Acquisition de la méta-politique sur un bus spécifique • Evolution de la politique de sécurité • Propre à chaque nœud • Sous contrôle de la méta-politique • Les mises à jour doivent être autorisées par la politique de modification • Gestion locale de la mise à jour • Par un agent local • Sans nécessité d’échanges avec d’autres agents • Bonne tolérance aux pannes • Réaction locale aux attaques (défense active)

6. Meta-Policy Meta-Policy Vue générale Meta-policy bus Host A Host B Control agent Control agent Policy update queries A Policy update queries B Security Policy Security Policy Neutral language Neutral language User space Language Adapter Language Adapter Kernel space SELinux language GRSecurity language MAC MAC

7. Composants • Security Policy • Langage neutre pour exprimer les intéractions • Rend la solution indépendante du système cible • Définit la liste des accès autorisés • Modification Policy • Méta-langage contrôlant les nouvelles intéractions • Permet le contrôle local des modifications • Garantie les propriétés globales (supporte des techniques de preuves) • Language Adapter • Supporte les systèmes hétérogènes et la réutilisation • Traduit la politique de sécurité • A partir du langage neutre • Vers des mécanismes de contrôle d’accès cibles

8. Méta-langage • Modification des permissions d’accès • enableAddIT (sc; [scS; scO]; PVA) • enableRemoveIT and enableModifyIT • Modification des contextes de sécurité • enableCreateSC (sc) • enableModifySC (sc) • enableRemoveSC (sc) • Paramètres • sc : contexte de sécurité • PVA : ensemble de permissions concerné • Fonctions de mise à jour associées • addIT ([scS; scO];PVA) • createSC (sc) • remove et modify

9. Exemples d’application • Restriction des droits du serveur Web • Update Policy contient :enableRemoveIT(scIDS; [scapache; sc*]; [accept]) • Cette règle permet à l’IDS (contre-mesure) d’appeler la fonction :removeIT([scapache; sc*]; [accept]) • Le processus apache ne peut plus accepter de connexion

10. Modèle formel et vérification • Objectif : garantir la non-interférence entre un sujet et un objet • Déterminer si un chemin peut être établi entre un sujet et un objet (lien en lecture ou en écriture) • Recherche d’existence d’un chemin contradictoire / Pas de recherche exhaustive • Cas de règles statiques • Problème de la recherche de chemin dans un graphe • Sommets : contextes de sécurité • Arêtes : interactions autorisées • Cas de règles réparties et dynamiques • Le graphe global réel n’est pas accessible. Mais il est synthétisé par les règles de modification de la méta-politique. • La création de nouveaux contextes peut conduire à un graphe global potentiellement infini (bien que contraint et pouvant être régulier)

11. Modèle formel et vérification • Actuellement la politique définit les types ayant la permission de créer de nouveaux contextes (besoin lié à un cluster sur lequel on déploie de nouvelles applications) et les règles pouvant être ajoutées pour ces nouveaux contextes. • Exemple de méta-règles: • enableAddIT(sc; [A.x; A.x.y]; PVA), enableAddIT(sc; [A.x.y; A.x.z]; PVA) • Régularité: • Possible d’exprimer le graphe de flots d’information de manière régulière • Sous forme d’une expression régulière sur un alphabet ? (a.ab+ab.ac) • Ensuite l’atteignabilité entre 2 nœuds serait décidable (coût mais vérification possible) ? • Ecrire le motif (de manière décidable) et ensuite effectuer la clôture transitive soit par des techniques décidables (langage rationnel) ou par des techniques non décidables (assistant de preuves) • Nombreux autres choix pour le langage de règles avec des attributs permettant de catégoriser les interactions (ex : attribut web=apache) • Nombreuses techniques de vérification : parcours de graphes, techniques de réécriture, utilisation de la théorie des langages pour prouver des propriétés, etc… • Etudié dans le cadre de l’ACI SATIN

12. Travaux futurs • Modèle formel et vérification • Etude au LIFO et dans l’ACI SATIN • Implémentation du vérificateur • Application à des systèmes réels (cluster, FAI, etc…) • Détection d’intrusion et corrélation orientées politique • Etude à l’ENSI-Bourges et au CEA • La détection d’intrusion peut permettre de régler des problèmes de performances (garantie la politique sans l’appliquer) • Contre-mesures • Apprentissage de la méta-politique