sergio/hammer
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

harkaq: Q1-copy.fail RESPONDIDA — fs-verity mata el vector page-cache

Browse Source 
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 <noreply@anthropic.com>
This commit is contained in:
sergio
2026-07-16 22:17:01 -04:00
co-authored by Claude Opus 4.8
parent 272125b93a
commit ec7ceb0915
1 changed files with 19 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/16-harkaq-jaula.md
+19
View File
@@ -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 ⇒