Vérification du mode SELinux
Vous pouvez obtenir la configuration actuelle du mode SELinux en exécutant getenforce ou sestatus en tant qu'utilisateur root. Le premier imprime simplement «Enforcing» ou «Permissive» sur stdout. Ce dernier fournit des détails supplémentaires, notamment le point de montage SELinuxfs, le mode actuel, le mode tel qu'il apparaît dans le fichier de configuration SELinux, etc.
Le mode SLELinux peut être modifié par l'utilisateur root pendant l'exécution à l'aide de l'application setenforce.
Usage:
setenforce [Application | Permissive | 1 | 0]
Il est important de se rappeler que les modifications apportées à l'aide de sentenforce ne sont pas persistantes au redémarrage du système.
Si SELinux est défini sur permissif plutôt que désactivé, toutes les applications compatibles SELinux se comporteront comme si le mode d'application était toujours défini. SELinux continuera également à auditer l'activité des applications en mode permissif. C'est la principale différence entre l'utilisation du mode permissif et la désactivation complète de SELinux.
La valeur par défaut du mode au démarrage du système est définie dans le fichier / etc / selinux / config par le paramètre SELINUX. Le paramètre SELINUX accepte l'application, la permission ou la désactivation.
Par exemple :
root> # cat / etc / selinux / config # Ce fichier contrôle l'état de SELinux sur le système. # SELINUX = peut prendre l'une de ces trois valeurs: # enforcing - La politique de sécurité SELinux est appliquée. # permissive - SELinux affiche des avertissements au lieu de les appliquer. # disabled - Aucune stratégie SELinux n'est chargée. SELINUX = enforcing # SELINUXTYPE = peut prendre l'une des trois valeurs suivantes: # target - Les processus ciblés sont protégés, # minimum - Modification de la politique ciblée. Seuls les processus sélectionnés sont protégés. # mls - Protection de sécurité à plusieurs niveaux. SELINUXTYPE = racine ciblée> #
Si jamais vous devez résoudre un problème où le mode SELinux passe constamment à un mode inattendu au moment du démarrage, il convient de noter que SELinux peut également être configuré dans grub.conf en définissant le paramètre d'application sur 0 ou 1 (permissif ou exécutoire, respectivement).
Configurer SELinux pour qu'il fonctionne correctement avec Amanda
Parce que la fonction principale de SELinux est d'appliquer le contrôle d'accès obligatoire, il peut nécessiter des étapes supplémentaires pour exécuter Amanda si SELinux n'est pas désactivé ou en mode permissif
Les versions modernes de Zmanda (Amanda Enterprise Edition) tenteront de régler automatiquement SELinux en mode permissif au moment de l'installation.
root> # ./amanda-enterprise-3.4-linux-x64.run L'installation de Zmanda nécessite le passage de SELinux à l'état Permissive. Le programme d'installation lui-même le fera et le restaurera à son état d'origine une fois l'installation terminée. Voulez-vous continuer? [O / n]:
Le programme d'installation de Zmanda utilise l'application semanage pour ce faire, veuillez donc vous assurer que semanage est installé en vérifiant par exemple quel semanage avant d'exécuter le programme d'installation. Si semanage n'est pas déjà installé, vous pouvez obtenir l'application avec:
root> # yum fournit * / semanage {sortie supplémentaire non affichée} root> # yum install
Lors du dépannage des installations Amanda / Zmanda dans des environnements qui implémentent SELinux si possible, essayez de régler temporairement SELinux en mode permissif. Réessayez vos tests pour confirmer que SELinux est bien la cause du problème et pour générer des entrées de journal d'audit.
S'il n'est pas possible d'exécuter SELinux en mode permissif en raison de votre politique de sécurité, certains indicateurs indiquent que SELinux interfère avec le fonctionnement normal d'Amanda. Vous pouvez consulter les journaux d'audit pour les entrées liées à amanda et / ou zmanda:
racine> # ausearch -m avc -c amanda
Si vous ne parvenez pas à trouver des entrées de journal concernant SELinux refusant Amanda, mais qu'il n'y a aucun problème lors de l'exécution en mode permissif, cela peut être le résultat de règles dontaudit. Pour désactiver temporairement les règles dontaudit, vous pouvez exécuter:
racine> # semodule -DB
Une fois que cela a été exécuté, essayez d'exécuter à nouveau votre installation, sauvegarde ou restauration et vérifiez le journal d'audit. Une fois que SELinux a enregistré les refus applicables, assurez-vous de réactiver ne pas auditer règles:
racine> # semodule -B
Certains systèmes d'exploitation sont livrés avec des modules de stratégie préinstallés pour Amanda qui peuvent ne pas refléter les contextes corrects pour votre version d'Amanda. Vous pouvez vérifier quel module est actuellement inclus en utilisant:
racine> # semodule -l | grep amanda
La liste de tous les modules installés peut prendre quelques instants, et bien sûr, s'il n'y a pas de module correspondant à «amanda», il n'y aura pas de sortie. Si vous constatez que vous exécutez un module de stratégie Amanda ancien ou corrompu, vous pouvez le supprimer en utilisant:
racine> # semodule -r
Tous les contextes SELinux peuvent être configurés manuellement, mais cela sort du cadre de cette documentation. Si vous êtes intéressé par une solution entièrement manuelle, vous devriez vous référer aux pages de manuel chcon et restorecon pour des informations détaillées.
Création de packages de stratégies personnalisés avec audit2allow
Dans la plupart des environnements, un certain nombre de machines clientes Amanda exécutent des systèmes d'exploitation similaires et des serveurs Amanda supplémentaires doivent parfois être déployés. Il n'est pas efficace de dépanner et de modifier manuellement les contextes de sécurité sur chaque machine individuelle dans ces scénarios. C'est là qu'un outil appelé audit2allow peut être utile pour créer des packages de politiques personnalisés qui peuvent être déployés sur plusieurs machines sur le réseau.
Tout d'abord, exécutez vos tâches en mode permissif et créez un fichier d'application de type:
racine> # grep -E 'amanda | zmanda' /var/log/audit/audit.log | audit2allow -m myamanda> myamanda.te
Une fois le fichier d'application de type créé, assurez-vous qu'il est vérifié par un opérateur. Veuillez modifier la sortie générée automatiquement comme requis par votre service de sécurité de l'information.
Lors de la vérification du fichier d'application de type, rappelez-vous: de nombreuses applications fourniront un contexte de sécurité SELinux au moyen d'un commutateur -Z. Par exemple, 'ls, -Z', 'ps axZ', etc.
Une fois qu'il est vérifié que le fichier d'application de type répond aux exigences de votre stratégie de sécurité, il doit être converti en un package de stratégie à inclure en tant que module de stratégie actif. Pour ce faire, vous pouvez exécuter les commandes suivantes:
root> # checkmodule -mo myamanda.mod myamanda.te root> # semodule_package -m myamanda.mod -o myamanda.pp
Pour charger le module de stratégie, vous devez ensuite exécuter:
racine> # semodule -i myamanda.pp
Si vous obtenez une erreur que vous avez "Tentative de liaison dans un module non MLS avec une base MLS" vous devrez à la place convertir le fichier d'application de type en tant que sécurité multicouche et inclure le package de stratégie résultant comme suit:
racine> # checkmodule -M -m -o myamanda.mod myamanda.te racine> # semodule_package -m myamanda.mod -o myamanda.pp
Et incluez ensuite le package de règles en utilisant semodule -i comme décrit ci-dessus. Vous devriez maintenant être configuré pour exécuter vos sauvegardes et restaurations avec SELinux en mode d'application.
