Raisons de désactiver / activer SELinux


36

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 ;-)

Réponses:


25

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.


8
Un fournisseur de logiciels "entreprise" embauché pour installer leur produit a résolu un problème d’autorisation en exécutant chmod -R 777 * dans une grande arborescence de répertoires. Ils ne se soucient vraiment pas de votre sécurité.
kmarsh

21

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.


16

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:


2
+1, informations très utiles.
DCookie

10

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.


2
+1 pour signaler que vous avez souvent intérêt à laisser SELinux en marche et à ne l'éteindre que pour vérifier s'il est à l'origine d'un problème.
Ophidian

2

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


Intéressant. Vous êtes sur quelle distribution? Je n'ai jamais utilisé AppArmor, mais je suis curieux de savoir quelle distribution a été configurée et quelles sont ses caractéristiques. Va examiner dans cela. Personnellement, je n'ai pas de problème avec SELinux, mais cela prend un certain temps pour s'y habituer.
lundi

AppArmor a été développé à l'origine par Novell et est inclus par défaut dans toutes leurs distributions openSUSE et SUSE Linux Enterprise. Il est activé par défaut sur les distributions Enterprise et est facile à activer dans les distributions grand public. Ubuntu le possède depuis le 7.04, mais il n’applique pas automatiquement chaque application par défaut.
andrewd18

Je pense me souvenir d’avoir parlé de Novell qui licenciait la majeure partie de l’équipe d’AppArmor. Ubuntu ne l’a-t-il pas abandonné? Ou est-ce que j'entends encore les voix dans ma tête? ;-)
wzzrd

Novell l'a fait - mais l'auteur y travaille toujours sans être payé. Il est toujours supporté sur Ubuntu, et des choses comme cups et mysqld sont appliquées par défaut.
LiraNuna

Pas toujours mais souvent nous échangeons la facilité d'utilisation pour la sécurité et vice versa. Il s’agit d’un exercice d’équilibrage et la réponse n’est pas anodine, principalement en raison de la définition des risques, et les objectifs de sécurité sont une tâche très difficile.
rev

1

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.


En réalité, il existe des cas où SELinux peut interférer avec des applications en mode Permissive. Un: à certains moments, certaines règles sont appliquées, bien que le système soit défini pour être permissif. Pas sûr que ce soit toujours le cas. Deux: le temps nécessaire pour traiter les règles peut être suffisant pour bousiller IPC. J'ai vu cela avec les clusters Oracle. Encore une fois dans le passé et pas sûr de ce que le statut actuel est. Mais rappelez-vous que presque chaque appel système a un peu de temps de traitement ajouté.
Jason Tan

0

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.


Je ne pense pas que Oracle soutienne officiellement SELinux
wzzrd le
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.