1. Préambule
Linux Amélioré en Sécurité (SELinux) est un module du noyau Linux et un sous-système de sécurité de Linux.
SELinux a été principalement développé par la NSA. Les noyaux Linux 2.6 et supérieurs intègrent déjà les modules SELinux.
SELinux est très complexe et comporte beaucoup de concepts difficiles à apprendre. De nombreux administrateurs système Linux ont désactivé SELinux car ils le trouvent problématique.
Si vous maîtrisez SELinux et l’utilisez correctement, je pense que tout le système peut en gros atteindre le point d’être « indestructible » (rappelez-vous toujours qu’il n’y a pas de sécurité absolue).
Maîtriser les concepts de base de SELinux ainsi que les méthodes de configuration simples est un cours obligatoire pour tout administrateur système Linux.
Cet article est basé sur CentOS 7.4.1708.
Cet article est purement un partage et un échange d’expérience d’apprentissage personnel, les erreurs sont inévitables, à titre de référence seulement ! Si vous trouvez une erreur, merci de la signaler, merci beaucoup !
2. Le rôle de SELinux et le mécanisme de gestion des permissions
2.1 Le rôle de SELinux
La fonction principale de SELinux est de minimiser les ressources accessibles par les processus de service dans le système (le principe du moindre privilège).
Imaginez que si un service réseau fonctionnant en root a une vulnérabilité 0day, les hackers peuvent exploiter cette vulnérabilité pour faire ce qu’ils veulent sur votre serveur en tant que root. N’est-ce pas effrayant ?
SELinux est là pour résoudre ce problème.
2.2 DAC
Dans un système d’exploitation qui n’utilise pas SELinux, le facteur qui détermine si une ressource peut être accessible est si une ressource dispose des permissions de l’utilisateur correspondant (lire, écrire, exécuter).
Tant que le processus d’accès à cette ressource répond aux conditions ci-dessus, il est accessible à celui-ci.
Le problème le plus fatal est que les utilisateurs root ne sont soumis à aucune réglementation, et que toutes les ressources du système peuvent être accessibles sans restrictions.
Le principal corps de ce mécanisme de gestion des permissions est l’utilisateur, également appelé contrôle d’accès autonome (DAC).
2.3 MAC
Dans un système d’exploitation utilisant SELinux, les facteurs qui déterminent si une ressource peut être accessible ne sont pas seulement ceux ci-dessus, mais aussi si chaque type de processus a accès à un certain type de ressource.
Ainsi, même si un processus fonctionne en tant que root, il est nécessaire de déterminer le type de processus et les types de ressources autorisés avant de décider s’il faut autoriser l’accès à une ressource. L’espace actif du procédé peut également être compressé au minimum.
Même un processus de service fonctionnant en root n’a généralement accès qu’aux ressources dont il a besoin. Même si un programme est vulnérable, l’ampleur de l’impact est limitée aux ressources auxquelles il est autorisé. La sécurité est grandement renforcée.
Le corps principal de ce mécanisme de gestion des permissions est le processus, également appelé contrôle d’accès obligatoire (MAC).
Le MAC est subdivisé en deux modes : l’un s’appelle le mode Sécurité de Catégorie (MCS), l’autre le mode Sécurité Multi-Niveau (MLS).
Les actions suivantes sont en mode MCS.
2.4 Comparaison entre DAC et MAC
Voici une image pour illustrer.
Comme vous pouvez le voir, en mode DAC, tant que le répertoire correspondant a les permissions de l’utilisateur correspondant, il est accessible à lui. En mode MAC, il est également limité par la gamme d’annuaires auxquels les processus peuvent accéder.
3. Concepts de base de SELinux
3.1 Sujet
Cela peut être complètement assimilé à un processus.
Note : Pour faciliter la compréhension, sauf indication contraire, le processus est considéré comme l’élément principal ci-dessus.
3.2 Objectif
Ressources accessibles par le directeur. Cela peut être des fichiers, des répertoires, des ports, des périphériques, etc.
Note : Pour faciliter la compréhension, sauf indication contraire, les documents ou annuaires suivants sont considérés comme des objets.
3.3 Politique et Règle
Il y a généralement un grand nombre de fichiers et de processus dans le système, et afin d’économiser du temps et de la surcharge, nous ne régulons généralement que certains processus de manière sélective.
Et quels processus doivent être réglementés et comment les contrôler dépendent de la politique.
Il y a plusieurs règles dans une police. Certaines règles peuvent être activées ou désactivées selon les besoins (ci-après désignées sous le nom de règles booléennes).
Les règles sont modulaires et extensibles. Lors de l’installation d’une nouvelle application, celle-ci peut ajouter des règles en ajoutant de nouveaux modules. Les utilisateurs peuvent également ajouter ou soustraire manuellement des règles.
Dans le système CentOS 7, il existe trois ensembles de politiques, à savoir :
1. ciblé : Contrôle la plupart des processus de service réseau. C’est la politique utilisée par défaut par le système (toutes les applications ci-dessous sont utilisées).
2. Minimum : Sur la base du ciblage, seuls certains processus de service réseau sont réglementés. En général, non.
3. MLS : Protection de sécurité à plusieurs niveaux. Régulez tous les processus. C’est la politique la plus stricte, et la configuration est très difficile. En général, elle n’est utilisée que si des exigences de sécurité extrêmement strictes.
Les politiques peuvent être définies dans /etc/selinux/config.
3.4 Contexte de sécurité
Le contexte de sécurité est au cœur de SELinux.
Contexte de sécurité, je le divise en « contexte de sécurité des processus » et « contexte de sécurité des documents ».
Un contexte de sécurité de processus correspond généralement à plusieurs contextes de sécurité documentaire.
Ce n’est que lorsque le contexte de sécurité des deux correspond qu’un processus peut accéder au fichier. Leur correspondance est déterminée par les règles de la police.
Le contexte de sécurité des fichiers est déterminé par l’endroit où le fichier a été créé et le processus qui l’a créé. Et le système dispose d’un ensemble de valeurs par défaut, et les utilisateurs peuvent aussi définir ces valeurs par défaut.
Il est important de noter que simplement déplacer des fichiers ne modifie pas le contexte de sécurité de vos fichiers.
La structure et la signification du contexte de sécurité
Le contexte de sécurité comporte quatre champs, séparés par des deux-points. Forme telle que : system_u :object_r :admin_home_t :s0.
3.5 Mode de fonctionnement SELinux
SELinux propose trois modes de fonctionnement, à savoir :
1. application : mode appliqué. Les infractions aux règles de SELinux seront bloquées et enregistrées dans les logs.
2. Permissif : mode tolérance. Les violations des règles SELinux ne sont enregistrées que dans les journaux. Généralement pour le débogage.
3. désactivé : Désactivez SELinux.
Le mode de fonctionnement SELinux peut être configuré dans /etc/selinux/config.
Si vous souhaitez passer de « handicapé » à « application » ou permissif, vous devrez redémarrer le système. Et inversement.
Les modes d’imposition et de permissif peuvent être rapidement inversés avec la commande Setenforce 1|0.
Il est important de noter que si le système a fonctionné avec SELinux éteint pendant un certain temps, le premier redémarrage après l’activation de SELinux peut être plus lent. Parce que le système doit créer un contexte sûr pour les fichiers sur le disque (j’ai dit que j’avais redémarré pendant environ 10 minutes et que je pensais que c’était mort...... ）。
Les journaux SELinux doivent être enregistrés avec l’aide d’auditd.service, merci de ne pas le désactiver.
3.6 Flux de travail SELinux
Voici une citation tirée d’une photo, sans beaucoup d’explications.
Note : Le texte de sécurité ci-dessus fait référence au contexte de sécurité.
4. Opérations de base de SELinux
4.1 Interroger le contexte de sécurité d’un fichier ou d’un répertoire
Usage de base par commande
ls -Z
Exemples d’utilisation
Interrogez le contexte de sécurité de /etc/hosts.
ls -Z /etc/hosts
Résultats d’exécution
-rw-r--r--. racine racine system_u :object_r :net_conf_t :s0 /etc/hosts
4.2 Interroger le contexte de sécurité du processus
Usage de base par commande
ps auxZ | grep -v grep | grep
Exemples d’utilisation
Interrogez le contexte de sécurité des processus liés à Nginx.
ps auxZ | grep -v grep | Grep Nginx
Résultats d’exécution
system_u :system_r :httpd_t :s0 racine 7997 0,0 0,0 122784 2156 ? Ss 14:31 0:00 nginx : master process /usr/sbin/nginx
system_u :system_r :httpd_t :s0 nginx 7998 0.0 0.0 125332 7560 ? S 14:31 0:00 nginx : processus de travail
4.3 Modifier manuellement le contexte de sécurité d’un fichier ou d’un répertoire
Usage de base par commande
CHCON [...]
Fonction option -u Modifier le champ utilisateur du contexte de sécurité -r Modifier le champ de rôle du contexte de sécurité -t Modifier le champ type du contexte de sécurité -l Modifier le champ de niveau du contexte de sécurité --référence Modifier le contexte de sécurité cohérent avec le fichier ou répertoire spécifié -R Opération récursive -h Modifier le contexte de sécurité du lien souple (modifier le fichier correspondant du lien souple sans cette option)
Exemples d’utilisation
Modifiez le contexte de sécurité du test en aaa_u :bbb_r :ccc_t :s0.
CHCON -U aaa_u -R bbb_r -T ccc_t test
4.4 Restaurer le contexte de sécurité d’un fichier ou d’un répertoire à sa valeur par défaut
Usage de base par commande
RestoreCon [Options] [...]
Fonction d’option - V Procédure d’opération d’impression - Opération récursive R
Exemples d’utilisation
Après avoir ajouté quelques fichiers web au répertoire de votre serveur Nginx, définissez le bon contexte de sécurité pour ces nouveaux fichiers.
restorecon -R /usr/share/nginx/html/
4.5 Requête des règles booléennes et leur statut dans le système
Usage de base par commande
getsebool -a
Comme la commande interroge soit toutes les règles, soit une seule règle, elle interroge généralement toutes les règles en premier puis filtre avec grep.
Exemples d’utilisation
Interrogez les règles booléennes liées à httpd.
getsebool -a | grep httpd
Résultats d’exécution
httpd_anon_write -->
httpd_builtin_scripting -->
httpd_can_check_spam -->
httpd_can_connect_ftp --> éteint
#以下省略
4.6 Changer une règle booléenne
Usage de base par commande
setsebool [option]
Fonction option -P redémarrage est toujours en vigueur
Exemples d’utilisation
Activez httpd_anon_write règles.
setsebool -P httpd_anon_write on
4.7 Ajouter un contexte de sécurité par défaut pour un annuaire
Usage de base par commande
semanage fcontext -a -t « (/.*) ? »
Note : Le contexte de sécurité par défaut d’un répertoire ou d’un fichier peut être consulté en utilisant la commande semanage fcontext -l en conjonction avec le filtrage grep.
Exemples d’utilisation
Après avoir ajouté un nouveau répertoire du site /usr/share/nginx/html2 à Nginx, vous devez définir le même contexte de sécurité par défaut que le répertoire original.
semanage fcontext -a -t httpd_sys_content_t « /usr/share/nginx/html2(/.*) ? »
4.8 Ajouter des ports autorisés par certains types de processus
Usage de base par commande
Port SEMANAGE -A -T -P
Note : Les numéros de port autorisés pour différents types de services peuvent être consultés en utilisant la commande semanage port -l avec filtrage grep.
Exemples d’utilisation
Pour Nginx, il faut utiliser le port 10080 pour les services HTTP.
SeManage Port -A -T http_port_t -P TCP 10080
5. Analyse et résolution des erreurs SELinux
5.1 Comprendre les journaux SELinux
Lorsque SELinux est activé, certains comportements normaux de nombreux services sont considérés comme une violation (à la fois dans le titre et dans les erreurs ci-dessous).
À ce stade, nous devons utiliser les journaux de violations SELinux pour les analyser et les résoudre.
Les journaux de violations SELinux sont enregistrés dans /var/log/audit/audit.log.
/var/log/audit/audit.log 的内容大概是这样的。
type=LOGIN msg=audit(1507898701.391:515) : pid=8523 uid=0 subj=system_u :system_r :crond_t :s0-s0 :c0.c1023 old-auid=4294967295 auid=0 tty=(none) old-ses=4294967295 ses=25 res=1
type=USER_START msg=audit(1507898701.421:516) : PID=8523 UID=0 AUID=0 SES=25 SUBJ=system_u :system_r :crond_t :S0-S0 :C0.C1023 MSG='op=PAM :session_open grantors=pam_loginuid,pam_ keyinit,pam_limits,pam_systemd acct="root » exe="/usr/sbin/crond » hostname= ? addr= ? terminal=cron res=succès'
...
Le fichier contient beaucoup de contenu, et il est mélangé à beaucoup de journaux d’audit système qui n’ont rien à voir avec les erreurs de SELinux. Nous utiliserons l’utilitaire sealert pour aider à l’analyse (si l’invite ne trouve pas la commande, installez le package setroubleshoot).
5.2 Analyser les erreurs avec SeAlert
Usage de base par commande
SeAlert -A /var/log/audit/audit.log
Après avoir exécuté la commande, le système doit prendre un certain temps pour analyser les violations dans les journaux et fournir un rapport d’analyse. |
Publié sur 05/07/2019 11:25:50
|
|
|
|
Propriétaire|
Publié sur 22/07/2021 17:17:58
|
