Alors, AppArmor et SELinux, ce sont 2 modules de sécurité du noyau (LSM, linux security module). L'idée est d'avoir des extensions du kernel pour accepter ou pas certaines opérations sur la base de critères externes ( voir ça comme un firewall pour les fonctions du kernel ).
Les LSM permettent plus que ces 2 la, mais je vais pas me disperser. Les 2 servent à appliquer des règles de qui a le droit de faire quoi plus souple que le simple modèle unix.
Ensuite, la ou ça diffère, c'est comment tu le fait. SELinux est un système de label couplé avec des règles. Tu mets un label sur les utilisateurs, sur les fichiers, sur les processus, etc, et tu écrit des règles pour régir l'interaction.
Par exemple, quelqu'un avec le label admin_u ( _u comme user ) a le droit de faire exec sur un fichier avec le label network_t ( _t comme type ), ce qui va donner un processus avec network-exec_t ( y a une regle qui dit comment les labels évoluent ). Et ce processus a le doit de faire tel ou tel chose, comme ouvrir un socket, et ainsi de suite.
Apparmor, c'est la même idée, sans les labels. IE, tu donnes direct les chemins de fichiers. Tu va dire "tel programme /usr/bin/toto a le droit de lire tel fichier, tel fichier, et faire tel opération". Par exemple, tu va dire que evince n'a pas le droit de lire ton .ssh, même si tu as le droit toi en tant qu'utilisateur de manipuler les fichiers. Si jamais un pdf contient un malware, il va pas piquer ta clé ssh.
Personnellement, je trouve SELinux plus souple, mais je suis partiel.
L'idée à la base, c'est de pouvoir confiner les processus et/ou les utilisateurs, ou de gérer des politiques obligatoires ( MAC, mandatory access control, par opposition à un DAC, discretionnary access control, qui sont les droits unix gérés par les utilisateurs eux mêmes, et donc potentiellement non conforme à ce que l'organisation veut ).
L'idée est que si tu as une faille dans un processus confiné, en temps normal ( ie non confiné ), il peut faire ce qu'il veut. Par exemple, si je prends la main sur apache via une faille, j'ai l'accès d'un utilisateur non privilégié et de la, je peux rebondir, faire des connexions vers l'extérieur, lancer des programmes avec d'autres failles, lire des fichiers non protégés, etc. Avec SELinux/AppArmor, tu peux interdire de faire ça.
Ça implique d'avoir une politique de sécurité, mais justement, Ubuntu propose des politiques ( appelés profil ) pour certains démons, Fedora/RHEL/Centos propose une politique SELinux des plus complètes
A partir de SELinux, tu peux aussi mettre en place différents modèles de sécurité des données, souvent mis pour des organisations militaires :
modèle Bell Lapadula, ou grosso modo, chacun a une classification ( donc un label assigné ), chaque document a une classification ( donc un label aussi ), par exemple, public, privée, confidentiel, top secret, par ordre de criticité. Les gens avec l'habilitation privée peuvent écrire un document privée, confidentiel, et top secret, et ne peuvent lire que public et privé. Ce qui fait que l'information top secret ne va jamais devenir moins que top secret ( sauf personne non soumise à la politique de sécurité ).
modèle Biba, qui est l'inverse, ou tu as par exemple 3 classifications, soldat, colonel, général. Les gens de rangs le plus haut peuvent écrire des documents à destination des gens en dessous, mais pas les lire. Et tout le monde peut lire les documents venant d'en haut. Et ça permet donc de formaliser la chaine de commandement d'une armée, ou par exemple, tu es sur que les ordres viennent bien d'une personne au dessus de toi. Le soldat ne peux pas donner d'ordre à un colonel, mais le général peut.
Formaliser la politique de sécurité permet de s'assurer que personne ne va faire des conneries comme virer les droits top secret par erreur.
( ensuite, il faut je précise d'autres mesures pour éviter d'autres attaques )
Enfin bon, je pourrais parler de SELinux pendant des heures, un peu moins de AppArmor ( je connais moins ) mais j’espère que mon explication t'a aidé.
[^] # Re: AppArmor et Selinux
Posté par Misc (site web personnel) . En réponse au journal OpenSUSE 13.1 Milestone1. Évalué à 10. Dernière modification le 18 mai 2013 à 00:13.
Alors, AppArmor et SELinux, ce sont 2 modules de sécurité du noyau (LSM, linux security module). L'idée est d'avoir des extensions du kernel pour accepter ou pas certaines opérations sur la base de critères externes ( voir ça comme un firewall pour les fonctions du kernel ).
Les LSM permettent plus que ces 2 la, mais je vais pas me disperser. Les 2 servent à appliquer des règles de qui a le droit de faire quoi plus souple que le simple modèle unix.
Ensuite, la ou ça diffère, c'est comment tu le fait. SELinux est un système de label couplé avec des règles. Tu mets un label sur les utilisateurs, sur les fichiers, sur les processus, etc, et tu écrit des règles pour régir l'interaction.
Par exemple, quelqu'un avec le label admin_u ( _u comme user ) a le droit de faire exec sur un fichier avec le label network_t ( _t comme type ), ce qui va donner un processus avec network-exec_t ( y a une regle qui dit comment les labels évoluent ). Et ce processus a le doit de faire tel ou tel chose, comme ouvrir un socket, et ainsi de suite.
Apparmor, c'est la même idée, sans les labels. IE, tu donnes direct les chemins de fichiers. Tu va dire "tel programme /usr/bin/toto a le droit de lire tel fichier, tel fichier, et faire tel opération". Par exemple, tu va dire que evince n'a pas le droit de lire ton .ssh, même si tu as le droit toi en tant qu'utilisateur de manipuler les fichiers. Si jamais un pdf contient un malware, il va pas piquer ta clé ssh.
Personnellement, je trouve SELinux plus souple, mais je suis partiel.
L'idée à la base, c'est de pouvoir confiner les processus et/ou les utilisateurs, ou de gérer des politiques obligatoires ( MAC, mandatory access control, par opposition à un DAC, discretionnary access control, qui sont les droits unix gérés par les utilisateurs eux mêmes, et donc potentiellement non conforme à ce que l'organisation veut ).
Ceci permet par exemple par une isolation des utilisateurs sur une plateforme comme openshift, ou chacun n'a accès qu'à son répertoire, ne voit pas les processus des autres ( http://www.youtube.com/watch?v=VaxkrSpBr6M pour les anglophones ), etc, à l'isolation des VMs les unes des autres ( voir libvirt et svirt http://namei.org/presentations/svirt-lca-2009.pdf , mais ça marche aussi avec AppArmor ), à la limitation des droits des applications bureautiques ( voir les propositions de Canonical sur le sujet : https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement ), etc.
Il existe par exemple plusieurs projets de sandbox comme https://www.stgraber.org/category/arkose/ , http://danwalsh.livejournal.com/28545.html , etc.
L'idée est que si tu as une faille dans un processus confiné, en temps normal ( ie non confiné ), il peut faire ce qu'il veut. Par exemple, si je prends la main sur apache via une faille, j'ai l'accès d'un utilisateur non privilégié et de la, je peux rebondir, faire des connexions vers l'extérieur, lancer des programmes avec d'autres failles, lire des fichiers non protégés, etc. Avec SELinux/AppArmor, tu peux interdire de faire ça.
Ça implique d'avoir une politique de sécurité, mais justement, Ubuntu propose des politiques ( appelés profil ) pour certains démons, Fedora/RHEL/Centos propose une politique SELinux des plus complètes
A partir de SELinux, tu peux aussi mettre en place différents modèles de sécurité des données, souvent mis pour des organisations militaires :
modèle Bell Lapadula, ou grosso modo, chacun a une classification ( donc un label assigné ), chaque document a une classification ( donc un label aussi ), par exemple, public, privée, confidentiel, top secret, par ordre de criticité. Les gens avec l'habilitation privée peuvent écrire un document privée, confidentiel, et top secret, et ne peuvent lire que public et privé. Ce qui fait que l'information top secret ne va jamais devenir moins que top secret ( sauf personne non soumise à la politique de sécurité ).
modèle Biba, qui est l'inverse, ou tu as par exemple 3 classifications, soldat, colonel, général. Les gens de rangs le plus haut peuvent écrire des documents à destination des gens en dessous, mais pas les lire. Et tout le monde peut lire les documents venant d'en haut. Et ça permet donc de formaliser la chaine de commandement d'une armée, ou par exemple, tu es sur que les ordres viennent bien d'une personne au dessus de toi. Le soldat ne peux pas donner d'ordre à un colonel, mais le général peut.
Formaliser la politique de sécurité permet de s'assurer que personne ne va faire des conneries comme virer les droits top secret par erreur.
( ensuite, il faut je précise d'autres mesures pour éviter d'autres attaques )
Enfin bon, je pourrais parler de SELinux pendant des heures, un peu moins de AppArmor ( je connais moins ) mais j’espère que mon explication t'a aidé.