La réutilisation des PID fausse l'attribution des sessions d'agent

Un PID seul convient pour un écran d'état. Il ne convient pas comme identité derrière une approbation, une trace d'audit ou une session d'agent qui détient des identifiants. Le système d'exploitation réutilise les identifiants de processus. Un système d'agent qui traite un numéro réutilisé comme s'il désignait le même acteur peut associer un processus ultérieur à l'approbation d'un processus précédent.

Cette erreur ne nécessite ni un attaquant disposant d'un accès au noyau, ni une condition de concurrence exceptionnelle. Elle apparaît lorsqu'un agent de courte durée se termine, qu'une machine occupée crée suffisamment de processus pour réutiliser son PID, puis qu'un composant reconnecte un appel, actualise un affichage ou retrouve une ancienne ligne d'audit à partir du PID. Le processus ultérieur peut être un logiciel tout à fait ordinaire. L'attribution reste erronée, et un système d'approbation qui agit sur une attribution fausse a déjà perdu la raison d'être des approbations.

La correction n'est pas compliquée, mais elle demande de changer de vocabulaire. Cessez d'appeler un PID une identité de processus. Enregistrez une fiche de processus capturée qui contient le PID, son heure de démarrage, ses informations de signature du code et la provenance de son parent, recueillies au moment où vous avez pris la décision d'autorisation. Ensuite, chaque comparaison ultérieure doit prouver que le processus actif correspond toujours à cette fiche.

Un PID désigne un emplacement, pas toute la durée de vie d'un processus

Un identifiant de processus désigne une entrée de processus actuellement attribuée par le noyau. Il ne nomme pas un programme pour toujours et ne garantit pas une unicité globale dans le temps. Lorsque le processus se termine, son PID peut être réutilisé.

Cette distinction paraît pointilleuse jusqu'à ce qu'un système laisse une ancienne approbation continuer de s'appliquer. Supposons qu'un client d'agent démarre avec le PID 4812, demande à utiliser un identifiant de déploiement et que l'utilisateur approuve cette exécution. Le client se termine. Plus tard, un autre processus reçoit le PID 4812. Si votre passerelle demande « le PID 4812 dispose-t-il d'une session approuvée ? », elle peut retrouver l'ancienne approbation et l'associer au nouveau processus.

Le point dangereux est que l'ancien et le nouveau processus n'ont pas besoin de s'exécuter en même temps. De nombreuses implémentations commettent l'erreur dans une jointure de base de données, une recherche dans un cache ou une tâche d'enrichissement différée. Elles enregistrent une approbation sous la forme pid = 4812, enregistrent les appels de la même manière et font confiance à une requête ultérieure pour conserver le sens initial. Ce n'est pas le cas.

Un PID peut rester utile dans un enregistrement destiné aux humains, car il aide un opérateur à inspecter un système actif. Conservez-le. Ne l'utilisez simplement pas comme identité principale pour l'autorisation ou l'attribution.

Il existe un second piège : fork et exec compliquent les explications trop simples. Un fork crée un nouvel enfant avec un PID différent. Un exec remplace l'image du programme dans un processus existant tout en conservant son PID. Si vous approuvez un exécuteur de shell qui lance ensuite un autre binaire avec exec, le PID reste familier, alors que le code qui effectuera la prochaine requête peut avoir changé. Une conception de l'identité doit prendre en compte à la fois la réutilisation du PID après un arrêt et le remplacement du programme dans un processus qui continue de vivre.

Capturez une fiche de processus au début de la session

Une fiche de session fiable est un instantané pris à la frontière de sécurité, pas un ensemble de faits reconstruits plus tard. Capturez-la lorsque le processus d'agent demande pour la première fois à créer une session, avant d'afficher une approbation qui décrit l'appelant.

Pour une passerelle d'agent macOS, j'enregistrerais les champs suivants dans un instantané de processus immuable :

• Le PID et l'ID utilisateur effectif.
• L'heure de démarrage du processus, avec les secondes et les microsecondes lorsque la plateforme les fournit.
• Le chemin de l'exécutable observé au moment de la capture.
• L'identifiant de signature, le contexte de l'équipe ou du signataire et le hachage du répertoire de code lorsque ces informations sont disponibles.
• Un instantané du processus parent, comprenant son propre PID et son heure de démarrage.

L'heure de démarrage transforme un PID en référence propre à un cycle de vie. Un tuple pratique ressemble à ceci :

