Q1 era el gate del proyecto (¿llegan los registros AUDIT_LANDLOCK_* a un lector?). Medido en el laptop (ABI 10) con scripts/harkaq/q1-audit.c: ✅ VIABLE. El multicast AUDIT_NLGRP_READLOG entrega blockers=fs.read_file path="/etc/passwd" dev="nvme1n1p6" ino=4458369 + exe=/comm= del que lo intentó. Es el diagnóstico de de-Alpinización que el SDD promete, saliendo del kernel sin instrumentar nada. Dos precondiciones que el Draft 2 no tenía, ambas medidas: - audit_enabled=1 NO viene de fábrica (sin audit=1 en cmdline, sin auditd) ⇒ cero registros de cualquier escenario. AUDIT_SET o audit=1 horneado. - LOG_NEW_EXEC_ON es OBLIGATORIO: same-exec=2 registros, new-exec=0, new-exec-logon=4. harkaq restringe y DESPUÉS execea el builder ⇒ sin el flag certificaría herméticos TODOS los builds, denials=[], sin un error. D9 (nueva, no negociable): el canario lo fabrica harkaq. Se investigó si el registro `deallocated denials=N` servía de verificación cruzada gratis: NO. Medido con ventana de 6s, un dominio con flags default y denegación post-exec no emite NADA (ni allocated, ni access, ni el contador); y el `allocated` es perezoso (llega pegado al primer denial logueado) ⇒ su ausencia tampoco prueba nada. Un build hermético y un lector ciego son bit-idénticos: denials=[]. El Verdict pasa a 3 estados (Hermetico / Impuro / SinEvidencia). El contador SÍ sirve para lo otro: nº ACCESS == denials caza registros perdidos por backlog (riesgo real con la granja en paralelo). Nota de método (§3.4): la 1ª corrida dio 0 en los 3 escenarios y "confirmaba" la hipótesis. Era el instrumento roto (AUDIT_GET con NLM_F_ACK: el ACK llegaba antes que la respuesta → enabled=-1 → nunca se encendía el audit). Se cazó sólo porque el CONTROL (same-exec) también dio 0, y eso era imposible. Es el modo de falla de harkaq en vivo sobre su propio banco. El test ahora aborta (exit 4) si no confirma audit_enabled=1. Nuevas Q1b (¿el lector ve a través del userns de bwrap? ¿cómo se atribuye un registro a SU build con la granja en paralelo?) y Q1c (privilegio de harkaq-audit). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2.1 KiB
harkaq — banco de pruebas
Ver docs/16-harkaq-jaula.md. Acá viven los experimentos que sostienen las afirmaciones del SDD:
si el doc dice "medido", el que lo midió está en este directorio.
q1-audit.c — el gate del proyecto (Q1, ✅ cerrado 2026-07-15)
Responde: ¿llegan los registros AUDIT_LANDLOCK_* a un lector? Todo harkaq cuelga de eso — su
producto es la evidencia, no la jaula.
gcc -O1 -Wall -o q1-audit q1-audit.c
for s in same-exec new-exec new-exec-logon; do sudo ./q1-audit $s; done
Necesita root (CAP_AUDIT_READ para leer el multicast, CAP_AUDIT_CONTROL para encender el
audit). Enciende audit_enabled=1 globalmente y no lo restaura — reversible, no persiste al
reboot (no toca el cmdline), pero deja dmesg más ruidoso mientras tanto.
Resultados en el laptop (ABI 10, kernel 7.2.0-rc3)
| Escenario | Registros ACCESS |
Qué prueba |
|---|---|---|
same-exec |
2 | el kernel loguea por defecto sin execve |
new-exec |
0 | flags por defecto ⇒ ciego tras execve — el caso real de harkaq |
new-exec-logon |
4 | LOG_NEW_EXEC_ON lo arregla |
Los registros traen blockers=fs.read_file path="/etc/passwd" dev="nvme1n1p6" ino=4458369 y el
exe= que lo intentó. Análisis completo en docs/16-harkaq-jaula.md §3.4.
Por qué aborta con código 4
Si no puede confirmar audit_enabled=1, aborta en vez de reportar 0 registros. No es
paranoia: la primera corrida dio 0 en los tres escenarios y parecía confirmar la hipótesis. Era un
bug del instrumento (AUDIT_GET con NLM_F_ACK → el ACK llegaba antes que la respuesta → nunca
se encendía el audit). Se detectó sólo porque el control (same-exec) también dio 0, y eso era
imposible.
Es el modo de falla de harkaq sobre su propio banco de pruebas: un sistema cuyo producto es la ausencia de algo no falla ruidosamente — dice que todo está bien. De ahí sale D9 (el canario deliberado), y de ahí sale la regla de este directorio: todo experimento lleva un control que debe dar positivo. Un experimento sin control no mide, tranquiliza.