🥇Systèmes de protection Linux

L'une des raisons du succès phénoménal des systèmes d'exploitation Linux sur les appareils embarqués, mobiles et serveurs réside dans un niveau de sécurité des cœurs, des services associés et des applications assez élevé. Mais si l'on regarde de plus près l'architecture du noyau Linux, on ne peut pas y trouver un petit carré responsable de la sécurité en tant que tel. Où se cache alors le sous-système de sécurité Linux et de quoi est-il composé ?

Historique des Modules de Sécurité Linux et SELinux

Security Enhanced Linux est un ensemble de règles et de mécanismes d'accès, basé sur des modèles d'accès mandatoire et par rôle, destinés à protéger les systèmes Linux contre les menaces potentielles et à corriger les faiblesses du Discretionary Access Control (DAC) — le système de sécurité traditionnel de Unix. Le projet a vu le jour dans les coulisses de l'Agence de sécurité nationale des États-Unis, principalement développé par les contractants de Secure Computing Corporation et MITRE, ainsi que par plusieurs laboratoires de recherche.

Modules de Sécurité Linux

Linus Torvalds a formulé plusieurs remarques concernant les nouveaux développements de la NSA, afin qu'ils puissent être intégrés dans la branche principale du noyau Linux. Il a décrit un environnement général, avec un ensemble d'intercepteurs pour gérer les opérations sur les objets et un ensemble de champs de protection dans les structures de données du noyau pour stocker les attributs correspondants. Cet environnement peut ensuite être utilisé par des modules de noyau chargeables pour mettre en œuvre n'importe quel modèle de sécurité souhaité. LSM a été pleinement intégré dans le noyau Linux v2.6 en 2003.

Le framework LSM inclut des champs de protection dans les structures de données et des appels de fonctions d'interception à des points critiques du code du noyau pour les gérer et exécuter des contrôles d'accès. Il ajoute également des fonctions pour enregistrer des modules de sécurité. L'interface /sys/kernel/security/lsm contient une liste des modules actifs dans le système. Les hooks LSM sont stockés dans des listes, qui sont appelées dans l'ordre spécifié par CONFIG_LSM. Une documentation détaillée sur les hooks est incluse dans le fichier d'en-tête include/linux/lsm_hooks.h.

Le sous-système LSM a permis d'achever l'intégration complète de SELinux de la même version du noyau stable Linux v2.6. Très rapidement, SELinux est devenu le standard de facto d'un environnement sécurisé Linux et a été inclus dans les distributions les plus populaires : RedHat Enterprise Linux, Fedora, Debian, Ubuntu.

Glossaire SELinux

Identité — L'utilisateur SELinux n'est pas la même chose que l'identifiant d'utilisateur Unix/Linux que vous connaissez, ils peuvent coexister sur le même système, mais sont fondamentalement différents. Chaque compte standard Linux peut correspondre à un ou plusieurs dans SELinux. L'identité SELinux fait partie du contexte de sécurité global, qui détermine dans quels domaines on peut entrer et dans lesquels on ne peut pas.
Domaines — Dans SELinux, un domaine est le contexte d'exécution d'un sujet, c'est-à-dire d'un processus. Le domaine détermine directement l'accès dont dispose le processus. Un domaine est essentiellement une liste de ce que les processus peuvent faire ou des actions que le processus peut effectuer sur différents types. Quelques exemples de domaines : sysadm_t pour l'administration système, et user_t, qui est un domaine utilisateur ordinaire et non privilégié. Le système d'initialisation init s'exécute dans le domaine init_t, et le processus nommé s'exécute dans le domaine named_t.
Rôles — Ce qui fait le lien entre les domaines et les utilisateurs SELinux. Les rôles définissent dans quels domaines un utilisateur peut se trouver et quels types d'objets il pourra accéder. Ce mécanisme de séparation des accès prévient les menaces potentielles de montée en privilèges. Les rôles sont intégrés dans le modèle de sécurité basé sur les rôles (RBAC) utilisé dans SELinux.
Types — Un attribut de la liste Type Enforcement, qui est attribué à un objet et définit qui aura accès à celui-ci. Cela ressemble à la définition d'un domaine, sauf que le domaine s'applique à un processus, tandis que le type s'applique à des objets comme des répertoires, des fichiers, des sockets, etc.
Sujets et objets — Les processus sont des sujets et s'exécutent dans un contexte particulier, ou domaine de sécurité. Les ressources du système d'exploitation : fichiers, répertoires, sockets, etc., sont des objets auxquels est attribué un certain type, autrement dit — un niveau de confidentialité.
Politiques SELinux — Pour protéger le système, SELinux utilise une variété de politiques. La politique SELinux définit l'accès des utilisateurs aux rôles, des rôles aux domaines et des domaines aux types. Au départ, l'utilisateur est authentifié pour obtenir un rôle, ensuite le rôle est authentifié pour accéder aux domaines. Enfin, un domaine ne peut accéder qu'à certains types d'objets.