process_instance = (
  pid = 4812,
  start_time = 2026-07-22T14:03:18.482911Z,
  euid = 501
)

Ce tuple répond à une question précise : « Est-ce le même cycle de vie de processus du noyau que celui que j'ai observé auparavant ? » Il ne dit pas si le processus est digne de confiance. L'enregistrement de signature répond à une autre question : « Quel code macOS a-t-il validé lorsque j'ai inspecté ce processus ? » L'instantané du parent en répond à une troisième : « Qu'est-ce qui a créé ce processus, d'après l'observation faite au début de la session ? »

Ne réduisez pas ces questions à une seule étiquette textuelle comme Claude Code (PID 4812). Cette étiquette peut convenir à une carte d'approbation, mais elle vous prive des faits nécessaires lorsqu'un réviseur demande pourquoi une session donnée a été autorisée.

Sur macOS, un inspecteur de processus peut utiliser proc_pidinfo avec PROC_PIDTBSDINFO pour obtenir proc_bsdinfo, qui contient pbi_start_tvsec et pbi_start_tvusec. Apple expose également start_time dans son modèle de processus Endpoint Security. Le choix de l'API importe moins que le fait de capturer l'heure de démarrage au moment de la décision et de la comparer ensuite.

Un petit utilitaire C consacré au cycle de vie peut ressembler à ceci :

#include <libproc.h>
#include <sys/proc_info.h>
#include <cstdio.h>

int read_process_lifetime(pid_t pid) {
    struct proc_bsdinfo info = {0};
    int size = proc_pidinfo(pid, PROC_PIDTBSDINFO, 0,
                            &info, sizeof(info));
    if (size != sizeof(info)) {
        return -1;
    }

    printf("pid=%d start=%lld.%06d parent=%d uid=%d\n",
           info.pbi_pid,
           info.pbi_start_tvsec,
           info.pbi_start_tvusec,
           info.pbi_ppid,
           info.pbi_uid);
    return 0;
}

La forme de la sortie compte davantage que le langage utilisé :

pid=4812 start=1784738598.482911 parent=4760 uid=501

Si une lecture ultérieure renvoie le même PID avec un horodatage de démarrage différent, vous avez affaire à un autre processus. Refusez la correspondance de session, même si toutes les couches pratiques veulent considérer ce numéro comme familier.

La signature du code décrit le code, pas une instance en cours d'exécution

Les données de signature du code apportent une provenance utile, mais ne deviennent pas automatiquement une identité de processus. Un identifiant de signature peut être partagé par toutes les versions publiées d'une application. Un identifiant d'équipe désigne une organisation signataire, pas un exécutable particulier. Un hachage du répertoire de code est plus spécifique au contenu signé, mais plusieurs instances du même exécutable exécutées simultanément le partageront encore.

La documentation d'Apple sur la signature du code établit une distinction importante que les produits de sécurité brouillent souvent. Un identifiant de signature peut être revendiqué par plusieurs signataires. Apple recommande donc de vérifier la catégorie de validation et, pour le code qui n'est pas signé par Apple, l'identifiant d'équipe également. La note technique TN3127 d'Apple explique aussi qu'une exigence désignée associe un identifiant à des exigences de signature afin d'établir l'identité du code au fil des mises à jour.

C'est le bon modèle mental : les informations de signature indiquent quel exécutable macOS a validé et s'il répond à vos exigences de confiance. Elles ne disent pas s'il s'agit du même processus que celui que l'utilisateur a approuvé cinq minutes plus tôt.

Pour l'autorisation d'une session, utilisez les deux niveaux :

same_process_lifetime:
  pid, start_time, euid all match the captured record

same_expected_code:
  captured signing requirement still validates for the live process

same_session:
  the session token refers to this captured process record, not only its PID

Ne comparez pas seulement un nom d'affichage, un identifiant de bundle ou un chemin. Les chemins changent. Les outils en ligne de commande non signés peuvent avoir une identité faible ou limitée à la machine. Un utilisateur peut aussi exécuter une copie d'un outil familier depuis un autre emplacement. Votre interface d'approbation peut afficher une étiquette compréhensible, mais votre code d'autorisation doit conserver les informations de signature évaluées qui ont conduit à cette étiquette.

