introduction
Sécurité Enhanced Linux ou SELinux est un mécanisme de contrôle d’accès avancé intégré à la plupart des distributions Linux modernes. Il a été initialement développé par la US National Security Agency pour protéger les systèmes informatiques contre les intrusions et les manipulations malveillantes. Au fil du temps, SELinux a été publié dans le domaine public et diverses distributions l’ont intégré à son code.
De nombreux administrateurs système considèrent SELinux comme un territoire relativement inexploré. Le sujet peut sembler intimidant et parfois assez déroutant. Cependant, un système SELinux correctement configuré peut réduire considérablement les risques de sécurité, et en savoir plus à ce sujet peut vous aider à résoudre les problèmes liés aux messages d’accès. Dans ce didacticiel, nous étudierons les concepts sous-jacents de SELinux - ses packages, ses commandes et ses fichiers de configuration - ainsi que les messages d’erreur qu’il consigne lorsque l’accès est refusé. Nous verrons également quelques exemples pratiques de mise en œuvre de SELinux.
_ * Remarque * + Les commandes, les packages et les fichiers présentés dans ce didacticiel ont été testés sur CentOS 7. Les concepts restent les mêmes pour les autres distributions. _
Dans ce tutoriel, nous exécuterons les commandes en tant qu’utilisateur root, sauf indication contraire. Si vous n’avez pas accès au compte root et utilisez un autre compte avec les privilèges sudo, vous devez faire précéder les commandes du mot-clé + sudo +.
Pourquoi SELinux
Avant de commencer, laissez-nous comprendre quelques concepts.
SELinux implémente ce que l’on appelle * MAC * (contrôle d’accès obligatoire). Ceci est implémenté en plus de ce qui est déjà présent dans chaque distribution Linux, le * DAC * (Contrôle d’accès discrétionnaire).
Pour comprendre le DAC, examinons d’abord le fonctionnement de la sécurité des fichiers Linux traditionnelle.
Dans un modèle de sécurité traditionnel, nous avons trois entités: Utilisateur, Groupe et Autre (u, g, o) pouvant avoir une combinaison d’autorisations de lecture, d’écriture et d’exécution (r, w, x) sur un fichier ou un répertoire. Si un utilisateur * jo * crée un fichier dans son répertoire de base, cet utilisateur y aura un accès en lecture / écriture, ainsi que le groupe * jo *. L '«autre» entité n’y aura peut-être pas accès. Dans le bloc de code suivant, nous pouvons considérer le contenu hypothétique du répertoire personnel de jo.
Vous n’avez pas besoin de configurer cet utilisateur * jo * - nous allons configurer beaucoup d’utilisateurs ultérieurement dans le didacticiel.
Lancer une commande comme ceci:
ls -l /home/jo/peut afficher la sortie comme suit:
total 4
-rwxrw-r--. 1 jo jo 41 Aug 6 22:45 myscript.shMaintenant, jo peut modifier cet accès. jo peut accorder (et restreindre) l’accès à ce fichier à d’autres utilisateurs et groupes, ou changer le propriétaire du fichier. Ces actions peuvent laisser des fichiers critiques exposés à des comptes qui n’ont pas besoin de cet accès. jo peut également limiter la sécurité, mais cela reste discrétionnaire: il n’ya aucun moyen pour l’administrateur système de l’appliquer pour chaque fichier du système.
Prenons un autre cas: lorsqu’un processus Linux est exécuté, il peut s’exécuter en tant qu’utilisateur root ou sous un autre compte doté des privilèges de superutilisateur. Cela signifie que si un pirate black-hat prend le contrôle de l’application, il peut l’utiliser pour accéder à la ressource à laquelle le compte de l’utilisateur a accès. Pour les processus exécutés en tant qu’utilisateur root, cela signifie essentiellement tout sur le serveur Linux.
Pensez à un scénario dans lequel vous souhaitez empêcher les utilisateurs d’exécuter des scripts shell à partir de leurs répertoires de base. Cela peut arriver lorsque des développeurs travaillent sur un système de production. Vous voudriez qu’ils consultent les fichiers journaux, mais vous ne voulez pas qu’ils utilisent les commandes + su + ou + sudo +, et vous ne voulez pas qu’ils exécutent des scripts à partir de leurs répertoires de base. Comment tu fais ça?
SELinux est un moyen d’affiner les exigences de contrôle d’accès. Avec SELinux, vous pouvez définir ce qu’un utilisateur ou un processus peut faire. Il limite chaque processus à son propre domaine afin qu’il puisse uniquement interagir avec certains types de fichiers et d’autres processus des domaines autorisés. Cela empêche un pirate de pirater n’importe quel processus pour obtenir un accès à l’échelle du système.
Mise en place d’un système de test
Pour nous aider à comprendre les concepts, nous allons créer un serveur de test exécutant à la fois un serveur Web et un serveur SFTP. Nous allons commencer par une installation nue de CentOS 7 avec des paquets minimaux et installer les démons Apache et vsftp sur ce serveur. Cependant, nous ne configurerons aucune de ces applications.
Nous allons également créer quelques comptes d’utilisateurs tests sur notre serveur cloud. Nous utiliserons ces comptes à différents endroits au cours de la leçon.
Enfin, nous installerons les packages nécessaires à SELinux. Cela nous permet de travailler avec les dernières commandes de SELinux.
Installation des services Apache et SFTP
Commençons par vous connecter au serveur en tant qu’utilisateur * root * et exécutez la commande suivante pour installer Apache:
yum install httpdLa sortie montrera le paquet en cours de téléchargement et vous demandera la permission d’installer:
Loaded plugins: fastestmirror, langpacks
...
...
================================================================================
Package Arch Version Repository Size
================================================================================
Installing:
httpd x86_64 2.4.6-18.el7.centos updates 2.7 M
Transaction Summary
================================================================================
Install 1 Package
Total download size: 2.7 M
Installed size: 9.3 M
Is this ok [y/d/N]:Appuyez sur * y * pour installer le démon de serveur Web Apache.
Downloading packages:
httpd-2.4.6-18.el7.centos.x86_64.rpm | 2.7 MB 00:01
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
Installing : httpd-2.4.6-18.el7.centos.x86_64 1/1
Verifying : httpd-2.4.6-18.el7.centos.x86_64 1/1
Installed:
httpd.x86_64 0:2.4.6-18.el7.centos
Complete!Démarrez le démon manuellement:
service httpd startL’exécution de la commande + service httpd status indiquera que le service est en cours d’exécution:
Redirecting to /bin/systemctl status httpd.service
httpd.service - The Apache HTTP Server
Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled)
Active: active (running) since Tue 2014-08-19 13:39:48 EST; 1min 40s ago
Main PID: 339 (httpd)
...
...Ensuite, nous installerons vsftpd:
yum install vsftpdLa sortie devrait ressembler à ceci:
Loaded plugins: fastestmirror, langpacks
...
...
==============================================================================================================
Package Arch Version Repository Size
==============================================================================================================
Installing:
vsftpd x86_64 3.0.2-9.el7 base 165 k
Transaction Summary
==============================================================================================================
Install 1 Package
Total download size: 165 k
Installed size: 343 k
Is this ok [y/d/N]:Appuyez sur * y * pour installer le package.
Ensuite, nous utiliserons la commande + service vsftpd start + pour démarrer le démon vsftpd. La sortie devrait montrer quelque chose comme ce qui suit:
Redirecting to /bin/systemctl status vsftpd.service
vsftpd.service - Vsftpd ftp daemon
Loaded: loaded (/usr/lib/systemd/system/vsftpd.service; disabled)
Active: active (running) since Tue 2014-08-19 13:48:57 EST; 4s ago
Process: 599 ExecStart=/usr/sbin/vsftpd /etc/vsftpd/vsftpd.conf (code=exited, status=0/SUCCESS)
Main PID: 600 (vsftpd)
...
...Installer des paquets SELinux
Un certain nombre de packages sont utilisés dans SELinux. Certains sont installés par défaut. Voici une liste des distributions basées sur Red Hat:
-
policycoreutils (fournit des utilitaires pour gérer SELinux)
-
policycoreutils-python (fournit des utilitaires de gestion de SELinux)
-
selinux-policy (fournit la politique de référence SELinux)
-
selinux-policy-target (fournit une politique ciblée sur SELinux)
-
libselinux-utils (fournit des outils pour gérer SELinux)
-
setroubleshoot-server (fournit des outils pour déchiffrer les messages du journal d’audit)
-
setools (fournit des outils pour la surveillance du journal d’audit, la stratégie de requête et la gestion du contexte de fichier)
-
setools-console (fournit des outils pour la surveillance du journal d’audit, la stratégie de requête et la gestion du contexte de fichier)
-
mcstrans (outils pour traduire différents niveaux en un format facile à comprendre)
Certains d’entre eux sont déjà installés. Pour vérifier quels packages SELinux sont installés sur votre système CentOS 7, vous pouvez exécuter quelques commandes telles que celle ci-dessous (avec des termes de recherche différents après + grep +) en tant qu’utilisateur root:
rpm -qa | grep selinuxLa sortie devrait ressembler à ceci:
libselinux-utils-2.2.2-6.el7.x86_64
libselinux-2.2.2-6.el7.x86_64
selinux-policy-targeted-3.12.1-153.el7.noarch
selinux-policy-3.12.1-153.el7.noarch
libselinux-python-2.2.2-6.el7.x86_64Vous pouvez aller de l’avant et installer tous les packages à l’aide de la commande ci-dessous (yum ne fera que mettre à jour ceux que vous avez déjà), ou simplement ceux que vous trouvez manquants dans votre système:
yum install policycoreutils policycoreutils-python selinux-policy selinux-policy-targeted libselinux-utils setroubleshoot-server setools setools-console mcstransNous devrions maintenant avoir un système qui contient tous les packages SELinux. Nous avons également des serveurs Apache et SFTP fonctionnant avec leurs configurations par défaut. Nous avons également quatre comptes d’utilisateurs normaux prêts à être testés en plus du compte * root *.
Modes SELinux
Il est temps de commencer à jouer avec SELinux. Commençons par les modes SELinux. À tout moment, SELinux peut être dans l’un des trois modes possibles:
-
L’application
-
Permissif
-
désactivé
En mode d’exécution, SELinux enforce sa politique sur le système Linux et s’assure que toute tentative d’accès non autorisé par les utilisateurs et les processus est refusée. Les refus d’accès sont également écrits dans les fichiers journaux pertinents. Nous parlerons des politiques SELinux et des journaux d’audit plus tard.
Le mode permissif est comme un état semi-activé. SELinux n’applique pas sa politique en mode permissif, aucun accès n’est refusé. Cependant, toute violation de stratégie est toujours enregistrée dans les journaux d’audit. C’est un excellent moyen de tester SELinux avant de l’appliquer.
Le mode désactivé est explicite, le système ne fonctionnera pas avec une sécurité renforcée.
Vérification des modes et du statut SELinux
Nous pouvons exécuter la commande + getenforce + pour vérifier le mode SELinux actuel.
getenforceSELinux devrait être actuellement désactivé, donc le résultat devrait ressembler à ceci:
DisabledNous pouvons également exécuter la commande + sestatus +:
sestatusLorsque SELinux est désactivé, le résultat affiché est le suivant:
SELinux status: disabledFichier de configuration SELinux
Le fichier de configuration principal de SELinux est / etc / selinux / config. Nous pouvons exécuter la commande suivante pour afficher son contenu:
cat /etc/selinux/configLa sortie ressemblera à ceci:
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - No SELinux policy is loaded.
SELINUX=disabled
# SELINUXTYPE= can take one of these two values:
# targeted - Targeted processes are protected,
# minimum - Modification of targeted policy. Only selected processes are protected.
# mls - Multi Level Security protection.
SELINUXTYPE=targetedIl y a deux directives dans ce fichier. La directive SELINUX dicte le mode SELinux et peut avoir trois valeurs possibles, comme indiqué précédemment.
La directive SELINUXTYPE détermine la stratégie à utiliser. La valeur par défaut est + ciblée +. Avec une stratégie ciblée, SELinux vous permet de personnaliser et d’ajuster les autorisations de contrôle d’accès. L’autre valeur possible est “MLS” (sécurité à plusieurs niveaux), un mode de protection avancé. De plus, avec MLS, vous devez installer un paquet supplémentaire.
Activation et désactivation de SELinux
Activer SELinux est assez simple. mais contrairement à la désactivation, devrait être fait en deux étapes. Nous supposons que SELinux est actuellement désactivé et que vous avez installé tous les packages SELinux de la section précédente.
Dans un premier temps, nous devons éditer le fichier + / etc / selinux / config + pour changer la directive SELINUX en mode permissif.
vi /etc/sysconfig/selinux...
SELINUX=permissive
...Il est nécessaire de définir d’abord le statut sur * permissive *, car chaque fichier du système doit avoir son contexte étiqueté avant que SELinux puisse être appliqué. À moins que tous les fichiers ne soient correctement étiquetés, les processus exécutés dans des domaines restreints peuvent échouer car ils ne peuvent pas accéder aux fichiers avec les contextes appropriés. Cela peut provoquer l’échec du processus de démarrage ou le démarrage avec des erreurs. Nous allons introduire contexts et domains plus tard dans le tutoriel.
Maintenant, lancez un redémarrage du système:
rebootLe processus de redémarrage verra tous les fichiers du serveur étiquetés avec un contexte SELinux. Le système fonctionnant en mode permissif, les erreurs SELinux et les refus d’accès seront signalés, mais cela n’arrêtera rien.
Connectez-vous à nouveau à votre serveur en tant que * root *. Ensuite, recherchez la chaîne «SELinux empêche» dans le contenu du fichier / var / log / messages.
cat /var/log/messages | grep "SELinux is preventing"Si aucune erreur n’est signalée, nous pouvons passer en toute sécurité à l’étape suivante. Cependant, il serait toujours judicieux de rechercher du texte contenant «SELinux» dans le fichier / var / log / messages. Dans notre système, nous avons exécuté la commande suivante:
cat /var/log/messages | grep "SELinux"Cela montrait des messages d’erreur liés au bureau GNOME en cours d’exécution. Cela se produisait lorsque SELInux était désactivé ou en mode permissif:
Aug 20 11:31:14 localhost kernel: SELinux: Initializing.
Aug 20 11:31:16 localhost kernel: SELinux: Disabled at runtime.
Aug 20 11:31:21 localhost journal: Unable to lookup SELinux process context: Invalid argument
Aug 20 11:33:20 localhost gnome-session: SELinux Troubleshooter: Applet requires SELinux be enabled to run.
Aug 20 11:37:15 localhost kernel: SELinux: Initializing.
Aug 20 11:37:17 localhost kernel: SELinux: Disabled at runtime.
Aug 20 11:37:23 localhost journal: Unable to lookup SELinux process context: Invalid argument
Aug 20 11:37:44 localhost gnome-session: SELinux Troubleshooter: Applet requires SELinux be enabled to run.
Aug 20 11:39:42 localhost kernel: SELinux: Initializing.
Aug 20 11:39:44 localhost kernel: SELinux: Disabled at runtime.
Aug 20 11:39:50 localhost journal: Unable to lookup SELinux process context: Invalid argumentCes types d’erreurs vont bien.
Dans la deuxième phase, nous devons éditer le fichier de configuration pour changer la directive SELINUX de * permissive * à * * dans le fichier + / etc / sysconfig / selinux +:
...
SELINUX=enforcing
...Ensuite, redémarrez le serveur à nouveau.
rebootUne fois le serveur en ligne, nous pouvons exécuter la commande + sestatus + pour vérifier le statut SELinux. Il devrait maintenant montrer plus de détails sur le serveur:
SELinux status: enabled
SELinuxfs mount: /sys/fs/selinux
SELinux root directory: /etc/selinux
Loaded policy name: targeted
Current mode: permissive
Mode from config file: error (Success)
Policy MLS status: enabled
Policy deny_unknown status: allowed
Max kernel policy version: 28Vérifiez le fichier / var / log / messages:
cat /var/log/messages | grep "SELinux"Il ne devrait y avoir aucune erreur. La sortie devrait ressembler à ceci:
Aug 20 11:42:06 localhost kernel: SELinux: Initializing.
Aug 20 11:42:09 localhost systemd[1]: Successfully loaded SELinux policy in 183.302ms.
Aug 20 11:44:25 localhost kernel: SELinux: Initializing.
Aug 20 11:44:28 localhost systemd[1]: Successfully loaded SELinux policy in 169.039ms.Vérification des modes et de l’état SELinux (à nouveau)
Nous pouvons exécuter la commande + getenforce + pour vérifier le mode SELinux actuel.
getenforceSi notre système fonctionne en mode de mise en application, la sortie ressemblera à ceci:
EnforcingLa sortie sera différente si SELinux est désactivé:
DisabledNous pouvons également exécuter la commande + sestatus + pour obtenir une meilleure image.
sestatusSi SELinux n’est pas désactivé, la sortie indiquera son statut actuel, son mode actuel, le mode défini dans le fichier de configuration et le type de politique.
SELinux status: enabled
SELinuxfs mount: /sys/fs/selinux
SELinux root directory: /etc/selinux
Loaded policy name: targeted
Current mode: enforcing
Mode from config file: enforcing
Policy MLS status: enabled
Policy deny_unknown status: allowed
Max kernel policy version: 28Lorsque SELinux est désactivé, le résultat affiché est le suivant:
SELinux status: disabledNous pouvons également basculer temporairement entre les modes d’application et d’application en utilisant la commande + setenforce +. (Notez que nous ne pouvons pas exécuter + setenforce + lorsque SELinux est désactivé.)
Commencez par changer le mode SELinux de forcer en permissif dans notre système CentOS 7:
setenforce permissiveL’exécution de la commande + sestatus + indique maintenant que le mode actuel est différent du mode défini dans le fichier de configuration:
SELinux status: enabled
SELinuxfs mount: /sys/fs/selinux
SELinux root directory: /etc/selinux
Loaded policy name: targeted
Current mode: permissive
Mode from config file: enforcing
Policy MLS status: enabled
Policy deny_unknown status: allowed
Max kernel policy version: 28Revenir à * appliquer *:
setenforce enforcingPolitique SELinux
La politique de SELinux est au cœur du moteur de sécurité de SELinux. Une politique est ce que son nom implique: un ensemble de règles qui définissent la sécurité et les droits d’accès pour tout ce qui se trouve dans le système. Et lorsque nous disons «tout», nous entendons les utilisateurs, les rôles, les processus et les fichiers. La politique définit la relation entre chacune de ces entités.
Quelques terminologie de base
Pour comprendre la politique, nous devons apprendre une terminologie de base. Nous entrerons dans les détails plus tard, mais voici une brève introduction. Une stratégie SELinux définit l’accès des utilisateurs aux rôles, des rôles aux domaines et des types d’accès aux domaines.
Utilisateurs
SELinux dispose d’un ensemble d’utilisateurs prédéfinis. Chaque compte d’utilisateur Linux standard est mappé à un ou plusieurs utilisateurs de SELinux.
Sous Linux, un utilisateur exécute un processus. Cela peut être aussi simple que l’utilisateur * jo * ouvrant un document dans l’éditeur vi (ce sera le compte de jo exécutant le processus vi) ou un compte de service exécutant le démon httpd. Dans le monde SELinux, un processus (un démon ou un programme en cours d’exécution) s’appelle un subject.
Les rôles
Un rôle est comme une passerelle entre un utilisateur et un processus. Un rôle définit les utilisateurs pouvant accéder à ce processus. Les rôles ne sont pas comme des groupes, mais plutôt comme des filtres: un utilisateur peut entrer ou assumer un rôle à tout moment, à condition que le rôle le lui permette. La définition d’un rôle dans la stratégie SELinux définit les utilisateurs ayant accès à ce rôle. Il définit également les domaines de processus auxquels le rôle lui-même a accès. Les rôles entrent en jeu car une partie de SELinux implémente ce que l’on appelle le * contrôle basé sur les rôles *.
-
Sujets et objets *
Un objet est un processus et peut potentiellement affecter un objet.
Un objet dans SELinux est tout ce sur quoi on peut agir. Cela peut être un fichier, un répertoire, un port, un socket TCP, le curseur ou peut-être un serveur X. Les actions qu’un sujet peut effectuer sur un objet sont ses permissions.
-
Les domaines sont pour les sujets *
Un domain est le contexte dans lequel un sujet (processus) SELinux peut s’exécuter. Ce contexte est comme une enveloppe autour du sujet. Il indique au processus ce qu’il peut et ne peut pas faire. Par exemple, le domaine définira quels fichiers, répertoires, liens, périphériques ou ports sont accessibles au sujet.
-
Les types sont pour les objets *
Un type est le contexte d’un fichier qui précise son objectif. Par exemple, le contexte d’un fichier peut indiquer qu’il s’agit d’une page Web, que le fichier appartient au répertoire + / etc + ou que le propriétaire du fichier est un utilisateur spécifique de SELinux. Le contexte d’un fichier s’appelle son type dans le jargon SELinux.
-
Alors, quelle est la politique de SELinux? *
La stratégie SELinux définit l’accès des utilisateurs aux rôles, des rôles aux domaines et des types d’accès aux domaines. Tout d’abord, l’utilisateur doit être autorisé à entrer un rôle, puis le rôle doit être autorisé à accéder au domaine. Le domaine à son tour est limité à l’accès à certains types de fichiers uniquement.
La stratégie elle-même est un ensemble de règles qui stipulent que les utilisateurs de telle ou telle personne ne peuvent assumer que des rôles de telle manière, et que ces rôles sont autorisés à accéder uniquement à des domaines de telle manière. Les domaines à leur tour peuvent uniquement accéder à de tels types de fichiers. L’image suivante montre le concept:
image: https: //assets.digitalocean.com/articles/SELinuxCentOS7/1.jpg [Utilisateurs, rôles, domaines et fichiers SELinux]
Conseil terminologique: le dernier bit, dans lequel un processus exécuté dans un domaine particulier ne peut effectuer que certaines opérations sur certains types d’objets, est appelé Type Enforcement (TE).
Pour revenir au sujet des politiques, les implémentations de politiques SELinux sont aussi généralement targeted par défaut. Si vous vous souvenez du fichier de configuration SELinux que nous avons vu précédemment, la directive SELINUXTYPE est définie sur + ciblé +. Cela signifie que par défaut, SELinux ne restreindra que certains processus du système (c’est-à-dire seuls certains processus sont ciblés). Ceux qui ne sont pas ciblés s’exécutent dans des domaines non restreints.
L’alternative est un modèle de refus par défaut dans lequel chaque accès est refusé à moins d’être approuvé par la stratégie. Ce serait une implémentation très sécurisée, mais cela impliquerait également que les développeurs anticipent toutes les autorisations possibles dont chaque processus peut avoir besoin sur chaque objet possible. Le comportement par défaut voit SELinux s’intéresser à certains processus seulement.
-
Comportement de la politique SELinux *
La politique SELinux ne remplace pas la sécurité traditionnelle du CAD. Si une règle DAC empêche un utilisateur d’accéder à un fichier, les règles de stratégie SELinux ne seront pas évaluées, car la première ligne de défense en a déjà bloqué l’accès. Les décisions de sécurité de SELinux entrent en jeu. La sécurité du DAC a été évaluée.
Lorsqu’un système activé pour SELinux démarre, la stratégie est chargée en mémoire. La politique SELinux est au format modulaire, un peu comme les modules du noyau chargés au démarrage. Et tout comme les modules du noyau, ils peuvent être ajoutés dynamiquement et supprimés de la mémoire au moment de l’exécution. La policy store utilisée par SELinux garde une trace des modules chargés. La commande + sestatus + affiche le nom du magasin de règles. La commande + semodule -l + répertorie les modules de stratégie SELinux actuellement chargés en mémoire.
Pour avoir une idée de cela, exécutons la commande + semodule +:
semodule -l | lessLa sortie ressemblera à ceci:
abrt 1.2.0
accountsd 1.0.6
acct 1.5.1
afs 1.8.2
aiccu 1.0.2
aide 1.6.1
ajaxterm 1.0.0
alsa 1.11.4
amanda 1.14.2
amtu 1.2.3
anaconda 1.6.1
antivirus 1.0.0
apache 2.4.0
...
...+ semodule + peut être utilisé pour un certain nombre de tâches telles que l’installation, la suppression, le rechargement, la mise à niveau, l’activation et la désactivation des modules de stratégie SELinux.
A présent, vous seriez probablement intéressé de savoir où sont situés les fichiers du module. La plupart des distributions modernes incluent des versions binaires des modules dans les packages SELinux. Les fichiers de règles ont une extension .pp. Pour CentOS 7, nous pouvons exécuter la commande suivante:
ls -l /etc/selinux/targeted/modules/active/modules/La liste montre un certain nombre de fichiers avec l’extension + .pp +. Si vous regardez de près, elles se rapporteront à différentes applications:
...
-rw-r--r--. 1 root root 10692 Aug 20 11:41 anaconda.pp
-rw-r--r--. 1 root root 11680 Aug 20 11:41 antivirus.pp
-rw-r--r--. 1 root root 24190 Aug 20 11:41 apache.pp
-rw-r--r--. 1 root root 11043 Aug 20 11:41 apcupsd.pp
...Les fichiers + .pp + ne sont toutefois pas lisibles par l’homme.
La modularisation de SELinux fonctionne comme suit: lorsque le système démarre, les modules de stratégie sont combinés dans ce que l’on appelle la stratégie_active_. Cette politique est ensuite chargée en mémoire. La version binaire combinée de cette stratégie chargée se trouve dans le répertoire + / etc / selinux / target / policy +.
ls -l /etc/selinux/targeted/policy/montrera la politique active.
total 3428
-rw-r--r--. 1 root root 3510001 Aug 20 11:41 policy.29Modification des paramètres booléens SELinux
Bien que vous ne puissiez pas lire les fichiers du module de stratégie, il existe un moyen simple d’ajuster leurs paramètres. C’est fait via SELinux booleans.
Pour voir comment cela fonctionne, exécutons la commande + semanage boolean -l +.
semanage boolean -l | lessCela montre les différents commutateurs qui peuvent être activés ou désactivés, ce qu’ils font et leurs statuts actuels:
ftp_home_dir (off , off) Allow ftp to home dir
smartmon_3ware (off , off) Allow smartmon to 3ware
mpd_enable_homedirs (off , off) Allow mpd to enable homedirs
xdm_sysadm_login (off , off) Allow xdm to sysadm login
xen_use_nfs (off , off) Allow xen to use nfs
mozilla_read_content (off , off) Allow mozilla to read content
ssh_chroot_rw_homedirs (off , off) Allow ssh to chroot rw homedirs
mount_anyfile (on , on) Allow mount to anyfile
...
...Nous pouvons voir que la première option permet au démon FTP d’accéder aux répertoires de départ des utilisateurs. Le réglage est désactivé pour le moment.
Pour modifier les paramètres, vous pouvez utiliser la commande + setsebool +. À titre d’exemple, considérons l’accès en écriture FTP anonyme:
getsebool ftpd_anon_writeCela nous montre que l’interrupteur est éteint pour le moment:
ftpd_anon_write --> offEnsuite, nous changeons le booléen pour l’activer:
setsebool ftpd_anon_write onVérifier à nouveau la valeur devrait montrer le changement:
ftpd_anon_write --> onLes booléens modifiés ne sont pas permanents. Ils reviennent à leurs anciennes valeurs après un redémarrage. Pour rendre les choses permanentes, nous pouvons utiliser le commutateur -P avec la commande + setsebool +.
Conclusion
Dans la première partie de ce didacticiel, nous avons essayé de comprendre quelques concepts de base autour de SELinux. Nous avons vu comment SELinux peut sécuriser un système, comment l’activer et dans quels modes il peut s’exécuter. Nous avons également abordé le sujet de la politique SELinux. Ensuite, nous allons apprendre à utiliser https://www.digitalocean.com/community/tutorials/an-inintroduction-to-selinux-on-centos-7-part-2-files-and-processes&; comment utiliser SELinux pour restreindre l’accès aux fichiers et processus].