Raisons de désactiver / activer SELinux

Dans la lignée de cette question sur StackOverflow et la foule complètement différente que nous avons ici, je me demande: quelles sont vos raisons de désactiver SELinux (en supposant que la plupart des gens le fassent encore)? Voulez-vous le garder activé? Quelles anomalies avez-vous rencontrées en laissant SELinux activé? À part Oracle, quels autres fournisseurs posent des problèmes pour la prise en charge de systèmes avec SELinux activé?

Question bonus: Quelqu'un a-t-il réussi à faire fonctionner Oracle sur RHEL5 avec SELinux en appliquant le mode ciblé? Je veux dire, strict serait génial, mais je ne pense pas que cela soit encore possible, alors restons avec ciblé en premier ;-)

RedHat active SELinux par défaut, car il est plus sûr. Presque tous les fournisseurs qui utilisent des produits dérivés de Redhat désactivent SELinux parce qu'ils ne veulent pas avoir à gagner du temps (et donc de l'argent) pour comprendre pourquoi cela ne fonctionne pas. Les employés de Redhat / Fedora ont consacré beaucoup de temps et d’efforts à faire de SELinux une option plus viable dans l’entreprise, mais peu d’autres organisations se préoccupent vraiment de votre sécurité. (Ils se soucient de leur sécurité et de la réputation de leur produit en matière de sécurité, ce qui est totalement différent.)

Si vous pouvez le faire fonctionner, alors allez-y. Si vous ne pouvez pas le faire, alors ne vous attendez pas à beaucoup d'assistance de la part des fournisseurs. Vous pouvez probablement obtenir de l'aide des gars de Redhat / Fedora, des listes de diffusion selinux et du canal #selinux sur freenode. Mais des entreprises comme Oracle - eh bien, SELinux ne prend pas vraiment en compte leur business plan.

En général, il vaut mieux exécuter SELinux dans Permissive plutôt que de le désactiver complètement. Vous pouvez ensuite vérifier (via audit2why) après un certain temps pour voir quels types de violations auraient été refusées lors de votre utilisation habituelle et créer des stratégies personnalisées via audit2allowsi ces "violations" sont des faux positifs pour votre configuration.

J'ai constaté que le comportement SELinux sur des systèmes non dérivés de Fedora était beaucoup plus sensible que ce que vous obtenez avec un système typique Fedora / RHEL par défaut.

Si vous ne l'avez pas encore vu, vous pouvez trouver le Guide de l'utilisateur de Fedora SELinux éducatif.

Raisons pour:

• Niveau de sécurité supérieur grâce au contrôle d'accès obligatoire
• Vous avez besoin d'une raison au-delà du niveau de sécurité supérieur? :-)

Raisons contre:

• Difficile à comprendre
• Difficile à gérer
• Difficile à dépanner

Ceci dit, si vous envisagez d'utiliser SELinux, je vous recommande le livre SELinux par exemple .

J'ai travaillé pour une entreprise qui avait activé SELinux, en mode de mise en application, sur tous les systèmes. La clé pour nous était de comprendre et d’utiliser le programme audit2allow, qui peut être utilisé pour créer de nouvelles règles de contexte.

Tout d'abord, nous générerions un modèle avec audit2allow, puis utiliserions un script pour le construire, comme ceci:

export NAME="my_serviced"
sudo audit2allow -m "${NAME}" -i /var/log/audit/audit.log > ${NAME}.te
sudo setup_semodule ${NAME}

Le script setup_semodule:

#!/bin/sh

# Where to store selinux related files
SOURCE=/etc/selinux/local
BUILD=/etc/selinux/local
NAME=$1

/usr/bin/checkmodule -M -m -o ${BUILD}/${NAME}.mod ${SOURCE}/${NAME}.te
/usr/bin/semodule_package -o ${BUILD}/${NAME}.pp -m ${BUILD}/${NAME}.mod
/usr/sbin/semodule -i ${BUILD}/${NAME}.pp

/bin/rm ${BUILD}/${NAME}.mod ${BUILD}/${NAME}.pp

Cela crée le module à partir du modèle (fichier .te), génère un package, puis charge le module.

Nous avons utilisé Puppet pour notre système de gestion de la configuration et nous avons écrit la configuration pour que Puppet gère tout cela.

Module Marionnettes SELinux:

• http://github.com/sansnoc/puppet/tree/master/selinux

La raison pour la désactiver est qu’il peut être difficile de déboguer.

Cependant, nous ne l'éteignons pas maintenant. Nous continuons presque toujours à le faire fonctionner. Je l'éteins parfois pour vérifier rapidement si SElinux pose un problème ou non.

Il est beaucoup plus facile de déboguer maintenant, surtout si vous vous familiarisez avec audit2allow. Vous n'avez pas vraiment besoin de le comprendre avec audit2allow, mais vous pouvez parfois vous retrouver plus ouvert que prévu avec audit2allow. Cela dit, certains SELinux valent mieux que rien.

Je ne suis en aucun cas un expert de SELinux et je ne l'utilise que depuis quelques années. Je ne comprends toujours pas vraiment les bases, mais j'en connais suffisamment pour faire fonctionner les applications, notamment celles incluses dans la distribution et les éléments aléatoires compilés sur le réseau.

La principale chose que j'ai dû utiliser sont le ls -lZ(montrer contexte SELinux), audit2allow, chcon, semodule, getenforce, setenforceet booléens. Avec ces outils, j'ai réussi à obtenir toutes les applications dont j'avais besoin pour exécuter SELinux.

Je trouve l’un des gros problèmes de débogage des problèmes SELinux, c’est simplement un rappel pour vérifier les problèmes SELinux lorsque j’ai d’autres problèmes inexplicables. Cela me prend habituellement un peu pour aller "h! Check SELinux !!".

Selon la page de manuel de bind, SELinux est beaucoup plus sûr que de lancer bind dans une prison chroot. Beaucoup d'autres personnes qui ont beaucoup plus d'indices que je le recommande également, je le cours maintenant à l'aveuglette. Et suspect malgré le problème occasionnel cela vaut probablement la peine d'être fait.

J'ai désactivé SELinux pour AppArmor , je l'ai trouvé beaucoup plus convivial et facile à maintenir que SELinux.

Il n'y a aucune raison de l'éteindre si vous pouvez l'exécuter en mode permissif. Il n'interférera pas avec l'application en cours d'exécution et fournira tout de même une journalisation de sécurité utile. La seule exception concerne les contextes utilisateur: si vous passez de différents utilisateurs résidant à l’intérieur d’une autre instance Linux exécutant un chroot, des problèmes peuvent survenir.

SE Linux n’est plus aussi désespérément hostile qu’avant, du moins ce n’est pas le cas dans les distributions commerciales telles que RHEL5. Pour la plupart, vous pouvez le laisser et tout ira bien avec tout ce qui est fourni par RedHat. Avec toute autre chose, cela peut être variable. Le problème est que les services professionnels permettant aux applications de fonctionner avec SE Linux activé constituent une source de revenus intéressante pour des entreprises telles que RedHat et Oracle. Elles ne sont donc pas incitées à tout faire fonctionner correctement.