SELinux est une sécurité « en plus », si vous envisagez qu'une backdoor ait pu y être introduite, il suffit de ne pas l'utiliser
En fait, selinux est un système de label et de permission. Chaque objet a son label ( stocké via xattr sur les fs, rien de spécial ), et un moteur de regle, avec un minimum d'optimisation pour pas faire ramer ( voir les détails sur https://www.imperialviolet.org/2009/07/14/selinux.html ). Donc ne pas l'utiliser pour éviter une backdoor, c'est revenir au système par défaut qui donne beaucoup plus de permissions et , et c'est comme dire que sans firewall, on est plus en sureté.
Retirer un firewall parce que ça fait chier, parce qu'on a pas le temps de le maintenir et que ça a un cout, pourquoi pas, ça se défend. Dire qu'on a pas besoin car il peut y avoir des failles dans le traitement des chaines( genre l7, le super truc qui fait de l'analyse protocolaire ), à la rigueur, mais c'est pas lié au concept de firewall lui même mais au code.
Par contre, j'ai vu personne dire "je retire le firewall car c'est plus sur, j'ai pas de risque de backdoor". Dire pareil de selinux, ça tiens plus du cargo cult qu'autre chose.
Sinon, oui le code de selinux a été audité par les gens de RH avant de l'intégrer ( comme tout ce qui est rajouté dans le kernel de RHEL ), et aussi par le même group de gens qui ont audités tout le reste du kernel sur la lklm ( surtout vu le selinux a mis du temps à rentrer ), et aussi par les gens de tresys.
Ensuite, quand on parle du code de selinux, c'est superbement imprécis. Est ce qu'on parle des LSMs, d'un LSM en particulier, du code en userspace, de la policy ?
Et prendre apparmor, je dirais qu'il y a pas la même couverture fonctionnelle, ni les mêmes fonctions. Le but, c'est pas de charger un LSM pour charger un LSM, mais de voir les menaces, les risques, les besoins tu as et quels solutions tu va déployer. Et pour un utilisateur, garder la solution choisi par le distributeur me semble logique, vu que la plupart dépende d'une politique de régles, soit c'est complet sur un LSMs, soit c'est grossièrement incomplet sur tout les LSMs. Donc le choix se fait plus au niveau de la distribution choisi qu'autre chose.
[^] # Re: Deux idées
Posté par Misc (site web personnel) . En réponse au journal [non-troll] Faire confiance à (N)S(A)ELinux ou aux *BSD ?. Évalué à 3.
En fait, selinux est un système de label et de permission. Chaque objet a son label ( stocké via xattr sur les fs, rien de spécial ), et un moteur de regle, avec un minimum d'optimisation pour pas faire ramer ( voir les détails sur https://www.imperialviolet.org/2009/07/14/selinux.html ). Donc ne pas l'utiliser pour éviter une backdoor, c'est revenir au système par défaut qui donne beaucoup plus de permissions et , et c'est comme dire que sans firewall, on est plus en sureté.
Retirer un firewall parce que ça fait chier, parce qu'on a pas le temps de le maintenir et que ça a un cout, pourquoi pas, ça se défend. Dire qu'on a pas besoin car il peut y avoir des failles dans le traitement des chaines( genre l7, le super truc qui fait de l'analyse protocolaire ), à la rigueur, mais c'est pas lié au concept de firewall lui même mais au code.
Par contre, j'ai vu personne dire "je retire le firewall car c'est plus sur, j'ai pas de risque de backdoor". Dire pareil de selinux, ça tiens plus du cargo cult qu'autre chose.
Sinon, oui le code de selinux a été audité par les gens de RH avant de l'intégrer ( comme tout ce qui est rajouté dans le kernel de RHEL ), et aussi par le même group de gens qui ont audités tout le reste du kernel sur la lklm ( surtout vu le selinux a mis du temps à rentrer ), et aussi par les gens de tresys.
Ensuite, quand on parle du code de selinux, c'est superbement imprécis. Est ce qu'on parle des LSMs, d'un LSM en particulier, du code en userspace, de la policy ?
Et prendre apparmor, je dirais qu'il y a pas la même couverture fonctionnelle, ni les mêmes fonctions. Le but, c'est pas de charger un LSM pour charger un LSM, mais de voir les menaces, les risques, les besoins tu as et quels solutions tu va déployer. Et pour un utilisateur, garder la solution choisi par le distributeur me semble logique, vu que la plupart dépende d'une politique de régles, soit c'est complet sur un LSMs, soit c'est grossièrement incomplet sur tout les LSMs. Donc le choix se fait plus au niveau de la distribution choisi qu'autre chose.