DOCS/UNIX/SElinux - Historique des versions

Admin : /* Créer des politiques de sécurité SELinux customisées avec audit2allow */

2020-12-11T19:18:08Z

Créer des politiques de sécurité SELinux customisées avec audit2allow

Admin : /* Creéer des politiques de sécurité SELinux customisées avec audit2allow */

2020-12-11T19:16:45Z

Creéer des politiques de sécurité SELinux customisées avec audit2allow

Admin : /* Collecter les logs d'audit en mode permissif */

2020-12-11T19:09:39Z

Collecter les logs d'audit en mode permissif

Admin : /* Ré-étiquetage des fichiers */

2020-12-11T19:09:13Z

Ré-étiquetage des fichiers

Admin : /* Ré-étiquetage des fichiers */

2020-12-11T18:49:01Z

Ré-étiquetage des fichiers

Admin : /* Ré-étiquetage des fichiers */

2020-12-11T18:46:28Z

Ré-étiquetage des fichiers

Admin : /* SELinux & Auditd */

2020-12-11T18:42:11Z

SELinux & Auditd

Admin : /* SELinux & Auditd */

2020-12-11T18:41:05Z

SELinux & Auditd

Admin : /* SELinux & Auditd */

2020-12-11T18:31:41Z

SELinux & Auditd

Admin : /* SELinux & Auditd */

2020-12-11T18:30:37Z

SELinux & Auditd

← Version précédente		Version du 11 décembre 2020 à 19:18
Ligne 494 :		Ligne 494 :

	Nous pouvons ensuite continuer à surveiller nos fichiers journaux SELinux pour vérifier que notre module de politique personnalisé fonctionne et, une fois que nous sommes satisfaits, nous pouvons réactiver le mode SELinux Enforcing et bénéficier à nouveau de la protection SELinux de notre serveur smtp désormais pleinement fonctionnel.		Nous pouvons ensuite continuer à surveiller nos fichiers journaux SELinux pour vérifier que notre module de politique personnalisé fonctionne et, une fois que nous sommes satisfaits, nous pouvons réactiver le mode SELinux Enforcing et bénéficier à nouveau de la protection SELinux de notre serveur smtp désormais pleinement fonctionnel.
		+
		+
		+	=Résumé=
		+	Cet article est destiné à donner un aperçu du travail avec SELinux pour les utilisateurs novices. SELinux est installé et activé par défaut, et pour la plupart des utilisateurs, il fonctionnera sans problème en offrant un niveau de sécurité accru. SELinux convient à toutes les catégories d'installation, y compris les serveurs, les stations de travail, les ordinateurs de bureau et les ordinateurs portables.
		+
		+	Bien que SELinux puisse sembler assez intimidant et complexe pour les utilisateurs qui ne le connaissent pas, ce n'est pas une raison pour le désactiver à l'installation. Si SELinux présente des problèmes, il est facile de passer en mode permissif, où les problèmes sont uniquement enregistrés et non bloqués. Lorsque des problèmes surviennent, les techniques présentées dans cet article peuvent être utilisées pour les dépanner et les résoudre.

← Version précédente		Version du 11 décembre 2020 à 19:16
Ligne 453 :		Ligne 453 :
	Cette approche ne souffre pas de la lourdeur du setenforce 0 et permet à tous les autres services du système de continuer à bénéficier des contrôles d'accès de SELinux.		Cette approche ne souffre pas de la lourdeur du setenforce 0 et permet à tous les autres services du système de continuer à bénéficier des contrôles d'accès de SELinux.

