Les mécanismes de contrôle d'accès du kernel linux

1,142 views
969 views

Published on

Les mécanismes de contrôle d'accès du kernel linux : histoire, théorie et évolution

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,142
On SlideShare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
0
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Les mécanismes de contrôle d'accès du kernel linux

  1. 1. Linux Security ModulesDYNAMICS NETWORK LABS www.dynamics-network.com
  2. 2. DYNAMICS NETWORK LABS Avant propos Linux Security Modules Security ?
  3. 3. DYNAMICS NETWORK LABS Avant propos
  4. 4. DYNAMICS NETWORK LABS Avant propos – la sécurité globalement •La sécurité est assurée par un principe de couche, notre couche sera le contrôle daccès •Modèle formel •Implémentation •Vérification •Critère dévaluation (orange book – DoD) •Sécurité ou outils dadministration système et réseau
  5. 5. DYNAMICS NETWORK LABS Avant propos - LSM •LSM est un framework proposant des vérifications de sécurité •Les implémentations actuelles reposent sur des modèles formels de type MAC (SELinux, Tomoyo, smack, apparmor) •Sans une de ces implémentations chargées, le kernel utilise les capabilities
  6. 6. DYNAMICS NETWORK LABS Approche •Modèle formel - théorie •Contrôle daccès •Implémentation dans Linux •Infrastructure LSM •Fonctions partagées •Pistes de réflexion, critique
  7. 7. DYNAMICS NETWORK LABS Modèle formel Modèle formel
  8. 8. DYNAMICS NETWORK LABS Modèle formel •Un modèle formel décrit une méthode de spécification de la politique de sécurité dun système •En pratique, il repose sur une idée fondatrice ou une technique •Le formaliste est introduit pour décrire lidée fondatrice ou la technique
  9. 9. DYNAMICS NETWORK LABS Modèle formel •LOMAC : Low Water-Mark Mandatory Access Control - 2000 •Bell-La Padula (BLP) – 1973 •object-capability - 1981 •Take-grant - 1977 •Biba – 1977 •Matrice de contrôle daccès – 1971 •..
  10. 10. DYNAMICS NETWORK LABS Modèle formel - LOMAC •Mécanisme de water marking dobjets top secret secret confidentiel Non classé temps
  11. 11. DYNAMICS NETWORK LABS Matrice de contrôle daccès : sujet et objet sujet contrôle daccès objets politique daccès
  12. 12. DYNAMICS NETWORK LABS Matrice de contrôle daccès meow R /home/meow/ W aegiap R /etc/passwd W R /tmp/foo sam W
  13. 13. DYNAMICS NETWORK LABS Matrice de contrôle daccès /etc/passwd /tmp/foo /home/meow meow - - { read, write } aegiap { read } - - sam { read } { read } { read, write }
  14. 14. DYNAMICS NETWORK LABS Matrice de contrôle daccès : domaine obj3 obj0 r obj1 r r S0 r r obj2 r S1 domaine
  15. 15. DYNAMICS NETWORK LABS Modèle par fonction de sécurité •Intégrité : BIBA, Clark Wilson •Confidentialité : HRU, Bell LaPadula, Take-Grant •HRU : matrice de contrôle daccès M(sujet x objet) •Take-Grant : formalisme de graphe •Bell LaPadula : classification des objets, habilitation des sujets
  16. 16. DYNAMICS NETWORK LABS Implémentation dans Linux Implémentation dans Linux
  17. 17. DYNAMICS NETWORK LABS Implémentation dans Linux - framework •Infrastructure de hooks •Développement de modèle formel •Des « fonctionnalités partagées »
  18. 18. DYNAMICS NETWORK LABS Les hooks LSM •include/linux/security.h •struct security_operations foo_ops { ... •.inode_create = foo_inode_create, •.task_kill = foo_task_kill, ... } •smack, SELinux, apparmor, tomoyo
  19. 19. DYNAMICS NETWORK LABS Les hooks userspace appel système Contrôle daccès accès ou refus TOCTOU : Time Of Check – Time Of Use
  20. 20. DYNAMICS NETWORK LABS Fonctionnalité partagée – critère de sécurité keys non répudiation disponibilité authentification sécurité confidentialité intégrité tracabilité crypto audit IMA
  21. 21. DYNAMICS NETWORK LABS Piste de réflexion Pistes de réflexion
  22. 22. DYNAMICS NETWORK LABS Piste de réflexion – projet LSM Condition dintégration des modules upstream •Il faut pouvoir expliquer la capacité défensive du nouveau module. •Pas compatible avec la gestion du projet upstream – « troll detected » •Exemples : stacking de modules, intégration tomoyo, rejet de fonctionnalités « because its not secure »
  23. 23. DYNAMICS NETWORK LABS Piste de réflexion : modèle par fonction de sécurité •Les modèles par thème (intégrité, confidentialité, etc) ne couvrent pas toutes les fonctionnalités •Impossibilité du stacking LSM •Utilisé un modèle protégeant lintégrité ne protègera pas les autres fonctions, et il est impossible de charger les autres modèles •Un mécanisme de hook, un seul module de sécurité ? (netfilter)
  24. 24. DYNAMICS NETWORK LABS Piste de reflexion : document, livres.. •Les LSM sont ils considérés comme un mécanisme essentiel du kernel ? (irq, process management, vfs, etc) •Les bouquins sur le kernel ne parlent pas des LSM
  25. 25. DYNAMICS NETWORK LABS Piste de réflexion – mécanisme de hook Le mécanisme de hook rend la création de module facile •Module formel au hack – regard sur les propositions •Refus dinnovation sur les modèles formel, 30 ans
  26. 26. DYNAMICS NETWORK LABS Piste de réflexion – ligne directrice Points difficiles •Politique monolithique implique configuration complexe - 350K+ lignes de conf, [application x fichier x action] •Pouvons nous rendre le contrôle daccès dynamique ? •Pouvons nous conserver la granularité ?
  27. 27. DYNAMICS NETWORK LABS Piste de réflexion – orthogonalité : granularité vs dynamisme mise à jour de la politique grossière granularité de la politique dynamisme
  28. 28. DYNAMICS NETWORK LABS Piste de réflexion – ligne directrice Points difficiles •Modèle monolithique cependant des fonctions partagées •Peut on séparer par thème ? Contrôle daccès en bloc : fs, net, mm, ... fs0 net0 mm0 fs1 net1 mm1 fs1 net0 mm2 mécanisme fs2 net2 mm2 déchange
  29. 29. Linux Security ModulesDYNAMICS NETWORK LABS www.dynamics-network.com

×