Configurez SELinux pour permettre aux démons d'utiliser des fichiers dans des emplacements autres que ceux par défaut

Contexte

SELinux ajoute une autre couche de vérification des autorisations sur les systèmes Linux. Sur les systèmes compatibles SELinux, les autorisations DAC régulières sont vérifiées en premier, et si elles autorisent l'accès, la politique de SELinux est consulté. Si la politique SELinux refuse l'accès, une entrée de journal est générée dans le journal d'audit dans /var/log/audit/audit.log ou dans dmesg si auditd ne s'exécute pas sur le système.

SELinux attribue une étiquette, appelée contexte de sécurité , à chaque objet (fichier, processus, etc.) du système :

Fichiers ont un contexte de sécurité stocké dans des attributs étendus. Ceux-ci peuvent être visualisés avec ls -Z .

SELinux maintient une base de données mappant les modèles de chemins aux contextes de fichiers par défaut. Cette base de données est utilisée lorsque vous devez restaurer manuellement les contextes de fichiers par défaut ou lorsque le système est réétiqueté. Cette base de données peut être interrogée avec semanage outil.
Processus se voient attribuer un contexte de sécurité lors de l'exécution d'un exécutable (execve appel système). Les contextes de sécurité des processus peuvent être visualisés avec la plupart des outils de surveillance du système, par exemple avec ps Z $PID .
D'autres objets étiquetés existent également, mais ne sont pas pertinents pour cette réponse.

Politique de SELinux contient les règles qui spécifient quelles opérations entre les contextes sont autorisées. SELinux fonctionne sur liste blanche règles, tout ce qui n'est pas explicitement autorisé par la politique est refusé. La politique de référence contient des modules de politique pour de nombreuses applications et il s'agit généralement de la politique utilisée par les distributions compatibles SELinux. Cette réponse décrit principalement comment travailler avec une stratégie basée sur la stratégie de référence, que vous utilisez très probablement si vous utilisez la stratégie fournie par la distribution.

Lorsque vous exécutez votre application en tant qu'utilisateur normal, vous ne remarquez probablement pas SELinux, car la configuration par défaut place les utilisateurs en mode non confiné le contexte. Processus exécutés en non confiné contexte ont très peu de restrictions en place. Vous pourrez peut-être exécuter votre programme sans problème dans le shell utilisateur dans un contexte non confiné, mais lorsqu'il est lancé à l'aide du système init, il peut ne plus fonctionner dans un contexte restreint.

Problèmes typiques

Lorsque les fichiers se trouvent dans un emplacement autre que celui par défaut (non décrit dans la politique par défaut), les problèmes sont souvent liés aux raisons suivantes :

Les fichiers ont un contexte de fichier incorrect/incompatible :Fichiers déplacés avec mv conserver leurs métadonnées, y compris les contextes de sécurité des fichiers de l'ancien emplacement. Les fichiers créés dans un nouvel emplacement ont hérité du contexte du répertoire parent ou du processus de création.
Avoir plusieurs démons utilisant les mêmes fichiers :La politique par défaut n'inclut pas de règles pour permettre l'interaction entre les contextes de sécurité en question.

Fichiers avec un contexte de sécurité incorrect

Si les fichiers ne sont pas utilisés par un autre démon (ou un autre processus confiné) et que le seul changement est l'emplacement où les fichiers sont stockés, les modifications requises à la configuration de SELinux sont :

Ajouter une nouvelle règle à la base de données de contexte de fichier
Appliquer le contexte de fichier correct aux fichiers existants

Le contexte de fichier sur l'emplacement par défaut peut être utilisé comme modèle pour le nouvel emplacement. La plupart des modules de politique incluent une documentation de page de manuel (générée à l'aide de sepolicy manpages ) expliquant les contextes de fichiers alternatifs possibles avec leur sémantique d'accès.

La base de données de contexte de fichier utilise la syntaxe d'expression régulière, ce qui permet d'écrire des spécifications qui se chevauchent. Il est intéressant de noter que le contexte appliqué est la dernière spécification trouvée.

Pour ajouter une nouvelle entrée à la base de données de contexte de fichier :

semanage fcontext -a -t <type> "/path/here/(/.*)?"

Une fois la nouvelle entrée de contexte ajoutée à la base de données, le contexte de la base de données peut être appliqué à vos fichiers à l'aide de restorecon <files> . Exécution de restorecon avec -vn les drapeaux montreront quels contextes de fichiers seraient modifiés sans appliquer aucun changement.

Tester un nouveau contexte de fichier sans ajouter de nouvelle entrée dans la base de données

Le contexte peut être changé manuellement avec chcon outil. Ceci est utile lorsque vous souhaitez tester le nouveau contexte de fichier sans ajouter d'entrée à la base de données de contexte de fichier.