−	=~~Creéer~~ des politiques de sécurité SELinux customisées avec audit2allow=	+	=Créer des politiques de sécurité SELinux customisées avec audit2allow=
		+
		+	Il arrive parfois qu'aucune des méthodes ci-dessus ne permette de traiter une situation donnée et nous devons étendre la politique SELinux en créant un module de politique personnalisé pour permettre un certain ensemble de conditions. Prenons par exemple le module complémentaire du service Postgrey pour un serveur de messagerie smtp. Notre serveur smtp doit communiquer avec postgrey sur une socket Unix et c'est quelque chose que la politique SELinux par défaut de notre serveur smtp ne permet pas. Par conséquent, le service est bloqué par SELinux. C'est un problème qui ne peut pas être résolu en modifiant ou en restaurant les contextes de sécurité des types de fichiers et ce n'est pas quelque chose qui a une valeur booléenne que nous pouvons autoriser par basculement. Nous pourrions désactiver la protection SELinux du serveur smtp par le biais d'un booléen, ce qui serait mieux que de désactiver complètement SELinux, mais c'est encore loin d'être idéal.
		+
		+	Si nous passons SELinux en mode permissif et que nous faisons fonctionner notre serveur de messagerie pendant une période déterminée, nous pouvons enregistrer les problèmes de SELinux tout en autorisant l'accès (comme mentionné dans la section "Collecter les journaux d'audit en mode permissif"). En vérifiant nos journaux, nous voyons les messages AVC SELinux suivants :
		+
		+	type=AVC msg=audit(1218128130.653:334): avc: denied { connectto } for pid=9111 comm="smtpd" path="/var/spool/postfix/postgrey/socket"
		+	scontext=system_u:system_r:postfix_smtpd_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=unix_stream_socket
		+	type=AVC msg=audit(1218128130.653:334): avc: denied { write } for pid=9111 comm="smtpd" name="socket" dev=sda6 ino=39977017
		+	scontext=system_u:system_r:postfix_smtpd_t:s0 tcontext=system_u:object_r:postfix_spool_t:s0 tclass=sock_file
		+
		+	Nous pouvons ensuite utiliser <code>audit2allow</code> pour générer un ensemble de règles qui permettraient les actions requises. Nous pouvons générer un fichier local de politique d'application de type postgrey (postgreylocal.te) :
		+
		+
		+	<syntaxhighlight lang="yaml">
		+	# grep smtpd_t /var/log/audit/audit.log \| audit2allow -m postgreylocal > postgreylocal.te
		+	# cat postgreylocal.te
		+	module postgreylocal 1.0;
		+	require {
		+	type postfix_smtpd_t;
		+	type postfix_spool_t;
		+	type initrc_t;
		+	class sock_file write;
		+	class unix_stream_socket connectto;
		+	}
		+	#============= postfix_smtpd_t ==============
		+	allow postfix_smtpd_t initrc_t:unix_stream_socket connectto;
		+	allow postfix_smtpd_t postfix_spool_t:sock_file write;
		+	</syntaxhighlight>
		+
		+	Nous voyons ci-dessus que nous pouvons greffer le fichier audit.log pour les problèmes liés à notre serveur smtp et les transmettre à <code>audit2allow</code> qui génère un ensemble de règles qui, selon lui, autorisent les actions actuellement refusées par la politique de SELinux. En examinant ces règles, nous constatons que notre serveur smtp veut se connecter et écrire sur une socket Unix qui, comme nous le voyons dans nos journaux, est la socket Unix sur laquelle le service postgrey est à l'écoute. Comme cela semble parfaitement raisonnable, nous pouvons utiliser audit2allow pour créer un module de politique personnalisé permettant ces actions :
		+
		+	# grep smtpd_t /var/log/audit/audit.log \| audit2allow -M postgreylocal
		+
		+	Nous chargeons ensuite notre module de politique post-Grey en utilisant la commande <code>semodule</code> dans la politique SELinux actuelle :
		+
		+	# semodule -i postgreylocal.pp
		+
		+	qui ajoutera notre module de politique post-gris à <code>/etc/selinux/targeted/modules/active/modules/postgreylocal.pp</code>. Nous pouvons vérifier que le module politique est correctement chargé en inscrivant <code>semodule -l</code> sur la liste des modules chargés.
		+
		+	Nous pouvons ensuite continuer à surveiller nos fichiers journaux SELinux pour vérifier que notre module de politique personnalisé fonctionne et, une fois que nous sommes satisfaits, nous pouvons réactiver le mode SELinux Enforcing et bénéficier à nouveau de la protection SELinux de notre serveur smtp désormais pleinement fonctionnel.

@@ Ligne 443 : / Ligne 443 : @@
   scontext=system_u:system_r:postfix_smtpd_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=unix_stream_socket
