takana/docs/16-harkaq-jaula.md

SDD 16 — harkaq: la jaula de hammer

Estado: Draft 2 · Fecha: 2026-07-15 · Nombre provisional: harkaq ("el que detiene"; renombrable, ningún identificador depende del nombre)

Qué cambió del Draft 1. El Draft 1 se escribió contra el sandbox de nix. hammer no usa nix para construir: usa bubblewrap (ADR 0004, crates/hammer-build/src/sandbox.rs). Eso invalidó por irrelevancia ~40% del documento — el argumento anti-nix, las FOD y su red abierta, y la fase del fetcher mediado que era el mayor riesgo de cronograma. Fase 0 (reconocimiento) se ejecutó y sus tres mediciones están en §3. El resultado neto es un proyecto más chico, más barato y con un beneficio que cobra antes. Lo que sobrevive intacto es el corazón: D1 (política derivada), D2 (evidencia negativa) y D3 (cero quieting).

Tesis: hammer es una distro cuyo autor es un modelo. Su sandbox (bwrap) fue diseñado para dar hermeticidad de facto — aislar el build del host — no para probar hermeticidad ni para acotar lo que el build usa de adentro de la jaula. harkaq cierra esa brecha sin pedirle política a nadie: la clausura de entradas declaradas de la receta ya es la política. El subproducto es más valioso que el producto — la ausencia de denegaciones bajo una política igual a la clausura es evidencia mecánica de que lo declarado basta, encadenable en willay y consumible por iniy.

---

0. Por qué esto no lo resuelve bwrap

El sandbox actual (sandbox.rs:224) hace bien lo que se propuso hacer:

• --unshare-all — netns, pidns, mountns, ipcns, utsns, userns. Sin red, ya hoy.
• --overlay-src <rootfs Alpine> [--overlay-src <dep>…] --tmp-overlay / — base y deps de solo lectura, escrituras a una capa tmpfs descartable.
• --bind <src> /src, --bind <out> /out — las únicas dos superficies RW reales.
• Entorno mínimo y fijado (SOURCE_DATE_EPOCH, CC, -mcpu=baseline, CARGO_BUILD_JOBS=1).

Eso da hermeticidad respecto del host. La brecha no está ahí. Está adentro:

El sandbox monta un rootfs Alpine entero como capa base del overlay.

O sea política ⊋ clausura, por un margen enorme. Una receta puede usar cualquier header, cualquier .so, cualquier binario que Alpine traiga — sin declararlo en deps — y el build pasa en verde. El artefacto queda sellado y reproducible, y aun así arrastra una dependencia fantasma que nadie escribió.

Ese no es un bug hipotético: es exactamente el bug que la campaña de de-Alpinización viene cazando a mano, receta por receta, leyendo logs y adivinando. El patrón documentado (strip makedepends, fase configure explícita, .pc Requires → [deps].build) es el parche manual de un problema que el kernel puede diagnosticar solo.

La inversión que hace hammer: el sandbox de bwrap asume que quien escribe la receta sabe lo que declaró. En hammer, quien escribe la receta es un modelo, la receta se importa automáticamente desde nixpkgs/Alpine, y "lo que declaró" es precisamente la parte que falla. Nadie más tiene ese problema porque nadie más tiene una distro cuyo autor sea un modelo.

No-tesis: esto no reemplaza a bwrap. harkaq compone con él (§5, D4): la jaula de mount y namespaces sigue siendo de bwrap; harkaq agrega la política de grano fino y —lo que importa— el canal de evidencia.

0.1 El lugar exacto en el modelo de confianza

De hammer-core/src/recipe.rs:229, sobre la evidencia H1 (proof-carrying recipes, SDD 15):

"Frontera honesta: garantiza que lo declarado pasa, no que lo declarado basta."

harkaq es el complemento simétrico de esa frase, y por eso encaja sin forzar nada:

	Pregunta	Mecanismo	Evidencia
H1	¿lo declarado pasa?	checks corridos en el sandbox	positiva (los checks pasan)
harkaq	¿lo declarado basta?	política = clausura, en el kernel	negativa (nadie denegó nada)

Juntas cierran el cuadro: H1 dice que el artefacto hace lo que dice; harkaq dice que no necesitó nada que no dijo. Ninguna de las dos pide confiar más en el modelo. Las dos piden verificar más — que es el principio declarado de SDD 15 §0.

