From ec7ceb0915f28c50f35472087d36d958cafe09a1 Mon Sep 17 00:00:00 2001 From: sergio Date: Thu, 16 Jul 2026 22:17:01 -0400 Subject: [PATCH] =?UTF-8?q?harkaq:=20Q1-copy.fail=20RESPONDIDA=20=E2=80=94?= =?UTF-8?q?=20fs-verity=20mata=20el=20vector=20page-cache?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit El SDD 16 dejó abierto: '¿el vector page-cache de copy.fail sobrevive a un ruleset que deniegue escritura a nivel de inode? Investigar antes de afirmar nada'. Investigado en un fs AISLADO (loop en un worker efímero, nunca el fs del usuario): escribir al artefacto sellado → EPERM dd como ROOT → Operation not permitted (ni root) machacar los bytes POR DEBAJO (device)+leer→ Input/output error El tercero ES el vector de copy.fail: modificar el fichero por debajo del fs. El kernel detecta la corrupción AL LEER (el Merkle no cuadra) y rechaza la lectura. ⇒ fs-verity mata el vector. Landlock read-only no alcanzaba; fs-verity sí. Costo medido, y corrige al SDD 17 §5: 'hash = identidad' es FALSO — fs-verity usa Merkle SHA-256, hammer direcciona con BLAKE3 ⇒ son DOS hashes, no uno. Y ext4 exige -O verity Y blocksize = PAGE_SIZE (con 1024 el mount falla: 'Unsupported blocksize for fs-verity'). No es gratis, pero es barato para lo que da. NO se tocó el fs del laptop (habilitar verity pediría tune2fs sobre la partición del usuario): el experimento corrió en un loop device de un worker descartable. Co-Authored-By: Claude Opus 4.8 --- docs/16-harkaq-jaula.md | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/docs/16-harkaq-jaula.md b/docs/16-harkaq-jaula.md index c697ebf7..4656317a 100644 --- a/docs/16-harkaq-jaula.md +++ b/docs/16-harkaq-jaula.md @@ -1027,6 +1027,25 @@ vibra. ## 8. Preguntas abiertas +- **Q1-copy.fail — ✅ RESPONDIDA (2026-07-16) con fs-verity.** El SDD dejó abierto: *«¿el vector + page-cache de `copy.fail` sobrevive a un ruleset que deniegue escritura a nivel de inode? + Investigar antes de afirmar nada»*. **Investigado, en un fs aislado (loop, nunca el fs real):** + + | ataque | resultado | + |---|---| + | escribir al artefacto sellado | `EPERM` | + | `dd` como **root** | `Operation not permitted` — ni root | + | **machacar los bytes POR DEBAJO** (en el device) y leer | **`Input/output error`** | + + El tercero es el vector de `copy.fail`: se modifica el fichero por debajo del filesystem. **El + kernel detecta la corrupción al leer** (el Merkle no cuadra) y rechaza la lectura. ⇒ **fs-verity + mata el vector**; Landlock read-only no alcanzaba, fs-verity sí. + + **Costo medido, contra lo que dice el SDD 17 §5:** *«hash = identidad»* es **falso** — fs-verity + usa un Merkle **SHA-256** y hammer direcciona con **BLAKE3**: son **dos** hashes, no uno. Y en + ext4 exige `-O verity` **y blocksize = PAGE_SIZE** (con 1024 el mount falla: + `Unsupported blocksize for fs-verity`). No es gratis, pero es barato para lo que da. + - **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 ⇒