😸 🚴🏿 👨🏿‍⚖️ Systèmes de sécurité Linux ➰ ⚒️ 🈳

L'une des raisons de l'énorme succès du système d'exploitation Linux sur les appareils mobiles et les serveurs embarqués est le haut degré de sécurité du noyau, des services et applications associés. Mais si vous regardez de près l'architecture du noyau Linux, vous ne pouvez pas y trouver de boîte responsable de la sécurité en tant que telle. Où se cache le sous-système de sécurité Linux et en quoi consiste-t-il?

Contexte des modules de sécurité Linux et SELinux

Security Enhanced Linux est un ensemble de règles et un mécanisme d'accès basés sur des modèles d'accès obligatoires et basés sur les rôles pour protéger les systèmes Linux des menaces potentielles et corriger les failles du Discretionary Access Control (DAC), le système de sécurité Unix traditionnel. Le projet est né dans les entrailles de la National Security Agency des États-Unis, principalement des entrepreneurs Secure Computing Corporation et MITRE, ainsi que plusieurs laboratoires de recherche, ont été directement impliqués dans le développement.

Modules de sécurité Linux

Linus Torvalds a fait un certain nombre de commentaires sur les nouveaux développements NSA afin qu'ils puissent être inclus dans le noyau Linux en amont. Il a décrit un environnement général, avec un ensemble d'intercepteurs pour gérer les opérations avec des objets et un ensemble de certains 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 implémenter n'importe quel modèle de sécurité souhaité. LSM a été entièrement incorporé dans le noyau Linux v2.6 en 2003.

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

Le sous-système LSM a permis une intégration SELinux complète du même noyau Linux stable v2.6. Presque immédiatement, SELinux est devenu le standard de facto pour les environnements Linux sécurisés et est devenu une partie des distributions les plus populaires: RedHat Enterprise Linux, Fedora, Debian, Ubuntu.

Glossaire SELinux

— SELinux , Unix/Linux user id, , . Linux SELinux. SELinux , , — .
— SELinux , . . . , . — , . : sysadm_t , user_t, . init init_t, named named_t.
— , SELinux. , . . Role Based Access Control (RBAC), SELinux.
— Type Enforcement, , . , , , , , , . .
— , . : , , ., , , — .
SELinux — SELinux . SELinux , — — . , . .

LSM SELinux

Malgré leur nom, les LSM ne sont généralement pas des modules chargeables sous Linux. Cependant, tout comme SELinux, il est directement intégré dans le noyau. Toute modification du code source LSM nécessite une nouvelle compilation du noyau. L'option correspondante doit être activée dans les paramètres du noyau, sinon le code LSM ne sera pas activé après le démarrage. Même ainsi, il peut être activé avec l'option du chargeur de démarrage du système d'exploitation.

Pile de contrôle

LSM Le LSM est équipé de crochets dans les fonctions principales de base qui peuvent être pertinentes pour les contrôles. L'une des principales caractéristiques des LSM est qu'ils sont empilés. Ainsi, les vérifications standard sont toujours effectuées et chaque couche LSM ajoute uniquement des commandes et des commandes supplémentaires. Cela signifie que l'interdiction ne peut pas être annulée. Ceci est montré dans la figure, si le résultat des contrôles DAC de routine est un échec, alors il n'atteindra même pas les hooks LSM.

SELinux a adopté 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 son nom l'indique, est d'accorder à un utilisateur ou à un traitement uniquement les droits nécessaires pour exécuter les actions prévues. Ce principe est implémenté en utilisant un typage d'accès forcé, ainsi le contrôle d'admission SELinux est basé sur le modèle de type domain =>.

En raison de la saisie forcée de l'accès, SELinux a des capacités de contrôle d'accès beaucoup plus importantes que le modèle DAC traditionnel utilisé dans le système d'exploitation Unix / Linux. Par exemple, vous pouvez limiter le numéro de port réseau qui arrivera au serveur ftp, autoriser l'écriture et la modification de fichiers dans un dossier spécifique, mais ne pas les supprimer.

