Qu'est-ce qui peut mal tourner si nous désactivons selinux [fermé]

Nous avons hérité d'un tas de serveurs utilisés d'une autre équipe. Certains d'entre eux ont activé SELinux, d'autres non. À cause de SELinux, nous avons du mal à configurer ssh sans mot de passe, notre serveur Web, etc. Nous avons trouvé un moyen de contourner ce site stackexchange , qui doit exécuter:

restorecon -R -v ~/.ssh

Cependant, comme nous n'avons pas besoin que SELinux s'exécute pour ce que nous faisons, il pourrait être plus facile de le désactiver que de nous rappeler d'avoir tout le monde exécutant la cmd ci-dessus sur tout répertoire nécessitant des autorisations.

Pouvons-nous désactiver SELinux sans aucune répercussion sur la route ou est-il préférable de simplement recréer l'image du serveur? Une chose à noter; notre groupe informatique est vraiment occupé, donc la réimagerie d'un serveur n'est pas en tête de liste à moins que cela ne soit absolument nécessaire (besoin d'une très bonne analyse de rentabilisation) ... ou que quelqu'un soudoie son patron avec une bouteille de scotch ou de whisky.

MISE À JOUR: Merci pour la suggestion et les conseils de chacun. Ces serveurs vont tous être utilisés comme serveurs de développement internes. Il n'y aura aucun accès extérieur à ces machines, la sécurité n'est donc pas une préoccupation majeure pour nous. Nos serveurs actuels que nous utilisons tous (au meilleur de ma connaissance) n'ont pas activé SELinux. Certains de ceux que mon manager vient d'acquérir le font et ce sont ceux que nous envisageons de désactiver afin que tout dans notre cluster soit uniforme.

SELinux est une fonction de sécurité du système d'exploitation. Il est conçu pour aider à protéger certaines parties du serveur contre d'autres parties.

Par exemple, si vous exécutez un serveur Web et que vous avez du code "vulnérable" qui permet à un attaquant d'exécuter des commandes arbitraires, SELinux peut aider à atténuer cela, en empêchant votre serveur Web d'accéder aux fichiers qu'il n'est pas autorisé à voir.

Vous pouvez maintenant désactiver SELinux et il ne devrait rien casser. Le serveur continuera de fonctionner normalement.

Mais vous aurez désactivé l'une des fonctions de sécurité.

Il existe différentes vues de SELinux. Dans de nombreux cas, certaines applications ne fonctionnent pas bien avec SELinux, de sorte que cette décision est théorique (Oracle en est un exemple).
Généralement, SELinux est un mécanisme de protection pour mettre encore un autre obstacle sur le chemin d'un méchant qui veut renverser votre système.

Dans mes précédents postes d'administrateur système dans de grandes entreprises ... J'ai généralement désactivé SELinux. Je n'ai pas eu le temps de retrouver toutes les erreurs SELinux sur tous les systèmes utilisés par les utilisateurs, les développeurs et les gestionnaires.

Avant de désactiver les choses, vous voudrez peut-être commencer par renommer les fichiers du système à ce qu'ils devraient être. La méthode la plus simple que j'ai trouvée consiste à entrer la commande:

 # /sbin/fixfiles onboot

OU

 # touch /.autorelabel

Ensuite, redémarrez et attendez car il faudra environ le même temps au système pour vérifier et réinitialiser les étiquettes SELinux errantes dans le système. Après cela, vous pouvez être d'accord car il corrige et corrige les étiquettes SELinux non conformes qui peuvent avoir été modifiées avant votre tentative d'administration du serveur.

Cependant, si ce n'est pas le cas, le système ne sera pas affecté par le fait de ne pas avoir SELinux en mode d'application. C'est juste une couche supplémentaire de protection.

Autrement dit, la désactivation des mécanismes de contrôle d'accès obligatoire (MAC) comme SELinux n'est pas une bonne idée et peut vous mettre à la sécurité si un méchant contourne avec succès les contrôles d'accès basés sur le nom, mis en œuvre par Discretionary Access Control (DAC).

Si c'était moi, je ferais quelque chose comme

semanage fcontext -a -t ssh_home_t ~/.ssh # Adding the policy
restorecon -R -v ~/.ssh # Applying the policy

pour être sûr supplémentaires sur le label de type attribué récursive de~/.ssh

D'une manière générale, vous ne devez pas désactiver SELinux. Il existe des outils qui pourraient vous aider à comprendre ce qui a mal tourné. Mon exemple préféré est l'utilisation de Sealert:

sealert -a /var/log/audit/audit.log

OFC vous pouvez toujours définir SELinux en mode permissif pour le débogage, mais garder SELinux désactivé ou permissif est enseigné comme une faille de sécurité grave par Red Hat.