---

1. Metas

1. Ejecutar el builder bajo una política derivada, no escrita: política = clausura(deps declaradas).
2. Producir, por cada build, un veredicto de hermeticidad con evidencia: hermético ⟺ política = clausura ∧ denegaciones = ∅.
3. Emitir esa evidencia hacia willay/iniy, direccionada por blake3, como un kind nuevo junto a la evidencia H1.
4. Convertir la de-Alpinización en un diagnóstico mecánico: cada denegación nombra el path, el dev y el ino de lo que el build usó sin declarar.
5. Degradación explícita y declarada: en kernel sin Landlock, harkaq marca el build sin evidencia — nunca finge.

2. No-metas

• No corre en wawa. Ver D6.
• No reemplaza el sandbox de bwrap; se compone encima. Defensa en capas.
• No es un contenedor de propósito general ni compite con bubblewrap/landrun.
• v1 no cubre macOS (hammer es musl/Linux).
• No promete contener un exploit de kernel. Ver §8.
• No reabre ADR 0004. hammer no adopta nix como backend de build. Esa opción sigue diferida y harkaq no la necesita.

---

3. Fase 0 — Reconocimiento: EJECUTADA (2026-07-15)

El Draft 1 estimaba "días". Fueron cinco minutos, porque las tres preguntas tenían respuesta mecánica. Las tres respuestas están medidas, no supuestas.

3.1 ABI de Landlock

Medido con el syscall (landlock_create_ruleset(NULL, 0, LANDLOCK_CREATE_RULESET_VERSION)), que es la vía correcta: los kernels de otras fuentes traen features backporteadas y el número de versión del kernel miente (RHEL 9.6 backporteó hasta ABI 5 sobre un 5.14).

Dónde	Kernel	ABI	Veredicto
Laptop de desarrollo	7.2.0-rc3-1-cachyos-rc	10	techo; todo disponible
Kernel de hammer	6.16.12-metal (recipes/linux.toml)	ausente	# CONFIG_SECURITY_LANDLOCK is not set

Lo que hace falta de cada ABI, y desde dónde:

ABI	Kernel	Qué trae	Para harkaq
2	5.19	FS_REFER	necesario — sin refer no compila nada real
3	6.2	FS_TRUNCATE	necesario
4	6.7	NET_BIND_TCP, NET_CONNECT_TCP	inerte — no hay red que filtrar (§6)
5	6.10	FS_IOCTL_DEV	cierra ioctls a dispositivos
6	6.12	SCOPE_ABSTRACT_UNIX_SOCKET, SCOPE_SIGNAL	corta fuga lateral
7	6.15	audit de denegaciones	este es el proyecto entero
8	7.0	RESTRICT_SELF_TSYNC	robustez (todos los hilos)
10	—	ADD_RULE_QUIET, quiet_access_*	deliberadamente NO usar (D3)

El hallazgo que ordena el diseño sigue siendo ABI 7: Linux 6.15 registra las peticiones denegadas vía audit con el motivo — domain, blockers (p.ej. fs.make_reg,fs.refer) y la identificación del objeto (path, dev, ino para filesystem; opid, ocomm para señales).

Traducción: el mecanismo de traza que el Draft 1 iba a construir ya lo hace el kernel. No hay que instrumentar syscalls ni interponer un tracer. La evidencia sale del audit log del propio LSM, que es un productor mucho más confiable que cualquier cosa en espacio de usuario.

3.2 El kernel de hammer: falta un flag, no una versión

store/060b34a6…-linux-metal/boot/config-6.16.12-metal dice:

# CONFIG_SECURITY_LANDLOCK is not set
CONFIG_LSM="landlock,lockdown,yama,loadpin,safesetid,selinux,smack,tomoyo,apparmor,ipe,bpf"
CONFIG_SECCOMP_FILTER=y

Respuesta a la Q2 del Draft 1 ("¿vale la pena forzar ≥6.15 en la distro?"): no hace falta forzar nada. 6.16.12 ya trae hasta ABI 8, y CONFIG_LSM ya lista landlock de primero. Falta sólo compilarlo: un scripts/config -e SECURITY_LANDLOCK junto a los otros ajustes de la fase configure de recipes/linux.toml (SECURITY_PATH entra por select). Cuesta un rebuild (~35min) y cambia el hash del kernel. Es el único trabajo de infraestructura del proyecto.

