{"id":20268,"date":"2026-08-02T18:19:04","date_gmt":"2026-08-02T16:19:04","guid":{"rendered":"https:\/\/webhosting.de\/seccomp-linux-kernel-sicherheit-anwendungen-einschraenken-sandbox-guard\/"},"modified":"2026-08-02T18:19:04","modified_gmt":"2026-08-02T16:19:04","slug":"seccomp-noyau-linux-securite-restreindre-les-applications-sandbox-guard","status":"publish","type":"post","link":"https:\/\/webhosting.de\/fr\/seccomp-linux-kernel-sicherheit-anwendungen-einschraenken-sandbox-guard\/","title":{"rendered":"Seccomp sous Linux : restreindre de mani\u00e8re cibl\u00e9e les applications pour plus de s\u00e9curit\u00e9"},"content":{"rendered":"<p><strong>Seccomp Linux<\/strong> limite les applications aux appels syst\u00e8me dont elles ont r\u00e9ellement besoin, r\u00e9duisant ainsi consid\u00e9rablement la surface d'attaque du noyau. J'utilise ce m\u00e9canisme de mani\u00e8re cibl\u00e9e pour isoler les conteneurs, les microservices et les services sensibles dans un <strong>Sandbox<\/strong> les verrouiller sans bloquer leurs fonctions essentielles.<\/p>\n\n<h2>Points centraux<\/h2>\n\n<p>Je r\u00e9sume ici les aspects les plus importants pour offrir un aper\u00e7u rapide et j'explique comment j'utilise Seccomp dans la pratique. Cela permet une introduction claire aux politiques, aux filtres et \u00e0 la protection des charges de travail. Ces points me servent de fil conducteur pour la planification, l\u2019exploitation et la v\u00e9rification. Ils aident \u00e0 hi\u00e9rarchiser les risques et \u00e0 choisir des param\u00e8tres par d\u00e9faut adapt\u00e9s. En gardant ces \u00e9l\u00e9ments cl\u00e9s \u00e0 l\u2019esprit, la <strong>S\u00e9curit\u00e9<\/strong> compr\u00e9hensible et ma\u00eetrisable.<\/p>\n<ul>\n  <li><strong>Mode de filtrage<\/strong>: Les profils BPF \u00e0 granularit\u00e9 fine n'autorisent que les appels syst\u00e8me n\u00e9cessaires.<\/li>\n  <li><strong>Surface d'attaque<\/strong>: La r\u00e9duction du nombre de chemins d'acc\u00e8s au noyau accessible diminue le risque d'exploitation.<\/li>\n  <li><strong>Conteneur<\/strong>: Les profils par d\u00e9faut bloquent efficacement les appels \u00e0 risque.<\/li>\n  <li><strong>Kubernetes<\/strong>: \u00ab seccompProfile \u00bb et \u00ab seccompDefault \u00bb harmonisent la protection.<\/li>\n  <li><strong>Flux de travail<\/strong>: Analyser, d\u00e9finir le profil, renforcer, tester, d\u00e9ployer.<\/li>\n<\/ul>\n<p>J'analyse chaque charge de travail, je d\u00e9finis un profil adapt\u00e9 et je v\u00e9rifie son efficacit\u00e9 en conditions r\u00e9elles. C'est ainsi que l'on d\u00e9veloppe une solution robuste <strong>Ligne de base<\/strong>- une protection qui pourra \u00eatre \u00e9tendue de mani\u00e8re cibl\u00e9e ult\u00e9rieurement.<\/p>\n\n<h2>Seccomp en bref : mode de calcul s\u00e9curis\u00e9<\/h2>\n\n<p>Seccomp signifie \u201e Secure Computing Mode \u201c et limite <strong>Appels syst\u00e8me<\/strong> d'un processus \u00e0 un ensemble clairement d\u00e9fini. J'applique ce filtre l\u00e0 o\u00f9 les applications interagissent avec le noyau, par exemple lors de l'ouverture de fichiers, de sockets ou lors de la cr\u00e9ation d'autres processus. L\u2019id\u00e9e est simple : autoriser ce qui est n\u00e9cessaire et bloquer ce qui ne l\u2019est pas \u00e0 l\u2019aide d\u2019un code d\u2019erreur ou d\u2019une commande \u00ab kill \u00bb. Quiconque comprend l\u2019interaction avec le noyau peut rapidement cr\u00e9er des profils solides ; l\u2019article suivant constitue un bon point de d\u00e9part : <a href=\"https:\/\/webhosting.de\/fr\/comprendre-les-appels-systeme-communication-entre-le-noyau-et-les-applications-acces-controle\/\">Comprendre les appels syst\u00e8me<\/a>. C'est ainsi que l'on obtient une <strong>Sandbox<\/strong>, ce qui complique les \u00e9chappements et bloque les chemins d'acc\u00e8s ind\u00e9sirables au noyau.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linux-sicherheit-serverraum-8274.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Pourquoi Seccomp r\u00e9duit la surface d'attaque sous Linux<\/h2>\n\n<p>Chaque appel syst\u00e8me suppl\u00e9mentaire augmente potentiellement la <strong>Surface d'attaque<\/strong>. Je r\u00e9duis cette surface d'attaque en n'autorisant que les appels syst\u00e8me dont l'utilisation par l'application est av\u00e9r\u00e9e. De ce fait, de nombreuses cha\u00eenes d'exploitation perdent l'acc\u00e8s aux fonctions critiques du noyau. M\u00eame en cas d\u2019ex\u00e9cution de code au sein du processus, un attaquant se heurte souvent \u00e0 des portes closes. C\u2019est ainsi que j\u2019emp\u00eache l\u2019acc\u00e8s \u00e0 des sous-syst\u00e8mes sensibles tels que <strong>ptrace<\/strong>, BPF ou certaines interfaces de d\u00e9bogage.<\/p>\n\n<h2>Une liste blanche plut\u00f4t qu'une liste noire : la bonne strat\u00e9gie<\/h2>\n\n<p>Dans les environnements de production, je mise sur <strong>Liste blanche<\/strong>: L'action par d\u00e9faut est \u201e interdire \u201c, et seul un ensemble d'appels syst\u00e8me soigneusement s\u00e9lectionn\u00e9 est autoris\u00e9. Pour des raisons de compatibilit\u00e9, de nombreux environnements d'ex\u00e9cution fournissent des profils de listes noires qui ne bloquent que les appels particuli\u00e8rement risqu\u00e9s. Pour les services sensibles, je resserre la vis et n\u2019autorise que ce que l\u2019analyse d\u2019ex\u00e9cution montre r\u00e9ellement. Cela r\u00e9duit les surprises lors des modifications du noyau et fait passer le contr\u00f4le de la question \u201e Qu\u2019est-ce qui est dangereux ? \u201c \u00e0 celle de \u201e Qu\u2019est-ce qui est n\u00e9cessaire ? \u201c. Pour les charges de travail g\u00e9n\u00e9riques, une liste de blocage solide peut constituer un bon point de d\u00e9part, mais pour les passerelles, les flux de paiement ou les services d\u2019authentification, il vaut la peine de passer \u00e0 une politique de liste d\u2019autorisation avec des exceptions explicites.<\/p>\n\n<h2>Modes et logique de filtrage : de \u00ab strict \u00bb \u00e0 \u00ab BPF \u00bb<\/h2>\n\n<p>Seccomp dispose d'un mode strict qui n'autorise que les commandes read, write, exit et sigreturn, ainsi que le mode hautement flexible <strong>Mode de filtrage<\/strong> via BPF. Dans la pratique, j'utilise presque toujours des filtres, car cela me permet d'analyser en d\u00e9tail les appels syst\u00e8me et leurs arguments. Le noyau v\u00e9rifie chaque appel par rapport au programme enregistr\u00e9 et d\u00e9cide s\u2019il est autoris\u00e9, s\u2019il renvoie une erreur ou s\u2019il met fin au processus. Je peux ainsi bloquer certaines variantes d\u2019un appel syst\u00e8me, par exemple des indicateurs sp\u00e9cifiques de clone ou d\u2019unshare. Cette granularit\u00e9 permet <strong>Politiques<\/strong> \u00e0 la fois sobre et efficace.<\/p>\n\n<h2>Op\u00e9rations de restitution et niveau de contr\u00f4le<\/h2>\n\n<p>Je g\u00e8re de mani\u00e8re cibl\u00e9e le comportement en cas d'infractions \u00e0 l'aide d'actions : autoriser, erreurs d\u00e9finies (g\u00e9n\u00e9ralement <em>EPERM<\/em> ou <em>EACCES<\/em>) renvoyer, via <em>TRAP<\/em> d\u00e9clencher un signal, avec <em>TRACE<\/em> Activer le d\u00e9bogage ou mettre fin de mani\u00e8re syst\u00e9matique au processus\/thread. Le simple renvoi d'une erreur est souvent suffisant et am\u00e9liore la tol\u00e9rance aux pannes ; en revanche, pour les chemins particuli\u00e8rement sensibles, j'utilise des actions de force d'arr\u00eat. Lorsque j\u2019ai besoin d\u2019un diagnostic, j\u2019utilise la journalisation du noyau ou des actions avec journalisation pour affiner progressivement le profil dans les environnements de pr\u00e9production, sans perturber inutilement le fonctionnement.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/seccomp-security-linux-8943.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Le sandboxing et la protection par conteneurs dans la pratique<\/h2>\n\n<p>Les environnements d'ex\u00e9cution de conteneurs offrent des solutions \u00e9prouv\u00e9es <strong>D\u00e9faut<\/strong>- des profils qui bloquent les appels syst\u00e8me \u00e0 risque. Je pars de l\u00e0 pour restreindre davantage les fonctions `mount`, `unshare`, `bpf`, `ptrace`, ainsi que `keyctl` et `perf_event_open`. Les applications qui traitent des donn\u00e9es d\u2019entr\u00e9e non fiables en tirent un double avantage : une interface avec le noyau r\u00e9duite et des cas d\u2019erreur clairement identifiables en cas de violation. M\u00eame les navigateurs Web et les outils de sandbox s\u2019appuient sur cette s\u00e9paration entre les acc\u00e8s n\u00e9cessaires et ceux qui pr\u00e9sentent un danger. Ainsi, le syst\u00e8me d\u2019ex\u00e9cution reste g\u00e9rable et <strong>pr\u00e9visible<\/strong>.<\/p>\n\n<h2>Notification dans l'espace utilisateur : exceptions contr\u00f4l\u00e9es<\/h2>\n\n<p>Pour les exceptions rares, mais l\u00e9gitimes, j'utilise le <strong>Notificateur en espace utilisateur<\/strong>-Approche : un processus de surveillance re\u00e7oit les demandes concernant les appels syst\u00e8me bloqu\u00e9s et peut les autoriser ou les refuser de mani\u00e8re cibl\u00e9e. Je reproduis ainsi des mod\u00e8les de courtier, par exemple pour n'autoriser que certains <em>monter<\/em>- Autoriser les op\u00e9rations dans des r\u00e9pertoires d\u00e9finis. Cela r\u00e9duit la n\u00e9cessit\u00e9 d'int\u00e9grer des exceptions g\u00e9n\u00e9rales dans la politique, tout en pr\u00e9servant la flexibilit\u00e9 op\u00e9rationnelle. Une gouvernance claire est ici essentielle : quelles commandes sont autoris\u00e9es, comment sont-elles contr\u00f4l\u00e9es et comment \u00e9viter que le syst\u00e8me de notification ne devienne lui-m\u00eame un point de d\u00e9faillance unique ?<\/p>\n\n<h2>Seccomp dans Kubernetes et OpenShift<\/h2>\n\n<p>Dans Kubernetes, je d\u00e9finis dans le manifeste du pod, via le SecurityContext, quel profil est actif. Le profil \u00ab seccompDefault \u00bb sur le n\u0153ud garantit que les charges de travail pour lesquelles aucun profil n\u2019est sp\u00e9cifi\u00e9 se voient directement attribuer un profil appropri\u00e9. <strong>Standard<\/strong>-profil. OpenShift et Podman int\u00e8grent \u00e9galement cette fonctionnalit\u00e9, y compris le transfert via l'option \u2013security-opt. Je peux d\u00e9ployer les profils de mani\u00e8re centralis\u00e9e et les associer via une annotation ou un lien de champ. De cette mani\u00e8re, j'\u00e9tablis des r\u00e8gles claires pour l'ensemble des <strong>Espaces de nommage<\/strong> sur le sujet.<\/p>\n\n<h2>Conception de politiques pour les \u00e9quipes et les plateformes<\/h2>\n\n<p>Je classe les profils selon <em>Classes de charge de travail<\/em> plut\u00f4t que par \u00e9quipes : interfaces Web, workers, clients de base de donn\u00e9es, pipelines de donn\u00e9es. Chaque classe re\u00e7oit un profil test\u00e9, que je ne compl\u00e8te que tr\u00e8s l\u00e9g\u00e8rement pour les cas particuliers. Dans Kubernetes, j'utilise une politique d'admission pour m'assurer que les pods ont au moins <em>RuntimeDefault<\/em> utiliser, tandis que les espaces de noms particuli\u00e8rement sensibles n\u00e9cessitent une <em>Localhost<\/em>- Imposer le profil. Pour les situations de d\u00e9bogage ou d'incident, il existe une proc\u00e9dure d'exception clairement d\u00e9finie, assortie d'une dur\u00e9e de validit\u00e9 limit\u00e9e et d'une r\u00e9duction suppl\u00e9mentaire des capacit\u00e9s r\u00e9seau et des fonctionnalit\u00e9s, afin de permettre le diagnostic sans abaisser de mani\u00e8re g\u00e9n\u00e9rale le niveau de s\u00e9curit\u00e9.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linux-security-seccomp-shield-4092.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Cr\u00e9ation de profils : processus de l'analyse au d\u00e9ploiement<\/h2>\n\n<p>Je commence par une analyse des dur\u00e9es d'ex\u00e9cution et j'observe quelles <strong>Appels syst\u00e8me<\/strong> que l'application utilise en fonctionnement normal. Je d\u00e9finis ensuite un profil initial qui autorise pr\u00e9cis\u00e9ment ces appels et exclut les chemins d'acc\u00e8s peu fr\u00e9quents. Je proc\u00e8de ensuite \u00e0 un durcissement suppl\u00e9mentaire en supprimant les appels rares ou risqu\u00e9s, ou en les restreignant davantage. Une phase de test permet de d\u00e9tecter les lacunes et de d\u00e9terminer si des fonctionnalit\u00e9s manquent ou si des codes d'erreur sont pertinents. Ce n'est qu'ensuite que je d\u00e9ploie la <strong>Politique<\/strong> en production et je g\u00e8re les versions de chaque modification.<\/p>\n\n<h2>Aspects li\u00e9s \u00e0 l'architecture et au baccalaur\u00e9at<\/h2>\n\n<p>Les appels syst\u00e8me varient en fonction de l'architecture et de la g\u00e9n\u00e9ration du noyau. Je veille \u00e0 ce que les profils <strong>Multi-Arch<\/strong> couvrent bien toutes les architectures (par exemple x86_64 et arm64) et que les variantes plus r\u00e9centes telles que <em>openat2<\/em> ou si les appels syst\u00e8me time64 sont pris en compte. Dans les conteneurs utilisant des syst\u00e8mes de base plus anciens, je v\u00e9rifie si les chemins h\u00e9rit\u00e9s (par exemple via <em>socketcall<\/em> ou certains appels IPC). Ceux qui <em>libseccomp<\/em> ou utilise le runtime pour la g\u00e9n\u00e9ration, b\u00e9n\u00e9ficie de correspondances stables entre les noms de symboles et les num\u00e9ros d'appels syst\u00e8me \u2013 je renonce d\u00e9lib\u00e9r\u00e9ment \u00e0 utiliser des num\u00e9ros fixes afin de pr\u00e9server la portabilit\u00e9. Important : les filtres sont <strong>h\u00e9r\u00e9ditaire<\/strong> et seulement <em>monotone<\/em> pouvant \u00eatre renforc\u00e9 ; ce qui est interdit une fois le reste interdit, m\u00eame apr\u00e8s <em>execve<\/em>.<\/p>\n\n<h2>Gestion des mises \u00e0 niveau et de la compatibilit\u00e9<\/h2>\n\n<p>Les mises \u00e0 jour des biblioth\u00e8ques et du noyau introduisent de nouveaux appels syst\u00e8me ou modifient les sch\u00e9mas d'appel. Je pr\u00e9vois donc de proc\u00e9der \u00e0 des <em>Tests de fum\u00e9e<\/em> apr\u00e8s les mises \u00e0 jour et je dispose d'un environnement de test qui, en cas de doute, peut \u00eatre utilis\u00e9 avec <em>LOG<\/em>-actions. Cela me permet de voir les nouvelles demandes avant de valider la mise en production. De plus, je documente d\u00e9lib\u00e9r\u00e9ment les diff\u00e9rences entre les images (par exemple, les conteneurs bas\u00e9s sur musl par rapport \u00e0 ceux bas\u00e9s sur glibc), car celles-ci peuvent emprunter des chemins diff\u00e9rents vers l'API du noyau. Pour les retours en arri\u00e8re, une gestion claire des versions des profils est essentielle ; en cas d\u2019incident, je passe temporairement \u00e0 une politique moins stricte, avec une dur\u00e9e d\u2019expiration courte et une surveillance \u00e9troite.<\/p>\n\n<h2>Identifier les types d'erreurs : journalisation et triage<\/h2>\n\n<p>Les appels syst\u00e8me bloqu\u00e9s doivent pouvoir \u00eatre identifi\u00e9s, sinon on avance \u00e0 l'aveuglette dans le <strong>Dans le noir<\/strong>. J'active la journalisation au niveau du runtime et j'analyse les m\u00e9triques qui r\u00e9v\u00e8lent des pics et des valeurs aberrantes. Les messages contenant EPERM ou EACCES indiquent souvent que les r\u00e8gles sont trop restrictives. J\u2019attribue les arr\u00eats inattendus au composant concern\u00e9 et je v\u00e9rifie les indicateurs ou arguments correspondants. Ensuite, j\u2019ajuste les <strong>Filtre<\/strong> R\u00e9glez-le au minimum et refaites un test.<\/p>\n\n<h2>Playbook de d\u00e9pannage<\/h2>\n\n<ul>\n  <li><strong>Reproduire<\/strong>: reproduire exactement le m\u00eame flux de donn\u00e9es et corr\u00e9ler les journaux.<\/li>\n  <li><strong>Identifier<\/strong>: enregistrer l'appel syst\u00e8me concern\u00e9 avec ses arguments (par exemple via le journal d'ex\u00e9cution ou les sorties d'audit).<\/li>\n  <li><strong>\u00c9valuer<\/strong>: Cet appel est-il n\u00e9cessaire ? Existe-t-il une alternative pr\u00e9sentant moins de risques (par exemple, \u00ab openat \u00bb au lieu de \u00ab open \u00bb, des indicateurs plus sp\u00e9cifiques) ?<\/li>\n  <li><strong>Personnaliser<\/strong>: autoriser le minimum, de pr\u00e9f\u00e9rence avec des filtres d'arguments ; laisser l'action par d\u00e9faut sur \u00ab stricte \u00bb.<\/li>\n  <li><strong>Se prot\u00e9ger<\/strong>: pour les exceptions d\u00e9licates, renforcer \u00e9galement la r\u00e9duction des capacit\u00e9s, le syst\u00e8me de fichiers en lecture seule ou les espaces de noms.<\/li>\n  <li><strong>Nouveau test et t\u00e9l\u00e9m\u00e9trie<\/strong>: apr\u00e8s la correction, effectuer des tests cibl\u00e9s, surveiller les indicateurs et configurer des alertes.<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/tech_office_linux_security_8432.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Comparaison avec SELinux, AppArmor et les capacit\u00e9s<\/h2>\n\n<p>Seccomp intervient au niveau de l'interface entre l'application et le noyau, tandis que SELinux et AppArmor r\u00e9gulent principalement les acc\u00e8s aux objets. Les capacit\u00e9s contr\u00f4lent les op\u00e9rations privil\u00e9gi\u00e9es, que je r\u00e9duis par ailleurs consid\u00e9rablement. En combinaison avec <a href=\"https:\/\/webhosting.de\/fr\/server-context-isolation-namespaces-cgroups-hebergement-securite\/\">Espaces de noms et Cgroups<\/a> On obtient ainsi une strat\u00e9gie de protection \u00e0 plusieurs niveaux. Je s\u00e9pare les ressources, je supprime les privil\u00e8ges inutiles et je limite les chemins d'acc\u00e8s au noyau via <strong>Seccomp<\/strong>. Cette combinaison permet de maintenir les charges de travail bien encadr\u00e9es et faciles \u00e0 contr\u00f4ler.<\/p>\n\n<h2>Performances et surcharge<\/h2>\n\n<p>Un profil Seccomp bien con\u00e7u n'entra\u00eene qu'une faible <strong>Overhead<\/strong>: Le noyau v\u00e9rifie un petit programme BPF pour chaque appel syst\u00e8me. Dans la pratique, cela n'a pratiquement aucun impact mesurable sur les charges de travail Web et de services courantes. Les chemins \u00e0 haute fr\u00e9quence et \u00e0 forte intensit\u00e9 d'appels syst\u00e8me (par exemple, le traitement des paquets, les processus IPC tr\u00e8s actifs) peuvent toutefois devenir critiques. Je veille donc \u00e0 limiter le nombre de r\u00e8gles, j\u2019utilise des filtres d\u2019arguments plut\u00f4t que de longues listes et je teste les chemins critiques \u00e0 l\u2019aide de benchmarks. Si un profil entra\u00eene un ralentissement mesurable, je v\u00e9rifie d\u2019abord s\u2019il y a des doublons, des correspondances impr\u00e9cises et si certains appels rares peuvent \u00eatre d\u00e9port\u00e9s vers un processus distinct.<\/p>\n\n<h2>Bonnes pratiques pour des param\u00e8tres par d\u00e9faut s\u00e9curis\u00e9s<\/h2>\n\n<p>Je commence par le profil par d\u00e9faut du Runtime, puis je l'affine en fonction de <strong>Charge de travail<\/strong>. Les services hautement sensibles, tels que les passerelles ou les services d'authentification, sont soumis \u00e0 des r\u00e8gles particuli\u00e8rement strictes. J'int\u00e8gre les modifications apport\u00e9es aux profils dans le processus CI\/CD et je les teste automatiquement. Je recommande en outre une forte r\u00e9duction des capacit\u00e9s, des syst\u00e8mes de fichiers en lecture seule et l\u2019application de la politique \u00ab NoNewPrivs \u00bb. Vous trouverez un guide sur les m\u00e9canismes globaux de protection des h\u00f4tes \u00e0 l\u2019adresse suivante : <a href=\"https:\/\/webhosting.de\/fr\/renforcement-du-noyau-linux-fonctionnalites-de-securite-pour-les-serveurs-dhebergement-securises\/\">Renforcement du noyau<\/a>, qui se combine bien avec Seccomp.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linux_seccomp_sicherheit_1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Durcissement avanc\u00e9 : ce que je v\u00e9rifie en plus<\/h2>\n\n<p>Outre les habituels suspects (<em>monter<\/em>, <em>ne plus partager<\/em>, <em>bpf<\/em>, <em>ptrace<\/em>, <em>keyctl<\/em>, <em>perf_event_open<\/em>) j'examine les requ\u00eates suivantes et, selon le contexte, je les limite consid\u00e9rablement ou je les bloque compl\u00e8tement :<\/p>\n<ul>\n  <li><strong>setns<\/strong>: emp\u00eache le passage vers d'autres espaces de noms.<\/li>\n  <li><strong>process_vm_readv\/process_vm_writev<\/strong>: emp\u00eache l'acc\u00e8s direct \u00e0 la m\u00e9moire d'autres processus.<\/li>\n  <li><strong>kexec_load<\/strong> et <strong>red\u00e9marrage<\/strong>: prot\u00e8gent contre les tentatives de red\u00e9marrage ou de remplacement du noyau.<\/li>\n  <li><strong>swapon\/swapoff<\/strong> et <strong>init_module\/finit_module<\/strong>: limitent les m\u00e9canismes de chargement du syst\u00e8me et des modules.<\/li>\n  <li><strong>clone3<\/strong> avec des indicateurs \u00e0 risque (par exemple, les espaces de noms) : limiter de mani\u00e8re granulaire via des arguments.<\/li>\n  <li><strong>io_uring_setup<\/strong>: \u00e0 autoriser ou \u00e0 limiter strictement en fonction de la charge de travail, car il s'agit d'une interface puissante.<\/li>\n<\/ul>\n<p>La r\u00e8gle d'or est la suivante : autant que n\u00e9cessaire, aussi peu que possible \u2013 et mieux vaut une petite exception document\u00e9e qu'une r\u00e8gle standard trop large.<\/p>\n\n<h2>Int\u00e9gration dans CI\/CD et Teams<\/h2>\n\n<p>Je traite les profils Seccomp comme <strong>Code<\/strong>: gestion des versions, r\u00e9vision, tests. Les t\u00e2ches du pipeline v\u00e9rifient si les profils correspondent \u00e0 l\u2019image et s\u2019il y a des blocages. Les tests de fum\u00e9e avec des donn\u00e9es de test d\u00e9tectent plus rapidement les changements de comportement que les clics manuels. Les d\u00e9veloppeurs re\u00e7oivent un petit guide expliquant comment fonctionne la journalisation et o\u00f9 ils peuvent adapter les signatures. C\u2019est ainsi que la <strong>S\u00e9curit\u00e9<\/strong> directement int\u00e9gr\u00e9 au processus de d\u00e9veloppement et reste \u00e0 jour.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/seccomp-linux-server-8765.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>En bref<\/h2>\n\n<p>Seccomp limite la <strong>Appels syst\u00e8me<\/strong> en limitant l'application au strict n\u00e9cessaire, ce qui \u00e9limine ainsi de nombreuses voies d'attaque. Je commence par une configuration par d\u00e9faut robuste, j'\u00e9value le comportement r\u00e9el, puis je restreins progressivement l'acc\u00e8s. Les plateformes de conteneurs telles que Kubernetes ou OpenShift me d\u00e9chargent d'une grande partie du travail de base lorsque je d\u00e9finis \u00ab seccompDefault \u00bb et que je d\u00e9ploie les profils de mani\u00e8re centralis\u00e9e. Combin\u00e9e aux capacit\u00e9s (capabilities), \u00e0 SELinux\/AppArmor ainsi qu\u2019aux espaces de noms (namespaces) et aux groupes de contr\u00f4le (cgroups), cette approche offre une protection multiple efficace. En suivant cette approche de mani\u00e8re coh\u00e9rente, on r\u00e9duit le risque d\u2019exploits du noyau tout en assurant une bonne protection des charges de travail. <strong>contr\u00f4lable<\/strong>.<\/p>","protected":false},"excerpt":{"rendered":"<p>Seccomp Linux est un \u00e9l\u00e9ment central de la s\u00e9curit\u00e9 du noyau. D\u00e9couvrez comment le mode de calcul s\u00e9curis\u00e9 limite les appels syst\u00e8me, isole les conteneurs dans un bac \u00e0 sable et prot\u00e8ge efficacement vos charges de travail.<\/p>","protected":false},"author":1,"featured_media":20261,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[794],"tags":[],"class_list":["post-20268","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-sicherheit-computer_und_internet"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"99","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"Seccomp Linux","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"20261","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/20268","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/comments?post=20268"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/20268\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media\/20261"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media?parent=20268"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/categories?post=20268"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/tags?post=20268"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}