LSM et architecture SELinux

Bien que le nom LSM ne désigne pas vraiment des modules chargés de Linux, tout comme SELinux, il est directement intégré au noyau. Toute modification du code source LSM nécessite une recompilation du noyau. L'option correspondante doit être activée dans les paramètres du noyau, sinon le code LSM ne sera pas activé au démarrage. Mais même dans ce cas, il peut être activé par l'option du chargeur de démarrage du système d'exploitation.

Pile des vérifications LSM

LSM est doté de hooks dans les fonctions principales du noyau, qui peuvent être pertinents pour les vérifications. L'une des principales caractéristiques de LSM est qu'il est organisé selon le principe de la pile. Ainsi, les vérifications standard sont toujours effectuées, et chaque couche LSM n'ajoute que des éléments de contrôle et de gestion supplémentaires. Cela signifie que toute interdiction ne peut pas être annulée. Cela est illustré sur le schéma, si le résultat des vérifications DAC habituelles aboutit à un refus, il ne parviendra même pas aux hooks LSM.

SELinux a hérité de l'architecture de sécurité Flask du système d'exploitation de recherche Fluke, en particulier le principe du moindre privilège. L'essence de ce concept, comme le suggèrent ses nom, est de ne fournir à l'utilisateur ou au processus que les droits nécessaires à l'accomplissement des actions prévues. Ce principe est réalisé grâce à une typisation d'accès forcée, ainsi le contrôle des accès dans SELinux est basé sur le modèle domaine => type.

Grâce à la typisation d'accès forcée, SELinux dispose de capacités de séparation d'accès beaucoup plus importantes que le modèle DAC traditionnel utilisé dans les systèmes d'exploitation Unix/Linux. Par exemple, il est possible de restreindre le numéro de port réseau qu'un serveur FTP écoutera, de permettre l'écriture et les modifications des fichiers dans un dossier spécifique, mais pas leur suppression.

Les composants principaux de SELinux sont :

Serveur d'application de politique — Mécanisme principal de contrôle d'accès.
Base de données des politiques de sécurité du système.
Interaction avec le hook d'événements LSM.
Selinuxfs — Système de fichiers pseudo, similaire à /proc et monté dans /sys/fs/selinux. Il est rempli dynamiquement par le noyau Linux au moment de l'exécution et contient des fichiers contenant des informations sur l'état de SELinux.
Cache de vecteurs d'accès — Mécanisme auxiliaire d'amélioration de la performance.

Fonctionnement de SELinux

Tout cela fonctionne comme suit.

Un sujet, en termes de SELinux, effectue une action autorisée sur un objet après une vérification DAC, comme montré sur l'image du haut. Cette demande d'exécution d'opération est transmise au gestionnaire d'événements LSM.
De là, la demande, accompagnée du contexte de sécurité du sujet et de l'objet, est transmise au module SELinux Abstraction and Hook Logic, responsable de l'interaction avec LSM.
L'instance prenant la décision concernant l'accès du sujet à l'objet est le Serveur de Contrôle de Politique, et elle reçoit des données du SELinux AnHL.
Pour prendre une décision sur l'accès ou le refus, le Serveur de Contrôle de Politique se réfère au sous-système de mise en cache des règles les plus utilisées, l'Access Vector Cache (AVC).
Si la décision pour la règle correspondante n'est pas trouvée dans le cache, la demande est transmise à la base de données des politiques de sécurité.
Le résultat de la recherche dans la base de données et l'AVC est retourné au Serveur de Contrôle de Politique.
Si la politique trouvée correspond à l'action demandée, l'opération est autorisée. Sinon, l'opération est refusée.

Gestion des paramètres de SELinux

SELinux fonctionne dans l'un des trois modes :