seccomp ya está =y en ambos kernels. No hay trabajo ahí.

3.3 Las FODs: no existen. El fetcher mediado: ya está construido

El Draft 1 dedicaba §6 entero + D8 al problema de las derivaciones de salida fija y su red abierta, y ponía el fetcher mediado en Fase 3 llamándolo "el mayor riesgo de alcance del proyecto", de "meses".

Ese trabajo está hecho desde siempre, por construcción:

• crates/hammer-build/src/download.rs corre curl en el host, fuera del sandbox.
• El builder recibe bytes vía --bind <src> /src. Nunca un socket.
• --unshare-all incluye --unshare-net: netns vacío para todo build, sin excepciones, porque no existe la categoría "derivación que necesita red".

Eso es la jaula con ventanilla que D8 proponía construir. hammer nunca tuvo el agujero de las FOD porque nunca tuvo FODs: separar el fetch del build fue una decisión temprana y silenciosa que resultó ser la correcta por razones de seguridad que nadie había escrito todavía. Queda escrita acá.

Fase 3 se elimina del plan. El riesgo de cronograma desaparece.

3.4 Q1 resuelta: la evidencia llega, con dos precondiciones y un canario obligatorio

Experimento scripts/harkaq/q1-audit.c (2026-07-15), corrido en el laptop (ABI 10). Tres escenarios: denegación sin execve, con execve y flags por defecto, y con execve + LANDLOCK_RESTRICT_SELF_LOG_NEW_EXEC_ON.

La evidencia llega, y es exactamente la que el diseño necesita. Un lector no privilegiado del grupo multicast AUDIT_NLGRP_READLOG recibe:

domain=146973ef2 blockers=fs.read_file path="/etc/passwd" dev="nvme1n1p6" ino=4458369
domain=146973ef2 status=allocated mode=enforcing pid=3359 uid=0 exe="…/q1-audit" comm="q1-audit"

blockers + path + dev + ino + el exe que lo intentó. Ese registro es el diagnóstico de de-Alpinización de §0, y sale del kernel sin instrumentar nada.

Precondición 1 — audit_enabled=1. Medido: el laptop arranca con audit_enabled=0 (sin audit=1 en el cmdline, sin auditd). Con audit apagado no se emite ningún registro, de ningún escenario. Se enciende con AUDIT_SET por netlink (CAP_AUDIT_CONTROL) o con audit=1 en el cmdline — que para el kernel de hammer es horneable, igual que el resto del cmdline metal.

Precondición 2 — LOG_NEW_EXEC_ON es obligatorio, y su ausencia es indetectable. Medido:

Escenario	Registros ACCESS
same-exec (sin execve)	2 — logueado por defecto
new-exec (flags por defecto)	0
new-exec-logon (LOG_NEW_EXEC_ON)	4

Misma jaula, misma denegación, cat rebotó con EACCES en los tres. harkaq restringe y después hace execve del builder (bwrap → /bin/sh -c → make → zig cc): es el caso new-exec. Sin el flag, harkaq certificaría como herméticos todos los builds, denials=[], para siempre, sin un solo error visible. El flag no es configuración: es la diferencia entre el sistema y un sello de goma.

No hay canario gratis en el kernel. Se investigó si el registro status=deallocated denials=N podía servir de verificación cruzada. Medido, con una ventana de escucha de 6s: un dominio con flags por defecto cuya única denegación es post-exec no emite absolutamente nada — ni allocated, ni access, ni el deallocated con su contador. El contador existe sólo para dominios que ya loguean. Y el allocated se emite perezosamente, pegado al primer denial logueado (mismo evento de audit), así que un build genuinamente limpio tampoco lo produce: su presencia no puede usarse como prueba de que los flags tomaron.

⇒ D9 (nueva decisión cerrada, abajo): el canario lo fabrica harkaq.

Lo que el contador sí resuelve, cuando el logging está bien puesto: exigir nº de registros ACCESS recibidos == denials del deallocated detecta registros perdidos por desborde del backlog de audit — un riesgo real con la granja construyendo en paralelo. Son dos chequeos para dos fallas distintas (mala configuración vs. pérdida), y hacen falta los dos.

