SUSE a annoncé SLES 16.0 le 4 novembre 2025, SELinux remplaçant AppArmor comme framework de contrôle d'accès obligatoire par défaut. Si votre serveur exécute SLES 16, ne présumez pas qu'AppArmor est installé ou actif : vérifiez le framework pris en charge par votre déploiement avant d'utiliser ces commandes. La procédure ci-dessous suit la documentation SUSE relative à AppArmor pour SLES 15 SP7, où AppArmor est installé et actif par défaut.
Sur SLES 15 SP7, la méthode pratique pour une application personnalisée consiste à aa-genprofcréer un profil initial, à exécuter l'application en mode de test, à examiner chaque requête enregistrée, puis à vérifier que le profil est bien appliqué. L'exemple utilise un exécutable hypothétique situé à l'emplacement indiqué/usr/local/bin/report-worker ; remplacez-le par le chemin d'accès réel de votre application.
Les profils AppArmor sont des politiques textuelles stockées sous /etc/apparmor.d. Le apparmor-utilspaquet fournit les outils de profilage. Vérifiez l'hôte et identifiez l'exécutable, notamment s'il s'agit d'une unité systemd lançant un processus wrapper ou enfant :
sudo aa-status
command -v aa-genprof
systemctl status apparmor
readlink -f /usr/local/bin/report-worker
SUSE indique qu'AppArmor est activé par défaut sur les installations SLES 15. Si les outils ou le modèle AppArmor complet sont manquants, installez-les sudo zypper in -t pattern apparmor. Si AppArmor n'est pas actif, identifiez la cause du problème avant de procéder au profilage, plutôt que de supposer qu'un fichier de profil suffit à assurer la protection. Un profil est associé au chemin d'accès d'un exécutable ; profiler un wrapper alors que la charge de travail réelle s'exécute dans un autre binaire peut laisser le processus critique sans confinement.
Démarrez le générateur. Arrêtez l'application si elle est déjà en cours d'exécution, puis lancez la génération du profil :
sudo systemctl stop report-worker
sudo aa-genprof /usr/local/bin/report-worker
Le nom du service est donné à titre d'exemple. Utilisez le nom réel de l'unité ou omettez la commande d'arrêt si le programme n'est pas en cours d'exécution. aa-genprofUn profil approximatif est créé lorsqu'il n'en existe pas, le place en mode d'apprentissage (avertissement), le recharge et consigne les informations dans le journal. Le mode d'apprentissage enregistre les requêtes non conformes à la politique, mais les autorise ; il s'agit d'un état d'apprentissage temporaire, et non d'une action coercitive.
Mettez en pratique le comportement réel de l'application. Laissez le générateur ouvert. Dans un autre terminal, démarrez le service et exécutez des tâches ou des fonctionnalités représentatives :
sudo systemctl start report-worker
sudo journalctl -f
Couvrez le démarrage normal, les flux d'entrée/sortie attendus, les tâches planifiées, la gestion des erreurs et tous les programmes auxiliaires lancés par l'application. Un profil ne peut analyser que les requêtes générées pendant le test. N'utilisez pas de charges de travail critiques pour la production uniquement pour générer des événements ; un environnement de test sécurisé et des données de test représentatives sont préférables.
Examinez chaque demande d'accès. Revenez à la plage de journal marquée aa-genprofet appuyez Ssur la touche correspondante. Pour chaque invite, déterminez si l'application a réellement besoin de ce fichier, de cette capacité ou de cette transition de programme enfant. Autorisez le chemin et les permissions les plus restreints et utiles. Acceptez une abstraction lorsqu'elle couvre précisément une tâche courante ; utilisez un modèle générique uniquement lorsque les fichiers correspondants partagent les mêmes exigences de confiance et d'accès. Refusez ou ignorez les demandes accessoires ou inexpliquées.
Portez une attention particulière aux requêtes d'exécution. Une transition non confinée peut permettre à un processus enfant d'échapper à la politique du processus parent ; n'y recourez que lorsqu'il existe un besoin de conception justifié. Répétez l'exercice et le cycle d'analyse après avoir ajouté des règles légitimes. Lorsque le profil couvre le comportement testé, terminez le générateur. SUSE indique que la fin d'un nouveau aa-genprofcycle d'apprentissage place généralement le profil en mode d'application.
Examinez la politique générée. Dans cet exemple, la convention de nommage de SUSE convertit les barres obliques en points dans le chemin de l'exécutable, ce qui donne : /etc/apparmor.d/usr.local.bin.report-worker. Analysez le résultat au lieu de considérer les règles générées comme automatiquement sûres.
sudo less /etc/apparmor.d/usr.local.bin.report-worker
Vérifiez que le profil nomme l'exécutable prévu, utilise les fichiers d'en-tête requis et n'accorde l'accès qu'à la configuration, aux données, aux journaux, aux sockets et aux programmes auxiliaires dont l'application a réellement besoin. Évitez les règles trop générales, comme un accès illimité /ou l'accès à l'intégralité de l'arborescence en écriture, simplement pour masquer un refus d'accès. L'application reste soumise aux droits d'accès et de propriété Unix classiques ; AppArmor ajoute une couche de restriction supplémentaire.
Définissez explicitement le mode souhaité. Après vérification, appliquez le profil au programme personnalisé :
sudo aa-enforce /usr/local/bin/report-worker
Si vous avez modifié le profil manuellement après l'arrêt du générateur, rechargez l'ensemble de profils sudo systemctl reload apparmor. La documentation SUSE indique que ce rechargement implique une nouvelle analyse des profils sans libérer les processus en cours d'exécution. Redémarrez le service de l'application pour que la nouvelle stratégie s'applique à son processus.
Exécutez à nouveau les mêmes tâches représentatives en mode d'application du profil. Vérifiez que le service démarre, lit ses entrées prévues, écrit sa sortie attendue et peut effectuer les opérations auxiliaires ou réseau requises. Examinez ensuite l'état du profil et les messages récents du noyau.
sudo aa-status
sudo journalctl -k -g apparmor --since today
L'exécutable personnalisé doit apparaître comme chargé et en mode d'application. Les refus d'AppArmor dans le journal du noyau identifient les requêtes bloquées par la politique ; utilisez-les pour diagnostiquer une véritable défaillance de l'application, et non pour autoriser tous les chemins enregistrés. En cas d'autorisation manquante légitime, exécutez la commande sudo aa-logprof, examinez la suggestion, modifiez la règle de manière ciblée, rechargez si vous l'avez modifiée manuellement, puis relancez l'application concernée.
Pour un service fonctionnant en continu et dont le profilage doit s'étendre sur plusieurs redémarrages ou une période d'observation prolongée, SUSE propose un flux de travail systémique distinct utilisant aa-autodepdes analyses aa-complainrépétées aa-logprof. La méthode autonome aa-genprofest plus simple lorsque l'environnement d'apprentissage peut rester ouvert pendant toute la durée du test. Aucun de ces flux de travail ne permet de déduire un comportement de l'application qui n'a jamais été observé ; il est donc important de surveiller le profil lors de toute modification logicielle ou de configuration.
Configurez le chemin de mise à jour en direct approprié pour SLES 16.0 ou 15 SP7, appliquez les correctifs de noyau éligibles et confirmez ce qui est actif sans le confondre avec une mise à jour de noyau nécessitant un redémarrage.
SLES 15 SP5 peut être migré en ligne vers SP6, mais chaque nœud doit être redémarré. Utilisez une mise à niveau progressive éprouvée ou une bascule bleue-verte pour garantir la disponibilité des charges de travail.
Créer, affiner et vérifier un profil AppArmor à privilèges minimaux sur SLES 15 SP7, avec une note claire sur la valeur par défaut de SELinux de SLES 16.
Utilisez le profil STIG pris en charge par SUSE pour analyser SLES 15, tester la correction, examiner les résultats restants et conserver les preuves d'évaluation.
Tracez une connexion Cockpit défaillante via DNS, port 9090, socket systemd, firewalld, TLS et paramètres de connexion en utilisant les instructions SUSE actuelles.
Créez une connexion Ethernet redondante sur SLES 15 avec YaST et Wicked, configurez l'agrégation active-sauvegarde et vérifiez les deux ports et le basculement.
Transformez un système SLES 15 existant en un profil AutoYaST vérifié, validez-le et utilisez-le pour déployer un serveur de test avec moins d'étapes manuelles.
Installez les outils SLES 15 KVM et libvirt, activez le service hôte approprié et configurez les machines virtuelles sélectionnées pour qu'elles démarrent après un redémarrage.
Utilisez les tâches systemd et le journal de démarrage précédent pour localiser un service, un montage ou une dépendance de stockage lents, puis corrigez-les sans masquer la cause.
Utilisez firewall-cmd pour inspecter la zone active, autoriser HTTP en toute sécurité, préserver l'accès SSH et vérifier que la règle survit à un rechargement sur SLES 15.
