Répondre à l'invite de confirmation utilisateur
Quand un changement n'est ni clairement sûr ni une attaque prouvée, PoisonZero le retient et demande. Cette page porte sur la réponse : ce que montre l'invite de confirmation utilisateur, ce que font Garder et Refuser, et pourquoi aucune réponse vaut un refus.
Ce que montre l'invite de confirmation utilisateur
L'invite montre seulement la ligne ajoutée, citée depuis le fichier pour qu'elle ne semble jamais être PoisonZero qui parle :
| Affiché | Signification |
|---|---|
| Fichier | Le chemin complet du fichier modifié |
| Modifié | Quand la ligne a été ajoutée, d'après les données |
| La nouvelle ligne | La ligne ajoutée seule, citée telle quelle ; le reste du fichier n'est pas montré |
| Recommandation | Une phrase simple ; rien n'y pousse vers Garder |
Garder ou refuser
Deux boutons, chacun nommant ce qui arrive à la ligne retenue :
| Réponse | Résultat |
|---|---|
| Garder | Le contenu reste en place et est noté comme approuvé par vous. Ce contenu exact devient le nouveau point de référence : la même trouvaille n'est plus soulevée, et l'approbation est visible dans la console. |
| Refuser | La ligne est retirée, le fichier remis à son état sûr. En quarantaine, pas supprimé, récupérable. |
| Aucune réponse | Traitée comme Refuser : retour à l'état sûr. |
La fenêtre de rétention
- Retenu, non appliqué : le fichier garde son dernier contenu propre jusqu'à ce que vous choisissiez Garder.
- Un délai pour répondre : un changement plus chaud en reçoit un plus court.
- Un plafond absolu : un dialogue jamais remis est annulé dès qu'une limite de temps externe est dépassée.
- Garder pose un point de référence : le fichier reste tel qu'écrit et ce contenu exact est noté comme approuvé par vous, il n'est donc plus redemandé. Visible dans la console comme une approbation humaine.
Comment l'invite de confirmation utilisateur est protégée
Digne de confiance par le chemin que prend la question et par qui a le droit de répondre, ni l'un ni l'autre ne reposant sur un secret que du contenu empoisonné pourrait lire :
- Un canal local, jamais le réseau : un canal à identifiants de pair sur la machine elle-même, un socket de domaine Unix sous Linux et macOS ou un tube nommé sous Windows.
- Le noyau atteste qui répond : seule la session de bureau connectée peut répondre, revérifiée en direct à chaque réponse.
- Aucun jeton falsifiable : l'authenticité vient de la frontière de compte attestée par le noyau, non d'un nonce ou d'un jeton sur le fil.
| Plateforme | Comment le compte du répondant est attesté |
|---|---|
| Linux | Le noyau indique le compte qui se connecte (SO_PEERCRED), pris au moment de la connexion |
| macOS | Le noyau indique le compte qui se connecte (LOCAL_PEERCRED), rapproché de l'utilisateur de console actif |
| Windows | Le serveur de tube lit le jeton de compte du client (ImpersonateNamedPipeClient, niveau identification) |
À lire ensuite
Plus : les invites de confirmation utilisateur et les appareils sans écran, fail-closed, et ce que le mode Cloud envoie.
Une ligne, une question, et aucune réponse veut dire refus.
Vous ne voyez que le changement, Garder le note comme vôtre, et chaque refus est une quarantaine réversible. Gratuit pour Linux, macOS et Windows.
Sign me up