Nota de método, que vale más que el resultado. La primera corrida del experimento dio 0 registros en los tres escenarios y parecía confirmar la hipótesis. Era un bug del instrumento: el AUDIT_GET pedía NLM_F_ACK, el ACK llegaba antes que la respuesta (el kernel la manda asíncrona), el lector lo tomaba por fallo, enabled quedaba en -1, la rama que encendía el audit nunca corría y el kernel no emitía nada. Sólo se detectó porque el control (same-exec, que debía loguear) también dio 0, y eso era imposible.

Es el modo de falla de harkaq, en vivo, sobre su propio banco de pruebas: un sistema cuyo producto es la ausencia de algo no se rompe ruidosamente — dice que todo está bien. El experimento ahora aborta con código 4 si no puede confirmar audit_enabled=1, en vez de reportar cero. La misma disciplina es la que D9 le impone a harkaq.

---

4. Arquitectura

 receta (escrita/importada por el agente)
        │
        ├─ deps declaradas (paths del store, por hash)
        │
        ▼
 ┌──────────────────────────────────────────────────────────┐
 │ harkaq-policy   (puro, testeable sin kernel)             │
 │   clausura(deps) → PolicySpec {                          │
 │      fs_ro:   [store paths de la clausura + base runtime]│
 │      fs_rw:   [/src, /out, /tmp, /cache]                 │
 │      scoped:  UNIX_ABSTRACT | SIGNAL                     │
 │   }                                                      │
 │   PolicyId = blake3(postcard(PolicySpec))                │
 └───────────────────────────┬──────────────────────────────┘
                             ▼
 ┌──────────────────────────────────────────────────────────┐
 │ harkaq-exec     (musl, Rust) — DENTRO de bwrap           │
 │   bwrap ya dio: ns, overlay, /src, /out, sin red         │
 │   1. landlock: PolicySpec → ruleset (best-effort/ABI)    │
 │   2. seccomp-bpf: allowlist (D4), vía --seccomp <fd>     │
 │   3. no_new_privs, drop caps, exec builder               │
 └───────────────────────────┬──────────────────────────────┘
                             ▼
 ┌──────────────────────────────────────────────────────────┐
 │ harkaq-audit    (lector de AUDIT_LANDLOCK_*)             │
 │   denegaciones → Denial { blockers, path, dev, ino, ... }│
 └───────────────────────────┬──────────────────────────────┘
                             ▼
        Verdict { PolicyId, recipe_hash, artifact_hash, denials[] }
                             │
              blake3 ──► CAS ──► willay ──► iniy

Ley de dependencia: harkaq-policy no conoce el kernel (función pura de Recipe → PolicySpec, testeable con cargo test en cualquier máquina, incluso sin Landlock). harkaq-exec no conoce la receta. El acoplamiento vive sólo en hammer-build.

Nota de encaje: Sandbox::bwrap_args ya construye la lista de deps (self.deps) — es literalmente el input de clausura(). Y merge_deps_layer() ya las funde en una capa. El PolicySpec se deriva de datos que la struct Sandbox ya tiene en la mano.

---

5. Decisiones cerradas

D1 — La política se deriva, no se escribe

Es el corazón, y sobrevive al Draft 1 sin un rasguño. Todo sandbox del mundo muere en la ergonomía: alguien mantiene a mano un perfil de permisos, nadie lo revisa, todos terminan en permisivo. hammer no tiene ese problema porque la receta ya declara sus deps por hash. clausura(deps) es el conjunto exacto de rutas de solo lectura. Cero configuración humana, precisión igual a la del direccionamiento por contenido.

Corolario: no existe "modo permisivo". Una receta que necesita más de lo que declara está mal escrita, y ese es exactamente el diagnóstico que queremos que el agente reciba — hoy lo producimos leyendo logs a mano y llamándolo de-Alpinización.

D2 — La evidencia es negativa, y por eso es barata

No se traza lo permitido. La tentación es loguear todo acceso para "probar" qué tocó el build; eso exige fanotify o eBPF, cuesta rendimiento y produce un río de datos que nadie audita.

La formulación correcta es la contrapositiva:

hermético(build) ⟺ política = clausura(deps) ∧ denegaciones = ∅

Si la política concede exactamente la clausura declarada y el kernel no denegó nada, entonces el build no usó nada fuera de lo declarado. La política es la afirmación; la ausencia de denegaciones es la prueba. Coste de la traza: un lector de audit y una lista casi siempre vacía.