Une recommandation souvent erronée consiste à autoriser uniquement à partir de l'identifiant de signature, parce qu'il reste stable lors des mises à jour. Elle est populaire, car la continuité entre les versions semble pratique. Elle ne convient pas à une approbation propre à une exécution. Si une personne a approuvé un processus d'agent en cours d'exécution, le lancement ultérieur du même programme signé constitue une nouvelle exécution et doit faire l'objet d'une nouvelle décision de session. L'identité stable du code rend la carte d'approbation plus lisible. Elle ne permet pas d'étendre silencieusement une approbation ponctuelle à toutes les instances futures.

Le PID du parent n'est une preuve que si vous conservez son cycle de vie

Les données du processus parent aident les réviseurs à comprendre comment un agent a démarré. Elles peuvent distinguer un client lancé depuis un terminal d'un processus lancé par un éditeur, un planificateur ou un autre agent. Mais ppid = 4760 souffre du même problème de réutilisation que le PID de l'enfant.

Le mauvais modèle est facile à repérer :

session.agent_pid = 4812
session.parent_pid = 4760

Trois heures plus tard, une visionneuse d'audit retrouve le PID 4760 et l'étiquette comme le parent de la session. Le parent d'origine peut avoir disparu depuis longtemps. Un autre processus possède maintenant le PID 4760. La page d'audit a transformé une affirmation historique en recherche active et réécrit discrètement l'histoire.

Capturez l'instantané du parent en même temps que celui de l'enfant :

parent_instance = (
  pid = 4760,
  start_time = 2026-07-22T14:01:02.117604Z,
  euid = 501,
  executable_path = "/usr/bin/login",
  signing_requirement = "captured evaluation",
  relationship = "observed_parent_at_session_open"
)

Le dernier champ semble banal, mais il évite beaucoup de formulations erronées. L'enregistrement du parent signifie « c'était le parent direct lorsque le système a observé l'enfant ». Il ne signifie pas « ce parent a autorisé l'enfant », « ce parent possède l'enfant pour toujours » ou « ce parent reste le parent actuel ». Ces affirmations nécessitent des preuves distinctes.

Si vous disposez des événements de processus Endpoint Security, es_process_t fournit le PID du parent d'origine et expose parent_audit_token et responsible_audit_token, ainsi que l'heure de démarrage et les données de signature. Les jetons d'audit sont préférables aux PID bruts lorsque l'API les fournit, car ils conservent davantage de contexte. Traitez malgré tout l'objet de processus d'un événement comme une observation capturée. Ne le remplacez pas par une recherche ultérieure de PID en prétendant qu'elle est équivalente.

Pour les systèmes qui ne disposent pas d'Endpoint Security, utilisez les meilleures API de processus disponibles, capturez rapidement les données et rendez l'incertitude visible. Un parent peut se terminer entre la lecture de l'enfant et celle du parent. N'inventez pas de certitude dans cette situation. Marquez le parent comme indisponible ou partiel, conservez l'identité de l'enfant que vous avez pu capturer et évitez d'affirmer une relation parentale que vous n'avez pas observée.

Revalidez avant qu'une session approuvée n'effectue une action

L'approbation d'une session nécessite deux moments de contrôle de l'identité : la capture à l'ouverture de la session et la revalidation lorsque la session utilise son autorité. La capture protège la trace d'audit. La revalidation protège l'action suivante.

Imaginez la séquence suivante :

1. Un processus d'agent ouvre une session et vous capturez le PID 4812, l'heure de démarrage, les informations du signataire et les détails du parent.
2. Une personne approuve cette exécution précise de l'agent.
3. Le processus se termine alors que le jeton de session reste en mémoire ou sur une connexion IPC locale.
4. Un processus ultérieur reçoit le PID 4812 et présente un jeton obsolète, ou retrouve une ancienne association à cause d'un bug.
5. Votre passerelle vérifie le processus actif avant d'effectuer un appel avec des identifiants.

Lors du contrôle final, le PID peut correspondre. L'heure de démarrage, elle, ne correspondra pas. Cette différence doit fermer la session. Ne corrigez pas l'enregistrement avec le nouvel horodatage, ne créez pas silencieusement une session de remplacement et n'attribuez pas l'action au processus précédent.

Le contrôle doit aussi refuser la demande lorsque l'inspection échoue. Si votre code ne peut pas lire les informations du processus parce que celui-ci s'est terminé, que les permissions ont changé ou que le système d'exploitation renvoie des données incomplètes, il ne peut pas établir que le demandeur est le processus approuvé. La bonne réponse consiste à demander une nouvelle session.

