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

  • 674 views
Uploaded on

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

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

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
674
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
0
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Linux Security ModulesDYNAMICS NETWORK LABS www.dynamics-network.com
  • 2. DYNAMICS NETWORK LABS Avant propos Linux Security Modules Security ?
  • 3. DYNAMICS NETWORK LABS Avant propos
  • 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. 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. 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. DYNAMICS NETWORK LABS Modèle formel Modèle formel
  • 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. 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. DYNAMICS NETWORK LABS Modèle formel - LOMAC •Mécanisme de water marking dobjets top secret secret confidentiel Non classé temps
  • 11. DYNAMICS NETWORK LABS Matrice de contrôle daccès : sujet et objet sujet contrôle daccès objets politique daccès
  • 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. 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. DYNAMICS NETWORK LABS Matrice de contrôle daccès : domaine obj3 obj0 r obj1 r r S0 r r obj2 r S1 domaine
  • 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. DYNAMICS NETWORK LABS Implémentation dans Linux Implémentation dans Linux
  • 17. DYNAMICS NETWORK LABS Implémentation dans Linux - framework •Infrastructure de hooks •Développement de modèle formel •Des « fonctionnalités partagées »
  • 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. 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. 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. DYNAMICS NETWORK LABS Piste de réflexion Pistes de réflexion
  • 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. 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. 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. 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. 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. DYNAMICS NETWORK LABS Piste de réflexion – orthogonalité : granularité vs dynamisme mise à jour de la politique grossière granularité de la politique dynamisme
  • 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. Linux Security ModulesDYNAMICS NETWORK LABS www.dynamics-network.com