Esto convierte la reproducibilidad de hammer, que hoy es una promesa arquitectónica verificable sólo rebuildeando, en un certificado por build.

D3 — Cero quieting. Las denegaciones son el producto

ABI 10 permite suprimir selectivamente logs de accesos denegados por objeto (LANDLOCK_ADD_RULE_QUIET, campos quiet_access_*). Es una feature excelente para sandboxear apps de escritorio ruidosas — y veneno para harkaq. Silenciar una denegación es destruir la única evidencia que produce el sistema. En harkaq quiet_* está prohibido por diseño; una denegación esperada no se calla, se clasifica en el Verdict.

(De la propia doc del kernel: el objeto queda marcado como quiet si al menos una llamada lo pidió, y llamadas posteriores sin el flag no lo limpian — es pegajoso. Razón extra para no tocarlo.)

Este laptop reporta ABI 10, así que la feature está a un flag de distancia. La disciplina es no usarla.

D4 — Landlock no basta; seccomp es obligatorio, no opcional

Landlock cubre fs, puertos TCP e IPC scoping. No cubre ptrace, bpf, userfaultfd, keyctl, io_uring, montajes, ni la mitad de la superficie interesante. seccomp-bpf con allowlist por syscall es la otra mitad de la jaula.

Buena noticia de composición: bwrap acepta --seccomp <fd>. No hay que reemplazar el launcher; se le pasa el filtro al que ya tenemos. CONFIG_SECCOMP_FILTER=y en ambos kernels.

io_uring va explícitamente denegado en v1 (superficie de kernel enorme, y bypassea buena parte del análisis por-syscall). Si un builder lo necesita, que lo justifique.

D5 — Herencia y TSYNC

Las restricciones de Landlock se heredan automáticamente por fork() y exec(), así que todo el árbol de procesos del build queda contenido sin trabajo extra — que es exactamente lo que hace falta cuando Sandbox::run lanza /bin/sh -c que lanza make que lanza zig cc. Con ABI 8 disponible (6.16.12 lo tiene), usar RESTRICT_SELF_TSYNC para cubrir todos los hilos.

D6 — harkaq es órgano de hammer, no de la suite. Rompe la paridad wawa, y está bien

Landlock, seccomp y cgroups son Linux puro; en x86_64-unknown-none no existen. Esto viola el principio de paridad Linux/wawa que gobierna el resto del ecosistema, y hay que decirlo en voz alta antes de que alguien lo cobre.

El costo es aceptable porque el bucle de build del agente es una actividad Linux por definición. wawa nunca compila nada: consume artefactos atestados del CAS. La frontera de confianza de wawa es la atestación; la de hammer es la jaula. Son mecanismos distintos para posiciones distintas del pipeline, y eso es coherente, no inconsistente.

D7 — Fallo cerrado, y honesto sobre el ABI

• abi_minima = V3 para intentar el build (sin REFER y TRUNCATE no compila software real).
• abi_evidencia = V7 para emitir un Verdict con evidencia.
• Entre V3 y V7: el build corre, el Verdict sale SinEvidencia, iniy lo trata con uncertainty alta en vez de creerle.
• Sin Landlock (el kernel de hammer hoy): SinEvidencia, y el build corre igual bajo el bwrap de siempre. harkaq es inerte, no un muro.

Nunca se emite evidencia que el kernel no respaldó. Se consulta el ABI con el syscall, jamás uname.

D8 — La red ya está cerrada; harkaq no la toca

(Reemplaza al D8 del Draft 1, que trataba de las FOD.)

--unshare-all ⇒ netns vacío ⇒ los derechos de red de ABI 4 son inertes. No se implementan. Si algún día un build necesitara red, la respuesta no es abrir el netns: es extender el fetcher del host (§3.3), que es el embudo con hash donde ancla el CAS y donde willay puede auditar.

SCOPE_ABSTRACT_UNIX_SOCKET (ABI 6) sí se usa: cierra la fuga simétrica hacia sockets abstractos. Ojo con la semántica documentada — un socket datagram ya conectado antes del scoping puede seguir enviando; y el scoping no admite reglas: si un dominio está scoped, no hay forma de permitir un recurso puntual fuera. Es todo-o-nada, lo cual para nosotros está bien.

D9 — El canario deliberado: denials=[] no se cree, se gana

