Responder a la solicitud de confirmación del usuario
Cuando un cambio no es ni claramente seguro ni un ataque probado, el agente poison0 lo retiene y pregunta. Esta página trata de responder: qué muestra la solicitud de confirmación del usuario, qué hacen Conservar y Rechazar, y por qué no responder es un rechazo.
Qué muestra la solicitud de confirmación del usuario
La solicitud muestra solo la línea añadida, citada del archivo para que nunca suene como si hablara el agente poison0:
| Mostrado | Significado |
|---|---|
| Archivo | La ruta completa del archivo modificado |
| Cambiado | Cuándo se añadió la línea, según los datos |
| La nueva línea | Solo la línea añadida, citada literalmente; el resto del archivo no se muestra |
| Recomendación | Una frase sencilla; nada te empuja a Conservar |
Solo se muestra la línea añadida, no el archivo entero ni una puntuación. Cuándo decide preguntar el agente poison0 se trata en las solicitudes de confirmación del usuario.
Conservar o rechazar
Dos botones, cada uno nombra lo que le ocurre a la línea retenida:
| Respuesta | Resultado |
|---|---|
| Conservar | El contenido permanece y queda registrado como aprobado por ti. Ese contenido exacto pasa a ser el nuevo punto de referencia: el mismo hallazgo no se vuelve a plantear, y la aprobación es visible en la consola. |
| Rechazar | La línea se elimina y el archivo vuelve a su estado seguro. En cuarentena, no borrado, recuperable. |
| Sin respuesta | Se trata como Rechazar: vuelta al estado seguro. |
No responder es un rechazo. Un tiempo agotado, pulsar Escape, cerrar el diálogo, un diálogo que apareció mientras escribías, o ningún escritorio donde mostrarlo: todo camino que no sea un Conservar explícito revierte el cambio.
La ventana de retención
- Retenido, no aplicado: el archivo conserva su último contenido limpio hasta que elijas Conservar.
- Un plazo para responder: un cambio más caliente recibe uno más corto.
- Un tope absoluto: un diálogo que nunca se entregó se revierte en cuanto pasa un límite de tiempo externo.
- Conservar fija un punto de referencia: el archivo queda como se escribió y ese contenido exacto queda registrado como aprobado por ti, así que no se vuelve a preguntar. Visible en la consola como una aprobación humana.
Un rechazo es una cuarentena reversible: uno por error no cuesta más que volver a escribir la línea. La postura de seguro por defecto es fail-closed.
Cómo se protege la solicitud de confirmación del usuario
Fiable por el camino que recorre la pregunta y por quién puede responder, sin que ninguno dependa de un secreto que el contenido envenenado pudiera leer:
- Un canal local, nunca la red: un canal de credenciales de par en la propia máquina, un socket de dominio Unix en Linux y macOS o una tubería con nombre en Windows.
- El núcleo avala quién responde: solo la sesión de escritorio con sesión iniciada puede responder, comprobada en vivo con cada respuesta.
- Ningún token falsificable: la autenticidad viene de la frontera de cuenta avalada por el núcleo, no de un nonce o un token en el cable.
| Plataforma | Cómo se avala la cuenta de quien responde |
|---|---|
| Linux | El núcleo indica la cuenta que se conecta (SO_PEERCRED), tomada en el momento de conectar |
| macOS | El núcleo indica la cuenta que se conecta (LOCAL_PEERCRED), cotejada con el usuario de consola activo |
| Windows | El servidor de la tubería lee el token de cuenta del cliente (ImpersonateNamedPipeClient, nivel de identificación) |
Un agente o un archivo envenenado no puede fingir un Conservar. Poder conectarse no prueba nada; solo se acepta una respuesta de la cuenta activa con sesión iniciada.
Lee a continuación
Más: las solicitudes de confirmación del usuario y los dispositivos sin pantalla, fail-closed y qué envía el modo Cloud.