-Le voici : <code>postfix_smtpd_t</code<. Pour autoriser temporairement l'accès à toute opération souhaitée par ce domaine, nous pouvons utiliser la <code>semanage</code> pour ajouter un nouveau type permissif :
+Le voici : <code>postfix_smtpd_t</code>. Pour autoriser temporairement l'accès à toute opération souhaitée par ce domaine, nous pouvons utiliser la <code>semanage</code> pour ajouter un nouveau type permissif :
   semanage permissive -a postfix_smtpd_t

@@ Ligne 350 : / Ligne 350 : @@
   ausearch -m AVC,USER_AVC -i --success yes
-==Ré-étiquetage des fichiers==
+==Réétiquetage des fichiers==
 La commande <code>chcon</code> peut être utilisée pour modifier le contexte de sécurité SELinux d'un fichier ou de plusieurs fichiers/répertoires de la même manière que les commandes "chown" ou "chmod" peuvent être utilisées pour modifier la propriété ou les autorisations standard d'un fichier.
@@ Ligne 389 : / Ligne 389 : @@
 pour ajouter un contexte de fichier de type httpd_sys_content_t pour tout ce qui se trouve sous /html.

← Version précédente		Version du 11 décembre 2020 à 18:49
Ligne 379 :		Ligne 379 :
	drwxr-xr-x root root user_u:object_r:httpd_sys_content_t html		drwxr-xr-x root root user_u:object_r:httpd_sys_content_t html
	</syntaxhighlight>		</syntaxhighlight>
		+
		+	De même, nous aurions pu régler les deux en une seule fois en utilisant le commutateur récursif <code>-R</code> :
		+
		+	# chcon -Rv --type=httpd_sys_content_t /html
		+
		+	La modification des contextes de sécurité de cette manière persistera entre les redémarrages du système, mais seulement jusqu'à ce que la partie modifiée du système de fichiers soit réétudiée. Cette opération n'est pas rare et la bonne solution, après test, est d'écrire une règle locale personnalisée (appelée module de politique) et de la fusionner avec les règles locales de base. Il s'agira d'une règle supplémentaire qui s'ajoutera aux plus de 200 règles mentionnées ci-dessus. Pour rendre permanent le changement du contexte de sécurité, même par un réétiquetage complet du système de fichiers, nous pouvons utiliser l'outil de gestion SELinux ou la commande "semanage" de la ligne de commande :
		+
		+	semanage fcontext -a -t httpd_sys_content_t "/html(/.*)?"
		+
		+	pour ajouter un contexte de fichier de type httpd_sys_content_t pour tout ce qui se trouve sous /html.

← Version précédente		Version du 11 décembre 2020 à 18:46
Ligne 351 :		Ligne 351 :

	==Ré-étiquetage des fichiers==		==Ré-étiquetage des fichiers==
		+
		+	La commande <code>chcon</code> peut être utilisée pour modifier le contexte de sécurité SELinux d'un fichier ou de plusieurs fichiers/répertoires de la même manière que les commandes "chown" ou "chmod" peuvent être utilisées pour modifier la propriété ou les autorisations standard d'un fichier.
		+
		+	Examinons quelques exemples.
		+
		+	En utilisant Apache comme exemple, supposons que vous vouliez modifier le DocumentRoot pour servir des pages web à partir d'un emplacement autre que le répertoire /var/www/html/ par défaut. Supposons que nous créions un répertoire (ou peut-être un point de montage) à /html/ et que nous y créions un fichier index.html :
		+
		+	<syntaxhighlight lang="bash">
		+	# mkdir /html
		+	# touch /html/index.html
		+	# ls -Z /html/index.html
		+	-rw-r--r-- root root user_u:object_r:default_t /html/index.html
		+	# ls -Z \| grep html
		+	drwxr-xr-x root root user_u:object_r:default_t html
		+	</syntaxhighlight>
		+
		+	Nous voyons que le répertoire /html/ et le fichier /html/index.html ont tous deux le type de contexte de sécurité : default_t. Si nous démarrons notre navigateur web et essayons de visualiser la page, SELinux refusera correctement l'accès et enregistrera l'erreur parce que le répertoire et le(s) fichier(s) ont le mauvais contexte de sécurité. Nous devons définir le type de contexte de sécurité correct pour Apache de : <code>httpd_sys_content_t. </code>
		+
		+	<syntaxhighlight lang="bash">
		+	# chcon -v --type=httpd_sys_content_t /html
		+	context of /html changed to user_u:object_r:httpd_sys_content_t
		+	# chcon -v --type=httpd_sys_content_t /html/index.html
		+	context of /html/index.html changed to user_u:object_r:httpd_sys_content_t
		+	# ls -Z /html/index.html
		+	-rw-r--r-- root root user_u:object_r:httpd_sys_content_t /html/index.html
		+	# ls -Z \| grep html
		+	drwxr-xr-x root root user_u:object_r:httpd_sys_content_t html
		+	</syntaxhighlight>