(Nace de la medición de §3.4. Es la decisión que Q1 obligó a tomar.)

El problema. Un build hermético y un lector ciego producen exactamente los mismos bytes: denials=[]. Y §3.4 midió que el kernel no ofrece ninguna forma de distinguirlos — un dominio sin logging es invisible, y el registro allocated es perezoso, así que su ausencia tampoco prueba nada. Sin resolver esto, D2 (la evidencia negativa) no vale nada: la afirmación más fuerte del sistema sería indistinguible de su falla más común.

La decisión. Cada build provoca una denegación conocida, después del execve, y harkaq exige verla. El canario es un path que existe en el sandbox y que la política deja deliberadamente fuera de la clausura (p.ej. un --ro-bind a una ruta fija que el ruleset no concede). El probe se antepone al comando del builder — misma vía que Sandbox::run ya usa (/bin/sh -c), así que corre en el dominio y del lado correcto del exec.

El veredicto pasa a ser de tres estados, no de dos:

Canario	Otras denegaciones	Veredicto
visto	∅	Hermetico — y ahora sí significa algo
visto	≥1	Impuro { denials } — el diagnóstico útil
no visto	cualquiera	SinEvidencia — el lector no es confiable; no se afirma nada

El canario cubre la mala configuración (flag ausente, audit apagado, lector caído). El contador deallocated denials=N de §3.4 cubre la otra falla, la pérdida de registros por backlog: se exige nº de ACCESS == N. Dos chequeos, dos fallas, ninguno redundante.

Por qué es un no-negociable. Es la misma disciplina de D7 (fallo cerrado) y de D3 (cero quieting), aplicada al único punto donde el sistema podría mentirse a sí mismo en silencio. Y no es hipotético: el banco de pruebas de Q1 ya cayó en esa trampa una vez (§3.4, nota de método).

---

6. Fases

Fase 0 — Reconocimiento. ✅ CERRADA (2026-07-15). Ver §3. Salidas: ABI 10 en el laptop, Landlock ausente-pero-a-un-flag en el kernel de hammer, cero FODs y fetcher ya construido.

Fase 1 — El hito demostrable (una tarde). Precondiciones, todas ya medidas en §3 y ninguna especulativa:

1. scripts/config -e SECURITY_LANDLOCK en recipes/linux.toml (+ rebuild, ~35min, cambia el hash).
2. audit=1 horneado en el cmdline del kernel metal — o AUDIT_SET desde hammerd (§3.4, Q1c).
3. LANDLOCK_RESTRICT_SELF_LOG_NEW_EXEC_ON en el restrict_self (§3.4). Sin esto no hay nada.
4. El canario de D9 antepuesto al comando del builder.

Después: tomar una receta real de hammer. Derivar su política de la clausura. Correrla bajo Landlock+seccomp dentro del bwrap actual. Emitir el Verdict con denials = [] y el canario visto. Luego correr una receta que sepamos no de-Alpinizada y mostrar que la jaula nombra exactamente qué usó sin declarar, con path/dev/ino. Ese par de corridas es el argumento entero del proyecto, y se enseña en dos minutos.

Cambio respecto del Draft 1: el segundo acto era una derivación de juguete que leía /etc/passwd. Una receta real no de-Alpinizada es mejor demo (es el problema que de verdad tenemos) y de paso le entrega valor inmediato a una campaña en curso.

Fase 2 — harkaq-policy completo + medir la brecha. Clausura real, /src, /out, /tmp, /cache, /proc y /dev mínimos, y el runtime base (sin /bin/sh ni la libc del rootfs no arranca nada — ver Q3). Correr contra N recetas del catálogo y medir la tasa de falsos positivos. Métrica de éxito: <5% de recetas necesitan excepción. El delta entre política = clausura y política = clausura + base Alpine es la medida cuantitativa de la deuda de de-Alpinización del catálogo. Ese número no existe hoy.

Fase 3 — El bucle epistémico. Verdict → willay → iniy, como kind nuevo junto a la evidencia H1 (§0.1). Aquí el agente empieza a recibir su propio reflejo: una receta cuyo build denegó cosas es una receta de la que el sistema desconfía, y esa desconfianza es un número, no una vibra.

(La Fase 3 del Draft 1 —el fetcher mediado— se eliminó: ya existe. Ver §3.3.)

---

7. Riesgos y honestidades