Le nouveau contexte de fichier est spécifié dans les arguments de chcon . Lorsqu'il est utilisé avec --reference= option, le contexte de sécurité d'un fichier de référence est copié dans les fichiers cibles.

en utilisant un contexte spécifique (default_t ):

chcon -t default_t <target files>

ou en utilisant une référence :

chcon --reference=<path to default location> <target files>

Remarque sur les différents systèmes de fichiers et points de montage

Si le nouvel emplacement est son propre point de montage, le contexte peut être défini avec une option de montage. Le contexte défini avec l'option de montage n'est pas stocké sur le disque, il peut donc également être utilisé avec des systèmes de fichiers qui ne prennent pas en charge les attributs étendus.

mount <device> <mount point> -o context="<context>"

Autoriser les processus s'exécutant dans différents contextes de sécurité à utiliser les mêmes fichiers

Option 1 :booléens

La politique de référence inclut des options réglables, appelées booléens , qui activent/désactivent certaines règles supplémentaires. Beaucoup d'entre eux permettent l'inter-opération de différents démons système qui n'utilisent généralement pas les mêmes fichiers.

La liste de toutes les options réglables possibles et leurs descriptions peuvent être répertoriées à l'aide de semanage boolean -l . audit2allow pourrait également être en mesure de dire directement quel booléen doit être activé.

Pour activer/désactiver un booléen en utilisant semanage :

semanage boolean --on <boolean name>
semanage boolean --off <boolean name>

Les booléens sont le moyen le plus simple de modifier la stratégie. Cependant, toutes les situations possibles ne peuvent pas être résolues en basculant un booléen. Certains booléens autorisent également un accès très large, étant trop permissifs.

Option 2 :Étendre la politique avec un nouveau module

Si aucun booléen n'existe pour autoriser l'accès, la politique doit être modifiée en ajoutant un module personnalisé.

Un module simple ajoutant les règles requises pour autoriser l'accès peut être généré à partir des fichiers journaux en utilisant audit2allow avec les étapes suivantes :

Définir le domaine du démon (contexte de sécurité) en mode permissif . En mode permissif, la règle n'est pas appliquée , mais les journaux sont générés sur l'accès que la stratégie refuserait normalement.
```
semanage permissive -a <domain>
```
Testez votre démon en fonctionnement normal pour générer des entrées de journal.
Créez un nouveau module de stratégie et insérez-le.
```
audit2allow -a -M <name>
semodule -i <name>.pp'
```
Réactiver le mode d'application
```
semanage permissive -d <domain>
```

Cette méthode fonctionne mieux lorsque seuls quelques contextes de sécurité sont impliqués. Dans une configuration complexe, vous devrez très probablement écrire votre propre module de stratégie. Certaines ressources pour démarrer sont le wiki gentoo et la documentation de l'API de politique de référence.

Avec cette commande :

# semanage fcontext -l /oldpath/

Vous pouvez vérifier les contextes SElinux par défaut dans les dossiers de votre système. Ainsi, avec cette commande, vous pouvez voir le contexte par défaut de ce dossier démon.

Ainsi, vous pouvez vérifier les contextes SELinux que vous devez configurer dans le répertoire vers lequel vous souhaitez déplacer votre contenu.

Disons que vous voyez que votre dossier démon a ce contexte (c'est le contexte apache) :

# semanage fcontext -l
...
/var/www(/.*)? all files system_u:object_r:httpd_sys_content_t:s0

Ensuite, vous appliquerez ces contextes au nouveau chemin comme celui-ci (exemple avec le contexte de sécurité par défaut du démon apache)

# semanage fcontext -a -t httpd_sys_content_t '/newpath(/.*)?'

Après cela, étant donné que votre contenu est déjà dans le nouveau chemin, vous devez forcer tout ce qui se trouve sous ce chemin, pour obtenir ce contexte :

# restorecon -RFvv /newpath

Vous pouvez vérifier si cela a fonctionné, avec cette commande :

# ls -Zd /newpath/

N'oubliez pas que lorsque vous mv un répertoire ou des fichiers, il maintient le contexte de sécurité Lorsque vous cp un dossier ou un répertoire, il définit le contexte sur celui du parent.

Si vous avez besoin de consulter les pages de manuel d'un logiciel spécifique, vous pouvez installer les pages de manuel avec :

# yum install -y selinux-policy-devel

N'oubliez pas d'exécuter cette commande, pour réindexer la base de données man :

# mandb

Ensuite, vous pouvez exécuter celui-ci et consulter toutes les pages de manuel selinux.

# man -k selinux

Suggestion, exécutez cette commande avant et après l'installation de ce package, pour voir la différence :

# man -k selinux | wc -l