@@ Ligne 346 : / Ligne 346 : @@
 Comme il est possible d'empêcher l'enregistrement des enregistrements d'audit en utilisant dontaudit, il est possible que tous les messages AVC ou USER_AVC ne soient pas vus. Pour éviter que les règles dontaudit ne masquent ces messages, l'administrateur peut exécuter le semodule -DB pour reconstruire sa politique SELinux sans les règles dontaudit. Après avoir reproduit le problème, il devrait y avoir plus de messages disponibles qu'auparavant, ainsi que certains enregistrements qui ne sont pas pertinents pour le problème (noatsecure, rlimitinh, et siginh sont des autorisations qui sont toujours vérifiées lorsqu'un programme est exécuté et peuvent généralement être ignorées). Lorsque vous avez terminé l'examen des enregistrements empêchés par les règles de dontaudit, exécutez le semodule <code>-B</code> pour reconstruire la politique avec les rôles de dontaudit inclus à nouveau.
-The inverse of this is the ability to log operations that are successful using auditallow. These logs can be searched for by filtering by successful operations (though this will also return successful events in permissive mode):
+L'inverse est la capacité d'enregistrer les opérations qui réussissent grâce à '''auditallow'''. Ces journaux peuvent être recherchés par filtrage des opérations réussies (bien que cela renvoie également les événements réussis en mode permissif) :
   ausearch -m AVC,USER_AVC -i --success yes
 ==Ré-étiquetage des fichiers==