• El kernel es la TCB. harkaq no contiene un exploit de kernel. Landlock+seccomp reduce superficie; no la elimina. Si el modelo de amenaza incluye "la IA encuentra un 0-day de kernel", la respuesta correcta es microVM, no LSM. Decir esto en el README, no en letra chica.
• La entrega de la evidencia es el único riesgo técnico serio que queda. Ver Q1. Todo el proyecto cuelga de poder leer los registros AUDIT_LANDLOCK_* de forma confiable desde el proceso que orquesta el build. Si eso no se resuelve limpio, harkaq queda sin producto.
• Falsos positivos matan proyectos de sandboxing. Si el 30% de los builds necesita excepción manual, harkaq se desactiva y queda como decoración. La Fase 2 existe para descubrir esto temprano y barato. Atenuante: acá un "falso positivo" suele ser un verdadero positivo de de-Alpinización, y el catálogo tiene ~750 recetas para probarlo.
• Domesticar el vocabulario. harkaq no prueba que un build fue hermético. Prueba que bajo el supuesto de que el kernel y la derivación de política son correctos, el build no accedió fuera de su clausura declarada. Es una afirmación fuerte y defendible. La versión sin asteriscos es la que te van a cobrar. (Mismo criterio que SDD 15 §0: "verificado bajo supuestos nombrados".)
• Competencia. Como proyecto OSS genérico, "sandbox para agentes" es un espacio poblado (ya existe landrun) y la ventana no es infinita. Como el ejecutor de hammer, no compite con nadie: el diferenciador no es la jaula, es que la política sale del hash y la evidencia entra al grafo de confianza. Nadie más tiene CAS + log monótono + grafo para cerrar ese bucle.
• El rebuild del kernel cambia su hash. Encender SECURITY_LANDLOCK invalida 060b34a6…-linux-metal y lo que dependa de él. Es esperado y barato, pero hay que agendarlo, no descubrirlo.

---

8. Preguntas abiertas

• Q1 — ✅ CERRADA (2026-07-15). La evidencia llega, con blockers/path/dev/ino/exe, por el multicast AUDIT_NLGRP_READLOG. Precondiciones medidas: audit_enabled=1 (no viene de fábrica) y LOG_NEW_EXEC_ON (sin él, cero registros tras el exec). No hay canario gratis ⇒ D9. Detalle y mediciones en §3.4. El gate del proyecto está pasado: harkaq es viable.
• Q1b (Fase 1, lo que Q1 destapó): ¿el lector funciona igual con el build dentro del userns de bwrap? El audit no está namespaceado, así que harkaq-audit lee desde el host (junto a hammerd) y debería ver los denials de adentro — pero hay que medirlo, no suponerlo. Y de paso: ¿cómo se atribuye un registro a su build cuando la granja corre varios en paralelo? El campo domain= es la clave candidata; el pid= del allocated es el puente, pero §3.4 midió que ese registro es perezoso. Riesgo concreto: sin atribución fiable, los builds paralelos se contaminan la evidencia entre sí.
• Q1c: ¿quién corre harkaq-audit y con qué privilegio? Necesita CAP_AUDIT_READ (leer) y CAP_AUDIT_CONTROL (encender el audit, si no se hornea audit=1 en el cmdline). En el laptop hizo falta root. ¿hammerd ya lo tiene, o hace falta un helper con capabilities acotadas?
• Q2 (Fase 2): ¿qué es exactamente el "runtime base" que toda receta necesita y ninguna declara (/bin/sh, la libc del rootfs, /opt/zig)? ¿Va en la clausura implícitamente, o se declara y se vuelve parte del hash de la receta? Esta es la decisión de diseño de verdad, y determina si la métrica de la Fase 2 mide deuda real o ruido.
• Q3 (Fase 2): ¿/proc y /dev mínimos rompen builds reales? (/proc/self suele hacer falta; /proc/sys casi nunca.) bwrap ya monta --proc /proc --dev /dev.
• Q4: ¿el Verdict entra en Recipe::hash_inputs? Por simetría con Evidence (H1), no: hermeticidad es comportamiento, no identidad. Confirmar con el mismo criterio de recipe.rs:228.

(Las Q1/Q4/Q5 del Draft 1 —el vector page-cache de copy.fail, la fracción de FODs, y si harkaq envuelve o reemplaza a nix— se eliminan: eran todas sobre nix.)