attestos

# attestos

Harness experimental de imagen y evidencia de arranque atestiguado para Linux,
con el fin de probar qué podría verificar un proveedor de anti-trampas en lugar
de depender de una lista de permisos basada en el nombre de la distribución.

El mecanismo, el modelo de amenaza y la especificación para el proveedor viven
en [plunder707/attested-gaming](https://github.com/plunder707/attested-gaming).
Este repositorio es la imagen que produce la evidencia.

---

> ## ESTADO: VISTA PREVIA DE MECÁNICA DE CÓDIGO FUENTE. NO INSTALABLE NI CONFIABLE PARA PRODUCCIÓN.
>
> Las ejecuciones de GitHub Actions
> [31157890393](https://github.com/plunder707/attestos/actions/runs/31157890393)
> y [31159951490](https://github.com/plunder707/attestos/actions/runs/31159951490)
> construyeron un QCOW2 derivado de Bazzite, lo arrancaron bajo QEMU/OVMF con
> swtpm y sin red invitada, aprovisionaron identificadores persistentes de EK/AK
> y verificaron una cita (quote) cruda sobre los PCR 7, 11, 12 y 15 de SHA-256
> desde dentro del invitado. Su recibo acotado tiene SHA-256
> `ad5ef12592cb5f4d1dfa8f0da88148931d48f0e6018924b2de4c766e1523ddaf`.
> Un flujo de trabajo verificador separado
> [31160003873](https://github.com/plunder707/attested-gaming/actions/runs/31160003873)
> ejercitó el commit final del agente `b918392` de este repositorio contra un
> TPM de software aislado y superó la inscripción de AK, la verificación de
> cita cruda, el rechazo de reproducción, el rechazo de manipulación de firma y
> el cableado de TPM QEMU/OVMF.
>
> El resultado arrancado también confirma el bloqueo de política de Bazzite: no
> había ningún archivo UKI ni señal de systemd-stub, faltaban los argumentos de
> bloqueo previstos, y los PCR 11 y 15 seguían en cero. El PCR 12 también estaba
> en cero, pero eso no es un fallo independiente: la línea de comandos UKI
> integrada pertenece al PCR 11, mientras que el PCR 12 registra entradas de
> línea de comandos externas y puede permanecer correctamente en cero cuando no
> se suministra ninguna. La inscripción de claves de Secure Boot, la medición de
> línea de comandos respaldada por UKI, la procedencia del hardware, la
> reproducción del registro de eventos, la vinculación del transporte y la
> admisión por política de arranque siguen sin resolverse. Ninguna de las dos
> ejecuciones en verde establece un sistema de atestación de producción
> funcional.
>
> Un control positivo separado de imagen sellada de Fedora pasó dos veces en
> [run 31218059725](https://github.com/plunder707/attestos/actions/runs/31218059725)
> y de nuevo en la cabecera de la fuente fusionada en
> [run 31219745053](https://github.com/plunder707/attestos/actions/runs/31219745053).
> Demuestra que el harness puede arrancar un UKI inmutable firmado por el
> proyecto ascendente, incorporar la ruta seleccionada por el firmware y el hash
> del archivo cargado a la inspección previa al arranque, observar un PCR 11
> distinto de cero y rechazar una mutación de `.cmdline` sin firmar. Esto es
> solo un control del harness: todas las marcas de confianza de fabricante,
> política y producción siguen siendo falsas, y no hace instalable la vista
> previa de Bazzite.
>
> El carril separado de complemento de política PCR 12 firmado pasó después dos
> veces en
> [run 31234464516](https://github.com/plunder707/attestos/actions/runs/31234464516).
> El UKI ascendente y el PCR 11 permanecieron byte-idénticos; ambos arranques
> firmados aplicaron `lockdown=confidentiality module.sig_enforce=1`
> exactamente una vez y reprodujeron el PCR 12 `ca62dd5f...a8f5`; la
> manipulación posterior a la firma fue rechazada y se volvió a la línea base de
> PCR 12 en cero. Esto prueba un mecanismo acotado, no una jerarquía de claves
> desplegable ni una política de confianza del sistema operativo.
>
> Este código fuente está disponible para revisión y emulación reproducible. No
> se publica ninguna imagen GHCR y no es una distribución confiable instalable.

El experimento completado de Bazzite se especifica en
[`BOOTED_IMAGE_CANARY.md`](https://github.com/plunder707/attestos/blob/main/BOOTED_IMAGE_CANARY.md). Las instrucciones de
reproducción y construcción desde el código fuente están en
[`BUILDING.md`](https://github.com/plunder707/attestos/blob/main/BUILDING.md). La evidencia base del UKI y sus criterios
independientes de admisión se registran en
[`UKI_BASE_DECISION.md`](https://github.com/plunder707/attestos/blob/main/UKI_BASE_DECISION.md). El experimento firmado del
complemento de política PCR 12 se especifica por separado en
[`FEDORA_PCR12_ADDON_CANARY.md`](https://github.com/plunder707/attestos/blob/main/FEDORA_PCR12_ADDON_CANARY.md).
El orden de hitos y las reglas de parada se controlan en
[`ROADMAP.md`](https://github.com/plunder707/attestos/blob/main/ROADMAP.md).
El control del harness de UKI cargado por separado se especifica en
[`FEDORA_SEALED_POSITIVE_CONTROL.md`](https://github.com/plunder707/attestos/blob/main/FEDORA_SEALED_POSITIVE_CONTROL.md).

---

## Qué añade esto a Bazzite

No se elimina nada y no se parchea nada. Se añaden cuatro cosas encima:

1. **`tpm2-tools` y `tpm2-tss`**, que el agente necesita en tiempo de ejecución.
2. **Una línea de comandos de kernel** en `/usr/lib/attestos/cmdline` con
   `lockdown=confidentiality` y `module.sig_enforce=1`.
3. **`attestos-provision`**, una unidad de una sola pasada que crea
   identificadores persistentes distintos de EK y AK RSA dentro del TPM y lee
   el certificado de respaldo del almacenamiento NV cuando existe.
4. **`attestos-agent`**, activado por socket en bucle local, que responde a un
   desafío estricto de identidad, activación o cita `attestos.tpm/v1` con
   evidencia TPM cruda. El agente nunca emite un veredicto de confianza.

## Por qué la base es Bazzite

Bazzite se deriva de Fedora, y la familia Fedora es lo que las listas de
permisos de anti-trampas bloquean actualmente. Demostrar que la atestación
funciona aquí es el caso que vale la pena demostrar. Construir sobre SteamOS no
demostraría nada, porque SteamOS ya está permitido, por lo que una demo exitosa
allí conseguiría un acceso que ya tiene.

Bazzite también está diseñado para ser superpuesto en capas. Es una imagen OCI,
así que este repositorio es un Containerfile y una Acción de GitHub en lugar de
una distribución con espejos e instaladores detrás.

## La política tiene que estar autenticada y medida antes del kernel

Esta es la parte que decide si todo esto significa algo.
`lockdown=confidentiality` bloquea `/dev/mem`, los kprobes contra un kernel en
ejecución y la carga de módulos sin firmar. Esa garantía no vale nada si la
política vive solo en una configuración de cargador de arranque que el usuario
puede editar. De lo contrario, un usuario puede eliminar los argumentos, arrancar
la misma medición de kernel y presentar una cita que no dice nada sobre la
política ausente.

Una imagen de kernel unificada (UKI) vincula kernel, initrd y su línea de
comandos integrada en un único binario PE firmado medido en el PCR 11. Un
complemento de línea de comandos de systemd firmado por separado puede extender
política adicional al PCR 12 dejando ese UKI ascendente sin cambios. Cualquiera
de las dos rutas debe unirse al artefacto cargado exacto y ser reproducida por el
verificador; la presencia de un archivo o un PCR distinto de cero no basta.

**Bazzite no usa UKI, y esto ahora está confirmado en lugar de sospechado.**
Su Containerfile excluye activamente los paquetes de kernel UKI:

```
dnf5 -y config-manager setopt "*fedora*".exclude="mesa-* kernel-core-* \
    kernel-modules-* kernel-uki-virt-* steam"
```

`systemd-ukify` no aparece en ningún lugar del repositorio. Así que el archivo
`cmdline` que esta imagen incluye es actualmente una declaración de intención y
nada más: sin un UKI no hay nada que lo selle, un usuario puede editarlo en el
cargador de arranque, y el PCR 11 no mide lo que el diseño supone que mide.

Arreglar Bazzite no es una línea en `build.sh`. Requiere una ruta de medición
pre-kernel confiable, ya sea cambiando cómo arranca la imagen o adoptando una
base que ya arranca a través de systemd-stub.

Los experimentos reducen las opciones prácticas:

1. Hacer el trabajo UKI en Bazzite de todos modos y aceptar la divergencia con
   la base.
2. Usar un UKI sellado de Fedora ascendente y añadir política de attestos a
   través de un complemento de systemd firmado por separado y medido en el
   PCR 12.
3. Encontrar otra ruta autenticada de medición pre-kernel. Una medición hecha
   solo después de que el kernel arranque es una clase de evidencia más débil y
   no debe presentarse como equivalente.

## El problema de la admisión de claves, sin resolver

Un UKI ascendente de Fedora puede conservar su firma de distribución, pero un
complemento de política de attestos separado aún necesita una clave de firma
admitida por el firmware, Shim o MOK. Un kernel de terceros tiene la versión más
grande del mismo problema. Las opciones de despliegue son:

- **Inscripción MOK**, donde el usuario inscribe una Machine Owner Key a través
  de una pantalla azul de firmware en el primer arranque. Universal Blue ya hace
  esto para módulos de kernel fuera del árbol, así que la maquinaria existe,
  pero cambia la afirmación de "Microsoft avala este kernel" a "el usuario
  confía explícitamente en esta clave", y un proveedor tiene que decidir si eso
  es aceptable.
- **Un shim firmado por Microsoft**, que es el camino que toma una distribución
  real y es un proceso de revisión más que un formulario.
- **PK y KEK propiedad del usuario**, que da control total y casi ninguna
  adopción.

El harness desechable de Fedora inscribe un certificado local de la ejecución en
una DB UEFI copiada y prueba el mecanismo sin reclamar un modelo de despliegue.
Todavía no hay un contrato aceptado de inscripción, revocación o recuperación de
claves para el usuario final. Es tanto una cuestión de la parte que confía como
de ingeniería.

## Instalarlo

Todavía no hay un comando de instalación soportado. En particular,
`ghcr.io/plunder707/attestos:latest` no está publicado. La vista previa actual
es solo para revisión del código fuente y reproducción aislada con QEMU/swtpm.
Ver [`BUILDING.md`](https://github.com/plunder707/attestos/blob/main/BUILDING.md).

## Estructura

```
Containerfile            imagen base y el único RUN que llama a build.sh
build_files/build.sh     la capa de atestación
system_files/            agente, script de aprovisionamiento, unidades systemd
image-template.env       nombre de imagen y organización del registro
.github/workflows/       canarios aislados de evidencia y solo construcción
Justfile                 objetivos locales de construcción y prueba
```

Todo lo que está fuera de `build_files/` y `system_files/` proviene de
[ublue-os/image-template](https://github.com/ublue-os/image-template) y es su
trabajo.

## Lo que aún tiene que responderse

- Si la imagen construye en absoluto. Confirmado para el commit `14e3a21` por la
  ejecución `31143048491` de GitHub Actions; la construcción emitió dos
  advertencias no fatales de lint del estado de DNF.
- Cómo un verificador convierte la afirmación de despliegue de `bootc status`
  del agente en tiempo de ejecución en identidad de imagen verificada. La
  afirmación es metadatos, no autoridad firmada; en sistemas sin `bootc` es
  explícitamente `unavailable`.
- El QCOW2 derivado de Bazzite supera el canario de mecánica aislada, pero sus
  observaciones negativas de UKI y bloqueo lo retienen de la admisión por
  política.
- Si el complemento de política PCR 12 firmado por separado sigue siendo
  reproducible bajo actualizaciones, reversión, orden alternativo y un ciclo de
  vida de claves de producción. El harness congelado de política única ahora
  pasa; estos casos de ciclo de vida no.
- Cómo construir el agente y la política en un candidato sellado, verificar una
  cita firmada fuera del invitado y reproducir los registros de eventos
  relevantes.
- Si el PCR 15 está poblado como supone el diseño en una raíz bootc.
- Si la inscripción MOK produce un valor de PCR 7 lo suficientemente estable
  como para escribir una política contra él.
- Si un proveedor aceptaría una jerarquía de claves inscrita por MOK.

Las preguntas de medición en tiempo de ejecución requieren QEMU con OVMF y
swtpm, lo que no necesita hardware adicional. El cableado y la mecánica del
protocolo TPM crudo ya han pasado allí, pero arrancar la imagen construida y
validar su registro de eventos y política siguen siendo experimentos separados.
La aceptación del proveedor requiere una conversación con el proveedor.

## Licencia

Apache-2.0, en correspondencia con la plantilla sobre la que está construido.