← Version précédente		Version du 11 décembre 2020 à 18:41
Ligne 326 :		Ligne 326 :
	Il existe plusieurs autres événements d'audit liés à SELinux qui sont utilisés dans IPSec/NetLabel et qui ne sont pas couverts ici pour le moment. Ces événements sont les suivants : MAC_UNLBL_ALLOW, MAC_UNLBL_STCADD, MAC_UNLBL_STCDEL, MAC_MAP_ADD, MAC_MAP_DEL, MAC_IPSEC_EVENT, MAC_CIPSOV4_ADD, MAC_CIPSOV4_DEL.		Il existe plusieurs autres événements d'audit liés à SELinux qui sont utilisés dans IPSec/NetLabel et qui ne sont pas couverts ici pour le moment. Ces événements sont les suivants : MAC_UNLBL_ALLOW, MAC_UNLBL_STCADD, MAC_UNLBL_STCDEL, MAC_MAP_ADD, MAC_MAP_DEL, MAC_IPSEC_EVENT, MAC_CIPSOV4_ADD, MAC_CIPSOV4_DEL.
	}}		}}
		+
		+
		+	Bien que <code>sealert</code> soit très utile pour interpréter les enregistrements AVC, les outils d'audit peuvent donner à l'administrateur une vue plus précise du journal d'audit. <code>'''ausearch'''</code> peut être utilisé pour rechercher des événements spécifiques dans le journal d'audit, et dispose d'une variété d'options disponibles pour travailler avec les enregistrements d'audit. Ainsi, au lieu d'interpréter les messages à l'aide de sealert, il est possible d'examiner les causes potentielles des problèmes de SELinux à l'aide d'ausearch. Les types que nous voulons généralement examiner lors du dépannage d'un problème sont '''AVC, USER_AVC, SELINUX_ERR''' et '''USER_SELINUX_ERR'''. ausearch fournit une option <code>-m</code> qui prend une liste de types d'enregistrements d'audit séparés par des virgules pour les filtrer, ainsi qu'un drapeau <code>-i</code> qui fait que les valeurs numériques soient interprétées en chaînes de caractères selon le système. Cela inclut la conversion des UID/GID en noms d'utilisateur et de groupe, ainsi que le mappage d'une paire d'appel système et d'architecture en nom d'appel système :
		+
		+	ausearch -m AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR -i
		+
		+	Recherche de documents et création d'un point de contrôle, pour s'assurer que les documents d'audit qui ont déjà été vus n'apparaissent pas à nouveau lors de la prochaine recherche :
		+
		+	ausearch --checkpoint="./audit-checkpoint" -m AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR -i
		+
		+	La recherche d'enregistrements basée sur le nom de commande des processus, c'est le nom de l'exécutable de la tâche dans le noyau :
		+
		+	ausearch -c "httpd" -m AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR -i
		+
		+	Trouver les événements où un administrateur (ou un programme) a changé l'état d'application de SELinux :
		+
		+	ausearch -m MAC_STATUS -i
		+
		+	Comme il est possible d'empêcher l'enregistrement des enregistrements d'audit en utilisant dontaudit, il est possible que tous les messages AVC ou USER_AVC ne soient pas vus. Pour éviter que les règles dontaudit ne masquent ces messages, l'administrateur peut exécuter le semodule -DB pour reconstruire sa politique SELinux sans les règles dontaudit. Après avoir reproduit le problème, il devrait y avoir plus de messages disponibles qu'auparavant, ainsi que certains enregistrements qui ne sont pas pertinents pour le problème (noatsecure, rlimitinh, et siginh sont des autorisations qui sont toujours vérifiées lorsqu'un programme est exécuté et peuvent généralement être ignorées). Lorsque vous avez terminé l'examen des enregistrements empêchés par les règles de dontaudit, exécutez le semodule <code>-B</code> pour reconstruire la politique avec les rôles de dontaudit inclus à nouveau.
		+
		+	The inverse of this is the ability to log operations that are successful using auditallow. These logs can be searched for by filtering by successful operations (though this will also return successful events in permissive mode):
		+
		+	ausearch -m AVC,USER_AVC -i --success yes
		+
		+	==Ré-étiquetage des fichiers==

← Version précédente		Version du 11 décembre 2020 à 18:31
Ligne 319 :		Ligne 319 :
	\|}		\|}

		+
		+
		+	{{NOTE\|
		+	contenu=

	Il existe plusieurs autres événements d'audit liés à SELinux qui sont utilisés dans IPSec/NetLabel et qui ne sont pas couverts ici pour le moment. Ces événements sont les suivants : MAC_UNLBL_ALLOW, MAC_UNLBL_STCADD, MAC_UNLBL_STCDEL, MAC_MAP_ADD, MAC_MAP_DEL, MAC_IPSEC_EVENT, MAC_CIPSOV4_ADD, MAC_CIPSOV4_DEL.		Il existe plusieurs autres événements d'audit liés à SELinux qui sont utilisés dans IPSec/NetLabel et qui ne sont pas couverts ici pour le moment. Ces événements sont les suivants : MAC_UNLBL_ALLOW, MAC_UNLBL_STCADD, MAC_UNLBL_STCDEL, MAC_MAP_ADD, MAC_MAP_DEL, MAC_IPSEC_EVENT, MAC_CIPSOV4_ADD, MAC_CIPSOV4_DEL.
		+	}}

← Version précédente		Version du 11 décembre 2020 à 18:30
Ligne 318 :		Ligne 318 :
	\|Enregistré chaque fois qu'un utilisateur exporte un objet étiqueté en utilisant CUPS.		\|Enregistré chaque fois qu'un utilisateur exporte un objet étiqueté en utilisant CUPS.
	\|}		\|}
		+
		+
		+	Il existe plusieurs autres événements d'audit liés à SELinux qui sont utilisés dans IPSec/NetLabel et qui ne sont pas couverts ici pour le moment. Ces événements sont les suivants : MAC_UNLBL_ALLOW, MAC_UNLBL_STCADD, MAC_UNLBL_STCDEL, MAC_MAP_ADD, MAC_MAP_DEL, MAC_IPSEC_EVENT, MAC_CIPSOV4_ADD, MAC_CIPSOV4_DEL.