Les erreurs d'autorisation qui se produisent uniquement dans les sous-processus surviennent lorsque l'agent lance des processus enfants avec une identité, un environnement, un espace de noms, une vue du système de fichiers ou une politique de sécurité différente.
Un processus agent peut lire un fichier du foyer ou appeler un outil avec succès, puis recevoir un refus d'autorisation lorsque la même action s'exécute via un shell, un processus worker Python, un conteneur ou un bac à sable. Le processus enfant peut perdre des groupes supplémentaires, des identifiants d'authentification, des variables d'environnement, des capacités, l'accès aux sockets, la visibilité des points de montage ou les droits d'exécution. Le texte de la commande est identique, mais son contexte de sécurité ne l'est pas.
L'enfant peut hériter d'un ensemble différent d'utilisateurs et d'identifiants
Les lanceurs peuvent définir l'UID, le GID, les groupes supplémentaires, l'umask, le répertoire de travail, l'environnement et les descripteurs de fichiers. Les gestionnaires de services, les utilitaires setuid, les conteneurs et les pools de workers peuvent volontairement réduire les privilèges avant d'exécuter du code généré. Cette distinction reste visible lors des tests ultérieurs dans le foyer.
Une analyse pratique du contexte de sécurité du processus commence par les vérifications de l'identité, de la politique de sécurité et de l'espace de noms, plutôt que de supposer que les bits de mode Unix expliquent tout. Le signe caractéristique est un identifiant, des groupes, une umask ou des informations d'authentification différents à l'intérieur de l'enfant.
Le fait qu'un parent s'exécute en tant que root ne garantit pas un enfant sans restriction, et les identifiants numériques peuvent être associés différemment dans les conteneurs ou sur les partages réseau. Comparez l'identité effective au niveau de l'appel système en échec. Le résultat intermédiaire doit rester inspectable avant la poursuite de l'automatisation.
Les espaces de noms, les points de montage et les bacs à sable modifient la vue du système de fichiers
Un sous-processus peut entrer dans un conteneur ou un bac à sable où les chemins sont en lecture seule, masqués, remappés, montés avec l'option noexec ou appartenant à un autre identifiant numérique. Les sockets Unix et les fichiers de périphériques peuvent être absents même lorsque les fichiers ordinaires sont visibles.
Un cas de dépannage de bac à sable montre les autorisations des sockets du bac à sable lorsqu'un enfant ne peut pas accéder au socket transféré dont il a besoin. La leçon est qu'un refus d'autorisation peut décrire une connectivité ou une politique d'espace de noms, et pas seulement le contenu des fichiers. Cette limite doit être mesurée séparément dans des conditions d'utilisation réalistes.
Si l'enfant voit un autre inode, d'autres options de montage ou un autre chemin, la modification des autorisations sur l'hôte peut ne rien changer pour lui. Résolvez le chemin et l'identité du point de montage depuis le contexte en échec. La conséquence pratique apparaît lorsque plusieurs sources se disputent un contexte limité.
Les capacités et les politiques obligatoires peuvent refuser des opérations malgré des bits de mode autorisés
Les capacités Linux répartissent les privilèges root, tandis que SELinux, AppArmor, seccomp et les règles du bac à sable peuvent rejeter des opérations malgré les bits de lecture ou d'exécution du propriétaire. Les opérations réseau, ptrace, sur les périphériques et les points de montage constituent des limites courantes. Cette dépendance doit rester explicite dans l'interface finale.
Le modèle des capacités et des étiquettes de sécurité présente les contrôles UID et GID aux côtés des capacités et des étiquettes de sécurité. Ces couches indépendantes expliquent pourquoi un simple chmod peut laisser l'échec du sous-processus inchangé. Le résultat doit donc être vérifié par rapport aux éléments de preuve d'origine.
La limite d'échec est un message d'autorisation généré par l'application qui ne correspond pas à un refus du système d'exploitation. Capturez errno, les journaux d'audit et l'appel système exact avant d'assouplir la politique du bac à sable ou de rendre les fichiers accessibles en écriture à tous. Cette distinction reste visible lors des tests ultérieurs dans le foyer.
Comparez les contextes de sécurité du parent et de l'enfant lors de l'appel en échec
Capturez le chemin de l'exécutable, les arguments, le répertoire de travail, l'UID, le GID, les groupes, l'umask, les noms des variables d'environnement, les descripteurs de fichiers, les identifiants des espaces de noms, la table des points de montage, l'inode du chemin, le mode, l'ACL, l'étiquette de sécurité, les capacités, l'état de seccomp, la présence du socket, errno et la décision d'audit dans le parent et l'enfant.
Utilisez les contrôles de capacité des agents pour relier le résultat à la portée des outils de l'agent. Reproduisez le problème avec un processus enfant minimal, puis réintroduisez les couches du lanceur, du conteneur et du bac à sable une par une. Le résultat intermédiaire doit rester inspectable avant la poursuite de l'automatisation.
N'accordez que la capacité, le groupe, le point de montage, le socket ou le chemin manquant. Conservez la restriction lorsqu'elle reflète une isolation intentionnelle ; l'échec du sous-processus peut indiquer que la limite de confiance de l'IA domestique fonctionne correctement. Cette limite doit être mesurée séparément dans des conditions d'utilisation réalistes.
Centre Tech & IA
Plus à lire

Qu’est-ce qui amène un planificateur d’agent IA à répéter des étapes déjà effectuées ?
Suivez les étapes répétées du planificateur à travers la persistance de l’état, les preuves d’achèvement, l’analyse des résultats des outils, la conservation du contexte,...

Quelles sont les causes de la saturation du processeur lorsque le transcodage matériel et l’IA vidéo s’exécutent simultanément ?
Suivez la saturation du processeur au niveau du déchargement des codecs, de la conversion des pixels, des copies d’images, du prétraitement de l’IA, de...

Qu’est-ce qui amène le même LLM local à renvoyer des schémas JSON incohérents ?
Diagnostiquez les JSON locaux incohérents en figeant le chemin du modèle, le prompt, le schéma, les contraintes du décodeur, l’échantillonnage, le contexte, les conditions...

