Cette série d'articles explorera certaines de mes fonctionnalités préférées de Red Hat Enterprise Linux (RHEL) 8 qui sont activées par systemd . Ainsi, cette série suppose une familiarité avec les concepts de base de systemd . Si vous avez besoin d'une bonne introduction, il existe une mine de documentation sur le produit sur le portail client Red Hat ainsi que sur le site du projet. Alternativement, il existe un certain nombre de présentations disponibles sur YouTube pour vous rattraper également avant de continuer.
Systemd fournit un nombre important de fonctionnalités de sécurité qui peuvent être utilisées pour isoler les services et les applications les uns des autres ainsi que du système d'exploitation sous-jacent. Dans de nombreux cas, systemd fournit un accès facile aux mêmes mécanismes fournis par le noyau Linux qui sont également utilisés pour créer une isolation pour les conteneurs Linux. Avoir la capacité de fournir une isolation de type conteneur pour les applications et services traditionnels est puissant car il est désormais facile d'améliorer la sécurité et l'isolation des charges de travail sans l'impact opérationnel que les conteneurs exigent. Il convient de noter que les changements opérationnels et organisationnels inspirés par l'adoption des conteneurs sont en effet sains et utiles. Cependant, même dans l'entreprise la plus avertie en matière de conteneurs, il existe un grand nombre de déploiements Linux traditionnels où la sécurité est une priorité absolue. Comme nous le verrons, les charges de travail sur ces systèmes peuvent bénéficier de quelques ajustements apportés aux fichiers d'unité correspondants.
Options de sécurité communes à Red Hat Enterprise Linux 7 et 8
La majorité des options explorées ci-dessous acceptent un true binaire ou false configuration qui les rend faciles à activer. Il y en a quelques-uns qui contiennent des options supplémentaires, et les plus importantes d'entre elles sont également affichées. Reportez-vous à la documentation complète et aux pages de manuel pour plus de détails. Si vous ne vous souciez pas du détail de ces options, n'hésitez pas à passer à la section suivante où nous regrouperons ces options pour des exemples plus cohérents :
| Option | Description |
|---|---|
PrivateTmp=yes | Crée un espace de noms de système de fichiers sous /tmp/systemd-private-*-[unit name]-*/tmp plutôt qu'un /tmp partagé ou /var/tmp . De nombreux fichiers d'unité livrés avec Red Hat Enterprise Linux incluent ce paramètre et il supprime toute une classe de vulnérabilités autour de la prédiction et du remplacement des fichiers utilisés dans /tmp . |
PrivateNetwork= | Fournit un espace de noms réseau pour le service avec uniquement une interface de bouclage disponible. Une excellente option pour les applications qui ne nécessitent pas de communication réseau externe. |
SELinuxContext= | Exécute l'application dans un contexte spécifique. Cette option est une bonne idée pour définir quand une stratégie est disponible pour les applications livrées en dehors de RHEL. Une bonne introduction à SELinux est disponible ici. |
NoNewPrivileges= | Empêche le service et les processus enfants associés d'augmenter les privilèges. |
ProtectSystem=yes | Fait /usr et /boot en lecture seule à l'application. Définir cette option sur full fait aussi /etc lecture seulement. Dans Red Hat Enterprise Linux 8, il existe une option supplémentaire appelée strict qui fait aussi /dev , /proc , et /sys en lecture seule. |
ProtectHome=yes | Rend /home , /root , et /run/user apparaissent vides. Une option supplémentaire est read-only , qui fait exactement ce qu'il dit. Également nouveau dans RHEL 8, tmpfs superposera un système de fichiers inscriptible et éphémère à ces points. Étant donné que ces répertoires sont utilisés pour stocker des clés SSH et d'autres informations potentiellement sensibles, il est judicieux d'interdire l'accès aux applications. |
ProtectDevices=yes | Crée un /dev privé espace de noms contenant uniquement des pseudo-périphériques comme /dev/null et /dev/random , qui ne donnent pas accès au matériel réel. Il désactive également CAP_MKNOD afin que de nouveaux nœuds de périphérique ne puissent pas être créés. |
CapabilityBoundingSet= | Accepte une liste blanche et une liste noire de capacités privilégiées pour l'unité. Les capacités de Linux décomposent l'accès de l'utilisateur racine au système afin que l'accès privilégié puisse être mieux identifié. L'exemple classique est pour NTP ou chrony pour pouvoir configurer l'horloge système mais n'entreprendre aucune autre action privilégiée. Plus de détails sont disponibles dans la page de manuel des capacités (7). |
|
| Se comporte de la même manière que ProtectSystem , mais ces trois options permettent un contrôle précis de l'accès au système de fichiers. |
Nouvelles options de sécurité dans Red Hat Enterprise Linux 8
Les nouvelles options de sécurité systemd disponibles dans Red Hat Enterprise Linux 8 sont :
| Option | Description |
|---|---|
ProtectKernelTunables=yes | Désactive la modification de /proc et /sys . |
ProtectKernelModules=yes | Interdit le chargement ou le déchargement des modules et des masques /usr/lib/modules depuis l'application. |
ProtectControlGroups=yes | Désactive l'accès en écriture à /sys/fs/cgroup/ . |
RestrictNamespaces= | Restreindre tout ou un sous-ensemble d'espaces de noms au service. Accepte cgroup , ipc , net , mnt , pid , user , et uts . |
AssertSecurity= | Prend un certain nombre d'exigences qui doivent être remplies par le système pour que le service démarre. Si les fonctionnalités répertoriées ne sont pas disponibles, le service ne s'exécute pas et l'événement est consigné. Des options comme selinux et uefi-secureboot sont utiles dans de nombreux environnements. |
MemoryDenyWriteExecute= | Désactive le mappage de la mémoire qui est simultanément inscriptible et exécutable. |
RestrictRealtime=yes | Interdit la planification en temps réel. |
PrivateMounts=yes | Entraîne l'exécution du service dans un espace de noms de montage privé. |
DynamicUser=yes | Crée efficacement un utilisateur transitoire pour l'application. Cette option justifie probablement son propre article à explorer, mais brièvement, le systemd l'implémentation est brillante car elle crée dynamiquement (comme son nom l'indique) un UID et un GID en branchant un nss module qui "crée" l'utilisateur à la volée. Ces utilisateurs n'existent tout simplement pas lorsque le service n'est pas en cours d'exécution. Cette fonctionnalité est particulièrement utile pour les applications sans état, mais les répertoires peuvent être mappés pour y écrire. |
SystemCallFilter= | Vous permet de mettre sur liste blanche et de mettre sur liste noire des appels système individuels ou d'utiliser les groupes d'appels conviviaux que systemd fournit. Si vous connaissez seccomp filtrage avec des conteneurs, cette option fournit exactement la même chose. De manière générale, la plupart des utilisateurs trouveront le @system-service filtre précieux, qui active les appels système pertinents nécessaires à la plupart des services. Les utilisateurs peuvent afficher la liste des groupes et des appels système disponibles en exécutant systemd-analyze syscall-filter . |
[Vous voulez essayer Red Hat Enterprise Linux ? Téléchargez-le maintenant gratuitement.]
Un exemple
Si vous êtes arrivé jusqu'ici, vous vous dites peut-être :« OK, ça a l'air vraiment puissant, mais c'est beaucoup de choses à retenir. Heureusement, depuis Red Hat Enterprise Linux 8.1, nous avons ajouté une commande pour faciliter la référence et la vérification de l'état de ces options :
systemd-analyze security [unit]
Cette commande génère un aperçu rapide de la façon dont le système exploite systemd et peut également afficher les paramètres individuels par unité. Cette conception facilite l'identification des options disponibles ainsi que la visualisation de leur utilisation à un niveau granulaire.
Voici la sortie du httpd.service par défaut unité :
Cette sortie de systemd-analyze security affiche le nom, une description pratique et une cote d'exposition, qui démontre la consommation des paramètres de sécurité disponibles par service et génère un score d'exposition pondéré en fonction de l'isolement du service. Il convient de noter que cet outil n'est pas destiné à fournir une vue ou une opinion holistique de la sécurité du code ou de l'application en cours d'exécution sur le système. Juste parce que httpd.service revient comme UNSAFE sur une installation par défaut ne signifie pas que le service n'est pas sécurisé.
Maintenant que nous savons comment interroger les unités et voir quels contrôles sont utilisés, examinons comment les appliquer à un simple serveur Web. Cet exemple général sert de point de départ facile pour d'autres services et applications.
Activer les options de sécurité
Tout d'abord, créez un drop-in systemd pour ajouter les options de sécurité. Pour Red Hat Enterprise Linux 8, exécutez :
# systemctl edit httpd
Ou, si vous préférez, créez manuellement /etc/systemd/system/httpd.service.d/security.conf .
Quelle que soit la manière dont vous avez accédé au fichier, ajoutez maintenant :
[Service]
ProtectSystem=strict
ProtectHome=yes
PrivateDevices=yes
ProtectKernelTunables=yes
ProtectKernelModules=yes
ProtectControlGroups=yes
SystemCallFilter=@system-service
SystemCallErrorNumber=EPERM
NoNewPrivileges=yes
PrivateTmp=yes
Pour Red Hat Enterprise Linux 7, nous pouvons utiliser un modèle similaire :
[Service]
ProtectSystem=full
ProtectHome=yes
PrivateDevices=yes
NoNewPrivileges=yes
PrivateTmp=yes
Une fois que vous avez enregistré le fichier et redémarré le service, le httpd service sera considérablement isolé du reste du système d'exploitation. Si jamais le service est compromis, le potentiel d'une évasion et des dommages qui en résultent est considérablement réduit.
Les exemples ci-dessus constituent un excellent point de départ pour verrouiller les services, les applications et les unités exécutées sur votre système. Vous devez bien sûr les tester pour vous assurer qu'ils conviennent à votre cas d'utilisation avant de les déployer sur l'ensemble de votre flotte. Par exemple, si nous voulions diffuser du contenu à partir des répertoires personnels des utilisateurs, nous n'inclurions pas ProtectHome=yes , mais à la place, utilisez ProtectHome=read-only . Il convient également de noter qu'il n'y a aucun mal à inclure les nouvelles options ajoutées dans RHEL 8 sur un fichier d'unité exécuté dans RHEL 7. Un message de notification sera émis et l'option sera ignorée.
Afficher les résultats
Nous pouvons maintenant afficher les options utilisées en exécutant systemd-analyze httpd :
Vous pouvez voir qu'un certain nombre d'options sont désormais appliquées sur le serveur Web. Le classement est également passé de UNSAFE à MEDIUM . Bien qu'il soit tout à fait possible d'activer plus d'options et de verrouiller davantage le service, nous nous écarterions de l'objectif de fournir un exemple pratique qui s'appliquera avec succès à de nombreux services et applications dans le monde réel. Il n'a jamais été aussi simple de limiter l'accès d'un service traditionnel au système d'exploitation sous-jacent.
Conclusion
Pour les développeurs intéressés par la sécurisation de votre propre logiciel, les options de sécurité pertinentes peuvent facilement être ajoutées au(x) fichier(s) d'unité inclus avec votre application. Red Hat encourage vivement les développeurs à "intégrer" autant de sécurité que possible par défaut, et c'est l'un des moyens les plus simples d'atteindre cet objectif.
Pour ceux qui se demandent si les fonctionnalités de sécurité présentées ici sont redondantes avec SELinux, il existe un chevauchement des fonctions, mais elles sont largement indépendantes. Ces paramètres s'appliqueront que SELinux soit utilisé ou non. Cette fonctionnalité est d'une grande valeur lorsque SELinux n'est pas une option viable en raison des exigences de politique ou d'application pour certains systèmes. Dans un monde idéal, ceux-ci seraient utilisés with SELinux dans le cadre d'une approche en couches de la sécurité.
J'espère que vous avez apprécié d'apprendre à quel point il est facile d'isoler et de mettre en bac à sable les charges de travail installées sur Red Hat Enterprise Linux 8 avec systemd . Maintenant, allez de l'avant et, le cas échéant, appliquez ces connaissances à l'ensemble de votre (vos) environnement(s). Dans le prochain article de cette série, nous verrons comment utiliser les groupes de contrôle Linux, alias cgroups , via systemd pour protéger les précieuses ressources système et résoudre le problème du "voisin bruyant".