Les principaux composants de SELinux sont:

Policy Enforcement Server - Le principal mécanisme d'organisation du contrôle d'accès.
Base de données des politiques de sécurité du système.
Interaction avec l'intercepteur d'événements LSM.
Selinuxfs - Pseudo-FS, identique à / proc et monté dans / sys / fs / selinux. Rempli dynamiquement par le noyau Linux lors de l'exécution et contient des fichiers contenant des informations sur l'état de SELinux.
Accédez à Vector Cache - Performance Helper.

Comment fonctionne SELinux

Tout cela fonctionne comme suit.

Un certain sujet, en termes SELinux, effectue une action autorisée sur un objet après une vérification DAC, comme indiqué dans l'image du haut. Cette demande d'exécution de l'opération est envoyée à l'intercepteur d'événements LSM.
À partir de là, la demande, ainsi que le contexte de sécurité du sujet et de l'objet, est transmise au module SELinux Abstraction and Hook Logic, qui est responsable de l'interaction avec le LSM.
Le serveur Policy Enforcement Server est l'instance pour décider de l'accès du sujet à l'objet, et les données de SELinux AnHL y parviennent.
Pour prendre une décision concernant l'accès ou le refus, le serveur d'application de stratégie consulte le sous-système de mise en cache des règles AVC (Access Vector Cache) les plus utilisées.
Si aucune solution pour la règle correspondante n'est trouvée dans le cache, la demande est transmise à la base de données de politique de sécurité.
Le résultat de la recherche à partir de la base de données et de l'AVC est renvoyé au serveur Policy Enforcement.
Si la stratégie trouvée est cohérente avec l'action demandée, l'opération est autorisée. Sinon, l'opération est interdite.

Gestion des paramètres SELinux

SELinux fonctionne dans l'un des trois modes suivants:

Application - Adhésion stricte aux politiques de sécurité.
Permissive - la violation des restrictions est autorisée, la marque correspondante est faite dans le journal.
Désactivé - Les politiques de sécurité ne sont pas en vigueur.

Vous pouvez voir dans quel mode SELinux se trouve avec la commande suivante.

[admin@server ~]$ getenforce
Permissive

Changer le mode avant de redémarrer, par exemple, réglez-le sur enforcing, ou 1. Le paramètre permissif correspond au code numérique 0.

[admin@server ~]$ setenfoce enforcing
[admin@server ~]$ setenfoce 1 #

Vous pouvez également changer de mode en éditant 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 lorsque le système d'exploitation démarre, le mode SELinux sera défini en fonction de la valeur du paramètre SELINUX du fichier de configuration. De plus, les modifications apportées à l'application <=> désactivée ne prennent effet qu'en modifiant le fichier / etc / selinux / config et après un redémarrage.

Afficher un court rapport d'état:

[admin@server ~]$ sestatus

SELinux status: enabled
      

        
        
        
      

    
SELinuxfs mount: /sys/fs/selinux
      

        
        
        
      

    
SELinux root directory: /etc/selinux
      

        
        
        
      

    
Loaded policy name: targeted
      

        
        
        
      

    
Current mode: permissive
      

        
        
        
      

    
Mode from config file: enforcing
      

        
        
        
      

    
Policy MLS status: enabled
      

        
        
        
      

    
Policy deny_unknown status: allowed
      

        
        
        
      

    
Max kernel policy version: 31

Certains des utilitaires natifs utilisent le paramètre -Z pour afficher les attributs SELinux.