Gardez la comparaison étroite et littérale. N'utilisez pas de correspondance approximative comme « même nom de commande », « même répertoire de travail » ou « même fenêtre de terminal ». Ces champs aident un humain à comprendre le contexte, mais ne résistent pas à l'ambiguïté, qu'elle soit accidentelle ou provoquée. Un processus peut changer de répertoire de travail et deux processus sans rapport peuvent choisir le même nom de commande.

Le bon endroit pour mettre en cache est la décision d'autorisation liée à l'instance de processus capturée. Le mauvais endroit est une table associant un PID à un état d'approbation. Une table indexée par PID passera les tests sur un ordinateur portable peu sollicité et échouera sous une forte rotation des processus, ce qui la rend particulièrement difficile à diagnostiquer une fois qu'elle est utilisée par des clients.

Modélisez les sessions comme des événements immuables, pas comme des lignes de processus modifiables

Un journal de session doit conserver ce que la passerelle a observé à chaque instant. Une ligne modifiable qui indique toujours « le PID 4812 est actif » ne peut pas préciser si ses champs proviennent de l'agent d'origine, d'un processus de remplacement ou d'une actualisation tardive en arrière-plan.

Utilisez des enregistrements d'événements ajoutés uniquement, avec des références explicites. La structure peut rester simple :

{
  "event_type": "session_authorized",
  "session_id": "sess_7d9f",
  "process_instance": {
    "pid": 4812,
    "start_time": "2026-07-22T14:03:18.482911Z",
    "euid": 501,
    "signing_id": "com.example.agent",
    "team_id": "A1B2C3D4E5",
    "cdhash": "captured-code-directory-hash"
  },
  "parent_instance": {
    "pid": 4760,
    "start_time": "2026-07-22T14:01:02.117604Z"
  },
  "approval": {
    "scope": "this process run",
    "decision": "approved"
  }
}

L'événement du prochain appel fait référence à sess_7d9f et enregistre sa propre heure, le canal demandé, la cible de l'action et le résultat. Il ne copie pas seulement pid: 4812 en espérant qu'un analyste pourra reconstituer le reste. Si la revalidation échoue, écrivez un événement de refus distinct avec la différence observée.

{
  "event_type": "action_denied",
  "session_id": "sess_7d9f",
  "reason": "process_start_time_mismatch",
  "captured_pid": 4812,
  "captured_start_time": "2026-07-22T14:03:18.482911Z",
  "observed_start_time": "2026-07-22T15:47:09.031882Z"
}

Le réviseur dispose ainsi d'un élément concret : le numéro de processus a été réutilisé, la passerelle a reconnu la différence et elle a refusé la demande. Sans les deux horodatages, l'événement indique seulement qu'une erreur s'est produite. Cela ne suffit pas lorsqu'il faut distinguer un défaut logiciel d'une tentative hostile de récupérer une autorité.

La séparation de Sallyport entre un journal des sessions et un journal d'activité est utile ici, car l'autorisation au niveau de la session et les actions individuelles répondent à des questions d'audit différentes. Les deux doivent conserver l'instantané du processus qui existait au moment de la décision de session, plutôt que de s'appuyer sur un PID seul lors d'une projection ou d'une revue ultérieure.

La carte d'approbation doit décrire la provenance sans feindre la certitude

Les utilisateurs ne peuvent pas prendre une bonne décision devant une boîte de dialogue qui dit seulement « Un agent demande un accès ». Ils ont besoin d'un contexte d'identité suffisant pour reconnaître l'appelant, mais il ne faut pas surcharger la carte de champs qui semblent précis tout en apportant peu d'informations.

Mettez en avant l'autorité de signature du code que vous avez évaluée. Ajoutez le nom ou le chemin de l'exécutable lorsqu'il est utile. Décrivez la relation avec le processus en termes simples, par exemple « lancé par une application de terminal signée » ou « lancé depuis un composant auxiliaire d'éditeur », uniquement si vous avez capturé les données correspondantes. Affichez le PID comme information de dépannage, pas comme identité revendiquée.

