Oui, SELinux rend Red Hat (et toute autre distribution Linux qui l'utilise réellement) plus sûr, en supposant qu'il soit réellement utilisé.
SELinux implémente un contrôle d'accès obligatoire . Les autorisations Unix normales, les ACL, etc., implémentent un contrôle d'accès discrétionnaire . Les deux se complètent.
Pour fonctionner, SELinux requiert une politique, définissant quelles actions sur le système peuvent être autorisées. Bien qu'il soit possible de créer une politique système entière à partir de zéro, la plupart des distributions Linux livrent une politique basée sur la politique dite de référence . Cela signifie, entre autres, que la configuration de SELinux entre les distributions sera très similaire. (La plupart des distributions Linux rendent la politique de référence SELinux disponible dans leurs référentiels de packages, bien qu'elle ne soit pas installée par défaut.)
SELinux fonctionne en restreignant les utilisateurs et les processus à effectuer uniquement les actions qui leur sont autorisées dans la stratégie. Par défaut, la stratégie consiste à refuser, donc si la stratégie n'autorise pas explicitement une action, cela ne se produit pas. C'est pourquoi vous rencontrez si souvent des problèmes avec SELinux interdisant quelque chose que vous essayez de faire.
Du côté positif, cela empêche également les exploits, même les exploits de 0 jour, de devenir incontrôlables. Par exemple, si votre serveur Web (Apache) est exploité, les dommages sont limités aux seules choses auxquelles Apache peut accéder. Il ne serait pas en mesure de lire votre /etc/shadowfichier, par exemple, même avec un exploit root distant. Alors que les autorisations Unix (DAC) permettent à root de lire le fichier, SELinux (MAC) ne permet pas au processus compromis de sortir des limites.
Le gros problème est qu'il doit y avoir un module de politique SELinux chargé pour le service. Si vous installez un service sur votre box qui n'inclut pas de module de politique SELinux, il s'exécutera sans restriction et pourra faire ce qu'il veut. SELinux ne s'y appliquera pas.
Une autre chose que vous devez savoir concerne les booléens . Ces paramètres ajustables sont fournis par les politiques SELinux pour les personnaliser pour des installations particulières et autoriser ou refuser l'accès en fonction des besoins de configuration locaux. Par exemple, vous pouvez donner à Apache un accès aux partages Samba, permettre à Samba de partager les répertoires personnels des utilisateurs et bien d'autres choses potentiellement utiles qui sont nécessaires pour certaines configurations mais pas pour d'autres.
Le meilleur guide de SELinux que j'ai vu actuellement est le Guide de l'utilisateur de Linux avec sécurité renforcée de Red Hat . Il vous aidera à être rapidement opérationnel et à remplir les détails de fond de ce qui se passe. Il comprend également un guide de dépannage complet qui vous aide à exécuter votre processus sous SELinux.
Est-ce utile?
SELinux protège contre les processus (et les utilisateurs, si vous avez confiné vos utilisateurs) de faire des choses inattendues. Il limite considérablement les dommages qu'un exploit distant peut faire. Si vous n'avez jamais subi de compromis à distance, vous êtes (1) chanceux et (2) probablement nouveau. Si vous avez travaillé un compromis à distance, vous ne voulez certainement pas que cela se reproduise.
Ce n'est pas aussi utile dans un environnement domestique , sauf si vous utilisez des services Internet à domicile (et certaines personnes le font). Dans ce cas, tout ce qui précède s'applique.
SELinux peut être la dernière chose qui se situe entre vos données et un attaquant avec un exploit de 0 jour qui le veut vraiment. Si vous pouvez l' utiliser, pourquoi ne le feriez-vous pas?