[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

Par rapport à la sortie habituelle de ls -l, il existe plusieurs champs supplémentaires au format suivant:

<user>:<role>:<type>:<level>

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

s0 - signification, également écrite comme intervalle de bas niveau à haut niveau
c0, c1… c1023 - catégorie.

Changement de configuration d'accès

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

[admin@server ~]$ semodule -l |wc -l #  
408
[admin@server ~]$ semodule -e abrt #enable -  
[admin@server ~]$ semodule -d accountsd #disable -  
[admin@server ~]$ semodule -r avahi #remove -

La première commande, la connexion semanage, lie l'utilisateur SELinux à l'utilisateur du système d'exploitation, la seconde le répertorie. Enfin, la dernière commande avec l'option -r supprime le mappage des utilisateurs SELinux vers les comptes OS. Une explication de la syntaxe des valeurs de plage MLS / MCS se trouve dans la section précédente.

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

Login Name SELinux User MLS/MCS Range 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

La commande semanage user est utilisée pour gérer les mappages entre les utilisateurs et les 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 une entrée de mappage de rôle personnalisée;
-l liste des correspondances entre utilisateurs et rôles;
-d supprime l'entrée de mappage de rôle définie par l'utilisateur;
-R liste des rôles attribués à l'utilisateur;

Fichiers, ports et booléens

Chaque module SELinux fournit un ensemble de règles pour marquer les fichiers, mais vous pouvez également ajouter vos propres règles si nécessaire. Par exemple, nous voulons que le serveur Web ait les 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 les nouvelles règles de marquage et la seconde réinitialise, ou plutôt définit, les types de fichiers conformément aux règles actuelles.

De même, les ports TCP / UDP sont marqués de sorte que seuls les services correspondants puissent les écouter. Par exemple, pour que le serveur Web écoute sur le port 8080, vous devez exécuter la commande.

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

Un nombre important de modules SELinux ont des paramètres qui peuvent prendre des valeurs booléennes. La liste complète de ces paramètres peut être vue avec getsebool -a. Les valeurs booléennes peuvent être modifiées avec 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

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

Prenons un exemple de la pratique, nous avons installé sur RHEL 7.6 pgadmin4-web pour l'administration de la base de données PostgreSQL. Nous avons parcouru une petite quête avec les paramètres pg_hba.conf, postgresql.conf et config_local.py, définir les droits sur les dossiers, installer les modules Python manquants de pip. Tout est prêt, exécutez-le et obtenez une erreur de serveur interne 500 .

En commençant par les suspects typiques, en vérifiant / var / log / httpd / error_log. Il y a là quelques entrées intéressantes. À ce stade, la plupart des administrateurs Linux seront tentés d'exécuter setencorce 0, et c'est tout. Franchement, la première fois que je l'ai fait. Ceci, bien sûr, est également une issue, mais loin d’être la meilleure.

[timestamp] [core:notice] [pid 23689] SELinux policy enabled; httpd running as context system_u:system_r:httpd_t:s0
      

        
        
        
      

    
...
      

        
        
        
      

    
[timestamp] [wsgi:error] [pid 23690] [Errno 13] Permission denied: '/var/lib/pgadmin'
      

        
        
        
      

    
[timestamp] [wsgi:error] [pid 23690]
      

        
        
        
      

    
[timestamp] [wsgi:error] [pid 23690] HINT : You may need to manually set the permissions on
      

        
        
        
      

    
[timestamp] [wsgi:error] [pid 23690] /var/lib/pgadmin to allow apache to write to it.

Malgré l'encombrement des constructions, SELinux peut être convivial. Il suffit d'installer le package setroubleshoot et d'afficher le journal système. Notez que le service auditd doit être redémarré de cette manière, et sans utiliser systemctl, malgré la présence de systemd dans le système d'exploitation. Le journal système indiquera non seulement le fait du blocage, mais également la raison et la manière de surmonter l'interdiction . Nous exécutons ces commandes: Nous vérifions l'accès à la page web pgadmin4-web, tout fonctionne.

[admin@server ~]$ yum install setroubleshoot
      

        
        
        
      

    
[admin@server ~]$ journalctl -b -0
      

        
        
        
      

    
[admin@server ~]$ service restart auditd

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

        
        
        
      

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

Systèmes de sécurité Linux