« LINUX:SELinux-Alertes et Journaux » : différence entre les versions
Aucun résumé des modifications |
Aucun résumé des modifications |
||
Ligne 39 : | Ligne 39 : | ||
* tclass : le type d'accès au fichier demandé | * tclass : le type d'accès au fichier demandé | ||
* {...} : la méthode d'accès au fichier demandé (en début de liste) | * {...} : la méthode d'accès au fichier demandé (en début de liste) | ||
Par exemple pour la première ligne, le programme serveur Fail2Ban | Par exemple pour la première ligne, le programme serveur Fail2Ban selon le type Selinux "fail2ban_t" essaye d'accéder au fichier "/var/log/mariadb/mariadb.log" ayant le type Selinux "mysqld_log_t"; il veut y accéder selon le type d'accès "file" grâce à la méthode "watch" qui est refusée (denied). Pour régler ce problème, il faudra ajouter par exemple une règle permettant cet accès ou corriger l'utilisation du programme. | ||
=Commandes de lignes= | |||
Il existe plusieurs commandes de lignes permettant de visionner ces alertes, telles "sealert" ou 'ausearch". | |||
Nous n'allons pas les décrire car nous n'avons pas eu besoin de les utiliser directement. Nous les utiliserons indirectement au travers d'autres outils. | |||
= | =Cockpit= | ||
Version du 6 janvier 2024 à 23:19
But
Quand une règle est enfreinte, outre que l'accès demandé est refusé, une alerte est déclenchée et un message est envoyé aux journaux. Lors que cet événement arrive, le service "setroubleshootd.service" s’enclenche automatiquement; il envoie un message aux services "auditd.service" et "rsyslog.service". D'où l'importance d'activer ces deux services.
Journaux
Le service "auditd.service" écrit ses messages dans le fichier "/var/log/audit/audit.log" et le service "rsyslog.service" dans le fichier "/var/log/messages".
Voici un extrait de trois messages provenant du fichier "audit.log":
Jul 29 16:31:59 serverdb audit[16758]: AVC avc: denied { watch } for pid=16758 comm="fail2ban-server" path="/var/log/mariadb/mariadb.log" dev="dm-3" ino=1700802 scontext=system_u:system_r:fail2ban_t:s0 tcontext=system_u:object_r:mysqld_log_t:s0 tclass=file permissive=0 Dec 14 16:05:00 serverdb audit[3991714]: AVC avc: denied { write } for pid=3991714 comm="php-fpm" name="www-error.log" dev="dm-4" ino=785036 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:httpd_log_t:s0 tclass=file permissive=0 Aug 6 15:59:10 serverdb audit[731396]: AVC avc: denied { open } for pid=731396 comm="BackupPC_Admin" path="/sauvegarde/backuppc/pc/serverbck1.home.dom/LOCK" dev="dm-3" ino=268435555 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:default_t:s0 tclass=file permissive=0
On les repère par la chaine "AVC avc: denied".
Voici un extrait équivalent provenant du fichier "messages":
type=AVC msg=audit(1690544030.649:142): avc: denied { watch } for pid=1020 comm="fail2ban-server" path="/var/log/mariadb/mariadb.log" dev="dm-4" ino=1701672 scontext=system_u:system_r:fail2ban_t:s0 tcontext=system_u:object_r:mysqld_log_t:s0 tclass=file permissive=0 type=AVC msg=audit(1702566300.939:82055): avc: denied { write } for pid=3991714 comm="php-fpm" name="www-error.log" dev="dm-4" ino=785036 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:httpd_log_t:s0 tclass=file permissive=0 type=AVC msg=audit(1691485897.697:31328): avc: denied { open } for pid=1339363 comm="BackupPC_Admin" path="/sauvegarde/backuppc/pc/serverbck1.home.dom/LOCK" dev="dm-3" ino=268435555 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:default_t:s0 tclass=file permissive=0
On les repère par la chaîne en début "type=AVC" et la chaîne "avc: denied" un peu plus loin.
La suite du message comporte diverses informations sous fourme d'une variable et de sa valeur séparés par le signe égal. En analysant leur contenu, on peut en déduire d'où provient le problème de blocage. Souvenons-nous que sous Unix, tout est représenté au travers d'un fichier.
Voici une description de quelques unes de ces variables:
- pid : le n° du programme lancé
- comm : le nom du programme concerné
- path ou name : le chemin ou le nom du fichier concerné qui est utilisé par ce programme
- scontext : le contexte du fichier source effectuant l'appel au fichier cible
- tcontext : le contexte du fichier cible
- tclass : le type d'accès au fichier demandé
- {...} : la méthode d'accès au fichier demandé (en début de liste)
Par exemple pour la première ligne, le programme serveur Fail2Ban selon le type Selinux "fail2ban_t" essaye d'accéder au fichier "/var/log/mariadb/mariadb.log" ayant le type Selinux "mysqld_log_t"; il veut y accéder selon le type d'accès "file" grâce à la méthode "watch" qui est refusée (denied). Pour régler ce problème, il faudra ajouter par exemple une règle permettant cet accès ou corriger l'utilisation du programme.
Commandes de lignes
Il existe plusieurs commandes de lignes permettant de visionner ces alertes, telles "sealert" ou 'ausearch".
Nous n'allons pas les décrire car nous n'avons pas eu besoin de les utiliser directement. Nous les utiliserons indirectement au travers d'autres outils.