Évitez de présenter une chaîne de parents comme s'il s'agissait d'une chaîne de certificats. La filiation est une observation ponctuelle du système d'exploitation. Un parent signé peut lancer un enfant non signé. Un parent attendu peut être un intermédiaire qui lance ensuite autre chose avec exec. La carte d'approbation doit indiquer clairement qui demande la session maintenant, puis fournir les informations sur le parent comme contexte.

Cette distinction modifie aussi la révocation. Révoquez un identifiant de session, pas un PID. Lorsqu'une personne révoque la session, marquez l'enregistrement de session immuable comme révoqué et refusez les futures tentatives d'action qui s'y réfèrent. Si le processus d'origine fonctionne encore, il perd son accès. S'il s'est terminé et que son PID a été réutilisé, la révocation reste correcte, car elle n'a jamais dépendu du contrôle de ce PID numérique.

Une approbation doit correspondre à une exécution observée. Si les utilisateurs veulent une décision de confiance plus large, créez une fonctionnalité distincte et explicite, avec un périmètre clair, par exemple une exigence de code signé assortie d'une durée définie. N'introduisez pas subrepticement ce périmètre plus large dans une approbation de session parce que l'implémentation disposait d'un cache de PID pratique.

Testez l'échec au lieu de faire confiance au comportement habituel des processus

Les bugs liés à la réutilisation des PID restent cachés, car les tests manuels ordinaires ne créent pas assez de rotation. Une suite de tests doit obliger votre code à prouver qu'il refuse un processus de remplacement qui a hérité d'un numéro et qu'il refuse un exec qui modifie le code derrière un processus qui continue de vivre.

Vous n'avez pas besoin d'attendre que macOS réutilise naturellement un PID donné. Placez la couche d'inspection des processus derrière une interface, puis fournissez-lui des instantanés contrôlés. Un bon test comprend un enregistrement approuvé et une observation active ultérieure avec le même PID, mais une heure de démarrage différente :

captured: pid=4812 start=1784738598.482911 signer=team-A
observed: pid=4812 start=1784744029.031882 signer=team-B
expected: deny with process_start_time_mismatch

Ajoutez un second cas où le PID et l'heure de démarrage correspondent, mais où la règle de signature échoue. Ajoutez-en un autre où l'enfant reste actif, mais où exec a modifié les informations de son exécutable. Ces tests prouvent que votre code d'autorisation rapproche les bons champs, au lieu de vérifier seulement que l'inspection du processus renvoie des données.

Testez séparément la vue d'audit. Initialisez une ancienne session avec un PID parent, simulez l'arrêt de ce parent, puis fournissez un processus sans rapport avec le même PID. La session historique affichée doit conserver les champs capturés du parent d'origine. Elle ne doit pas les remplacer par un nom obtenu dans la table actuelle des processus.

Enfin, testez l'annulation et les échecs d'inspection. Un processus peut disparaître dans le court intervalle qui sépare l'acceptation d'une demande IPC de la consultation de ses détails. Votre code doit enregistrer une raison claire de refus et demander à l'appelant d'établir une nouvelle session. Les systèmes qui transforment ces échecs en correspondances approximatives créent précisément l'ambiguïté que le modèle d'identité devait supprimer.

L'invariant utile est simple et strict

Toute action privilégiée d'un agent doit faire référence à une session liée à un seul cycle de vie de processus capturé. Une demande active correspondante doit prouver qu'elle provient de ce même cycle de vie et que son exécutable satisfait encore à l'identité de code approuvée. Un PID réutilisé échoue au premier test. Un autre binaire derrière un PID inchangé échoue au second.

Cet invariant maintient chaque information de processus dans son rôle. Les données de démarrage distinguent les cycles de vie. Les données du signataire identifient le code validé. Les détails du parent fournissent la provenance. L'identifiant de session porte la décision humaine. Aucun de ces champs ne peut remplir le rôle des autres.

Sallyport peut rendre cette décision visible en présentant l'autorité de signature du code du processus au début de l'autorisation de session et en conservant des enregistrements distincts pour les exécutions et les appels. L'implémentation doit néanmoins refuser qu'un simple numéro, aussi familier qu'il paraisse dans un journal, remplace le processus qui a obtenu l'approbation.

La prochaine fois que vous voyez une table indexée par pid, demandez-vous ce qui se passe après l'arrêt du processus. Si la réponse est « nous le recherchons à nouveau », cette table ne stocke pas l'identité d'une session. Corrigez cela avant qu'un événement banal du cycle de vie d'un processus ne se transforme en erreur d'autorisation.