Enforcing — Respect strict des politiques de sécurité.
Permissive — Les violations des restrictions sont autorisées, une note correspondante est enregistrée dans le journal.
Disabled — Les politiques de sécurité ne sont pas appliquées.

Pour voir dans quel mode se trouve SELinux, on peut utiliser la commande suivante.

[admin@server ~]$ getenforce
Permissive

Changement de mode jusqu'au redémarrage, par exemple passer en enforcing, ou 1. Le paramètre permissive correspond au code numérique 0.

[admin@server ~]$ setenfoce enforcing
[admin@server ~]$ setenfoce 1 #c'est la même chose

Le mode peut également être changé en modifiant le fichier :

[admin@server ~]$ cat /etc/selinux/config

# 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=enforcing # SELINUXTYPE= can take one of three values: # targeted - Targeted processes are protected, # minimum - Modification of targeted policy. Only selected processes are protected. # mls - Multi Level Security protection.
SELINUXTYPE=targete

La différence avec setenfoce est que lors du démarrage du système d'exploitation, le mode SELinux sera défini conformément à la valeur du paramètre SELINUX dans le fichier de configuration. De plus, les changements de enforcing disabled prennent effet uniquement par la modification du fichier /etc/selinux/config et après redémarrage.

Voir un rapport de statut succinct :

[admin@server ~]$ sestatus

Statut de SELinux : activé Montage de SELinuxfs : /sys/fs/selinux Répertoire racine de SELinux : /etc/selinux Nom de la politique chargée : ciblée Mode actuel : permissif Mode à partir du fichier de configuration : appliqué Statut de la politique MLS : activé Statut de la politique deny_unknown : autorisé Version maximale de la politique du noyau : 31
Pour consulter les attributs de SELinux, certaines utilitaires standard utilisent le paramètre -Z.

[admin@server ~]$ ls -lZ /var/log/httpd/
-rw-r--r--. root root system_u:object_r:httpd_log_t:s0 access_log
-rw-r--r--. root root system_u:object_r:httpd_log_t:s0 access_log-20200920
-rw-r--r--. root root system_u:object_r:httpd_log_t:s0 access_log-20200927
-rw-r--r--. root root system_u:object_r:httpd_log_t:s0 access_log-20201004
-rw-r--r--. root root system_u:object_r:httpd_log_t:s0 access_log-20201011
[admin@server ~]$ ps -u apache -Z
LABEL                             PID TTY          TIME CMD
system_u:system_r:httpd_t:s0     2914 ?        00:00:04 httpd
system_u:system_r:httpd_t:s0     2915 ?        00:00:00 httpd
system_u:system_r:httpd_t:s0     2916 ?        00:00:00 httpd
system_u:system_r:httpd_t:s0     2917 ?        00:00:00 httpd
...
system_u:system_r:httpd_t:s0     2918 ?        00:00:00 httpd

Comparé à la sortie ls -l habituelle, il y a ici plusieurs champs supplémentaires au format suivant :

:::

Le dernier champ désigne quelque chose comme un niveau de classification et consiste en une combinaison de deux éléments :

s0 — importance, noté aussi par un intervalle lowlevel-highlevel
c0, c1… c1023 — catégorie.

Modification des accès de configuration

Utilisez semodule pour charger des modules SELinux, les ajouter et les supprimer.

[admin@server ~]$ semodule -l | wc -l # liste de tous les modules
408
[admin@server ~]$ semodule -e abrt # enable - activer le module
[admin@server ~]$ semodule -d accountsd # disable - désactiver le module
[admin@server ~]$ semodule -r avahi # remove - supprimer le module

La première commande semanage login lie l'utilisateur SELinux à l'utilisateur du système d'exploitation, la deuxième commande affiche la liste. Enfin, la dernière commande avec l'option -r supprime le lien entre les utilisateurs SELinux et les comptes OS. L'explication de la syntaxe des valeurs MLS/MCS Range se trouve dans la section précédente.

[admin@server ~]$ semanage login -a -s user_u karol
[admin@server ~]$ semanage login -l

Nom d'utilisateur SELinux Plage d'utilisateur MLS/MCS Service __default__ unconfined_u s0-s0:c0.c1023 * root unconfined_u s0-s0:c0.c1023 * system_u system_u s0-s0:c0.c1023 * [admin@server ~]$ semanage login -d karol
Commande semanage user est utilisé pour gérer les associations entre utilisateurs et rôles SELinux.

[admin@server ~]$ semanage user -l
                Labeling   MLS/       MLS/
