Raisons de désactiver / activer SELinux

En général, il est préférable d'exécuter SELinux en mode Permissif plutôt que de le désactiver complètement. Vous pouvez alors vérifier (via audit2why ) après un certain temps pour voir quels types de violations auraient été refusés lors de votre utilisation habituelle, et construire des politiques personnalisées via audit2allow si ces "violations" sont des faux-positifs pour votre installation.

J'ai constaté que le comportement de SELinux sur les systèmes non dérivés de Fedora est nettement plus délicat que celui d'un système Fedora/RHEL typique par défaut.

Si vous ne l'avez pas déjà vu, vous pouvez trouver le Guide d'utilisation de Fedora SELinux éducatif.

Raisons pour lesquelles :

• Un niveau de sécurité plus élevé grâce au contrôle d'accès obligatoire
• Vous avez besoin d'une raison autre qu'un niveau de sécurité plus élevé ? :-)

Raisons contre :

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

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

J'ai travaillé pour un entreprise qui avait SELinux activé, en mode enforcing, sur chaque système. La clé pour nous a été de comprendre et d'utiliser le programme audit2allow qui peut être utilisé pour créer de nouvelles règles de contexte.

D'abord, on génère un modèle avec audit2allow, puis on utilise 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 module setup_semodule script :

#!/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

Cette opération construit le module à partir du modèle (fichier .te), génère un paquet, puis charge le module.

Nous avons utilisé Puppet pour notre système de gestion de la configuration, et nous avons écrit une configuration pour Puppet afin de gérer tout cela.

Module Puppet SELinux :

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

La raison pour laquelle il faut le désactiver est qu'il peut être difficile à déboguer.

Cependant, nous ne l'éteignons pas maintenant. Nous le laissons presque toujours en marche. Je l'éteins occasionnellement pour vérifier rapidement si SElinux est 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 finir par ouvrir les choses plus largement que vous ne le pensez avec audit2allow. Cela dit, un peu de SELinux vaut 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 sais assez pour faire fonctionner des applications, qu'elles soient incluses dans la distribution ou qu'elles soient compilées au hasard sur le net.

La principale chose que j'ai eu à utiliser sont les ls -lZ (montrer le contexte selinux), audit2allow , chcon , semodule , getenforce , setenforce et les booléens. Avec ces outils, j'ai réussi à faire fonctionner toutes les applications dont j'avais besoin sous SELinux.

Je trouve que l'un des grands problèmes du débogage des problèmes SELinux, est simplement de se rappeler de vérifier les problèmes SELinux lorsque j'ai d'autres problèmes inexplicables. Il me faut généralement un peu de temps pour me dire "h ! vérifiez SELinux !!".

Selon la page de manuel de bind, SELinux est beaucoup plus sûr que d'exécuter bind dans une prison chroot. Beaucoup d'autres personnes qui ont beaucoup plus de connaissances que moi le recommandent également, alors je l'exécute aveuglément maintenant. Et je pense que malgré les problèmes occasionnels, cela vaut probablement la peine de le faire.

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