SELinux User    Prefix     MCS Level  MCS Range             SELinux Roles
guest_u         user       s0         s0                    guest_r
staff_u         staff      s0         s0-s0:c0.c1023        staff_r sysadm_r
...
user_u          user       s0         s0                    user_r
xguest_u        user       s0         s0                    xguest_r
[admin@server ~]$ semanage user -a -R 'staff_r user_r'
[admin@server ~]$ semanage user -d test_u

Paramètres de commande :

-a ajouter un enregistrement de correspondance utilisateur- rôle ;
-l liste des correspondances utilisateur et rôle ;
-d supprimer un enregistrement de correspondance utilisateur- rôle ;
-R liste des rôles attachés à l'utilisateur ;

Fichiers, ports et valeurs booléennes

Chaque module SELinux fournit un ensemble de règles de marquage des fichiers, mais il est également possible d'ajouter ses propres règles si nécessaire. Par exemple, nous souhaitons donner au serveur Web des droits d'accès au dossier /srv/www.

[admin@server ~]$ semanage fcontext -a -t httpd_sys_content_t "/srv/www(\/.*)?
[admin@server ~]$ restorecon -R /srv/www/

La première commande enregistre de nouvelles règles de marquage, et la seconde réinitialise, ou plutôt fixe, les types de fichiers en fonction des règles actuelles.

De même, les ports TCP/UDP sont marqués de manière à ce que seuls les services correspondants puissent les écouter. Par exemple, pour que le serveur Web puisse écouter le port 8080, il faut exécuter la commande.

[admin@server ~]$ semanage port -m -t http_port_t -p tcp 8080

Un nombre significatif de modules SELinux ont des paramètres qui peuvent prendre des valeurs booléennes. La liste complète de ces paramètres peut être consultée avec getsebool -a. Les valeurs booléennes peuvent être modifiées à l'aide de setsebool.

[admin@server ~]$ getsebool httpd_enable_cgi
httpd_enable_cgi --> on
[admin@server ~]$ setsebool -P httpd_enable_cgi off
[admin@server ~]$ getsebool httpd_enable_cgi
httpd_enable_homedirs --> off

Pratique, accéder à l'interface Pgadmin-web

Considérons un exemple pratique, nous avons installé sur RHEL 7.6 pgadmin4-web pour l'administration de la base de données PostgreSQL. Nous avons suivi un petit défi avec la configuration de pg_hba.conf, postgresql.conf et config_local.py, avons défini des droits sur les dossiers, installé via pip les modules Python manquants. Tout est prêt, nous lançons et obtenons erreur interne du serveur 500.

Nous commençons par les suspects habituels, vérifions /var/log/httpd/error_log. Il y a des entrées intéressantes.

[timestamp] [core:notice] [pid 23689] Politique SELinux activée ; httpd s'exécute avec le contexte system_u:system_r:httpd_t:s0 ... [timestamp] [wsgi:error] [pid 23690] [Errno 13] Permission refusée : ' /var/lib/pgadmin ' [timestamp] [wsgi:error] [pid 23690] [timestamp] [wsgi:error] [pid 23690] SUGGESTION : Vous devrez peut-être définir manuellement les autorisations sur [timestamp] [wsgi:error] [pid 23690] /var/lib/pgadmin pour permettre à apache d'y écrire.

À ce stade, la plupart des administrateurs Linux seront fortement tentés de lancer setenforce 0, et de terminer le problème. Pour être honnête, la première fois, j'ai fait exactement cela. C'est une solution, mais loin d'être la meilleure.

Malgré la complexité des constructions, SELinux peut être convivial. Il suffit d'installer le paquet setroubleshoot et de consulter le journal système.

[admin@server ~]$ yum install setroubleshoot [admin@server ~]$ journalctl -b -0 [admin@server ~]$ service restart auditd

Notez que le service auditd doit être redémarré de cette manière, et non avec systemctl, malgré la présence de systemd dans le système d'exploitation. Dans le journal système sera indiqué non seulement le fait d'un blocage, mais aussi la cause et la manière de contourner l'interdiction.

Exécutons ces commandes :

[admin@server ~]$ setsebool -P httpd_can_network_connect 1 [admin@server ~]$ setsebool -P httpd_can_network_connect_db 1

Vérifions l'accès à la page Web pgadmin4-web, tout fonctionne.

Source : habr.com