Arquitectura de un Entorno de Examen Seguro en Linux: Por qué un Live USB en Debian supera a las soluciones comerciales

Hoy quiero publicar una propuesta completa a algo que parece que algunas grandes empresas no han querido hacer.
Nos vamos a enfocar en dar un rigor técnico al artículo, utilizaremos Debian como base y quiero demostrar por qué una arquitectura Open Source bien diseñada aplasta en términos de seguridad, auditoría e integridad a los binarios propietarios de supervisión remota.

El argumento recurrente de los proveedores de exámenes en línea (proctoring) para no ofrecer soporte en Linux es la "dificultad para auditar el entorno del usuario y prevenir el fraude".
Para justificar la falta de soporte nativo, optan por exigir aplicaciones propietarias en sistemas Windows o macOS que ejecutan agentes invasivos a nivel de usuario o kernel.

Sin embargo, desde el punto de vista del análisis de vectores de ataque y la seguridad informática, un sistema operativo instalado en el disco local del usuario —lleno de software de terceros, controladores propietarios y servicios residentes— es intrínsecamente inauditable.

En este artículo demostraremos técnicamente cómo construir una solución de evaluación en remoto basada en Debian Live, inmutable, cifrada, con arranque seguro e insuperable por cualquier solución comercial cerrada.

1. El vector de fallo de las soluciones comerciales (OnVUE y similares)

Las aplicaciones tipo OnVUE basan su seguridad en la detección heurística posterior:

• Escanean la lista de procesos en ejecución (tasklist / ps).
• Intentan detectar hipervisores mediante instrucciones de CPU (como CPUID o registros de tablas de descriptores).
• Bloquean combinaciones de teclas e inyectan enganches (hooks) en las API del sistema operativo.

Por qué este enfoque es defectuoso:

Si el usuario controla el sistema operativo anfitrión (o el hipervisor subyacente), cualquier detección en espacio de usuario (user-space) o controlador de kernel (kernel-space) es puenteable mediante parches en memoria, módulos de kernel personalizados (DKMS), o modificando las respuestas de la CPU virtualizada (ej. KVM con tablas de anidamiento modificadas).

2. La solución inmutable: Imagen Debian Live con arranque firmado (Chain of Trust)

Para garantizar la integridad del examen no debemos intentar "limpiar" o "vigilar" un sistema sucio.

La estrategia correcta es desplegar un entorno efímero, inmutable y firmado desde el origen.

A. Cadena de confianza (Secured Chain of Trust)

El hardware del usuario debe validar la imagen antes de ejecutar una sola línea de código:

[UEFI / Secure Boot] 
       │
       ▼ (Valida firma PK/KEK/db)
[shim-helpers-amd64-signed]
       │
       ▼ (Valida kernel y initramfs)
[GRUB2 Signed (Debian)]
       │
       ▼
[Linux Kernel (Debian)] ──► Lockdown Mode (Integridad de Kernel)
       │
       ▼
[SquashFS cifrado / Verity] ──► Entorno efímero en RAM (overlayfs)

1. Secure Boot: Se utiliza la clave de plataforma de Debian o una clave propia firmada adjunta al UEFI.
2. Kernel Lockdown Mode: El kernel de Debian se inicia obligatoriamente con el parámetro de arranque lockdown=integrity o lockdown=confidentiality. Esto deshabilita /dev/mem, eprobes, carga de módulos de kernel no firmados (unsigned kernel modules), hibernación y acceso a registros de la CPU que permitan alterar la ejecución del sistema en tiempo de ejecución.

3. Construcción del entorno minimalista (Debian Live Build)

Utilizando las herramientas oficiales de Debian (live-build), creamos una distribución personalizada sin servidor gráfico pesado ni herramientas de desarrollo.

Configuración del constructor (auto/config):

#!/bin/sh
lb config noauto \
    --architectures amd64 \
    --distribution bookworm \
    --archive-areas "main" \
    --chroot-filesystem squashfs \
    --compression-level 9 \
    --backports false \
    --binary-images iso-hybrid \
    --bootappend-live "boot=live components quiet splash lockdown=confidentiality systemd.unit=multi-user.target" \
    "${@}"

Paquetes estrictamente necesarios (config/package-lists/exam.list.chroot):

# Kernel y base
linux-image-amd64
live-boot
systemd-sysv

# Red y WebRTC
network-manager
chromium
pipewire
pipewire-audio

# Entorno de despliegue gráfico aislado
wayland-protocols
cage

Nota: No se incluye bash interactivo para el usuario, ni sudo, ni compiladores, ni pila de utilidades coreutils avanzadas si no son requeridas por la sesión.

4. Aislamiento gráfico y ejecución en Kiosk Mode mediante Wayland (Cage)

En lugar de utilizar X11 (cuyo protocolo carece de aislamiento de entrada entre ventanas y permite el keylogging entre aplicaciones de forma nativa), se utiliza un compositor Wayland minimalista diseñado específicamente para modo Kiosk: Cage.

Cage ejecuta una única aplicación a pantalla completa e impide la apertura de cualquier otro proceso gráfico o terminal.

Configuración de la unidad de Systemd (/etc/systemd/system/exam-kiosk.service):

[Unit]
Description=Entorno de Examen Aislado (Kiosk)
After=network-online.target
Wants=network-online.target

[Service]
User=examuser
Group=examuser
PAMName=login
TTYPath=/dev/tty1
ExecStart=/usr/bin/cage -s -- /usr/bin/chromium \
  --no-first-run \
  --kiosk \
  --incognito \
  --disable-pinch \
  --disable-translate \
  --disable-extensions \
  --disable-component-extensions-with-background-pages \
  --disable-dev-tools \
  --app=https://examen.lpi.org/session-id-secure \
  --enable-features=UseOzonePlatform \
  --ozone-platform=wayland

Restart=always
RestartSec=1s

[Install]
WantedBy=multi-user.target

5. Control de red, comunicación y verificación anti-fraude

Una vez desplegado el entorno, ¿cómo garantizan los supervisores la autenticidad y la supervisión del estudiante?

A. Túnel cifrado y filtrado de red (eBPF / nftables)

Se bloquea cualquier tráfico saliente salvo la conexión de WebSocket/WebRTC contra la infraestructura del centro de certificación.

# Configuración estricta de nftables
table inet filter {
    chain output {
        type filter hook output priority 0; policy drop;
        
        # Permitir tráfico local loopback
        oif "lo" accept
        
        # Permitir resolución DNS solo al servidor del examen
        udp dport 53 ip daddr 192.168.1.1 accept
        
        # Permitir únicamente tráfico HTTPS/WebRTC hacia la subred de LPI
        tcp dport 443 ip daddr exam-nodes.lpi.org accept
        udp dport 3478 ip daddr stun.lpi.org accept # STUN/TURN WebRTC
    }
}

B. Captura multicanal (WebRTC nativo)

Sin necesidad de instalar binarios de supervisión propietaria con permisos de administrador:

1. El navegador WebRTC solicita acceso a la cámara web, micrófono y captura de pantalla completa (getDisplayMedia).
2. Al estar sobre Wayland (PipeWire), la captura de pantalla no se puede alterar mediante intermediarios de software no autorizados.
3. Los tres flujos se transmiten cifrados punto a punto (DTLS-SRTP) directamente a los monitores/supervisores.

6. Firma remota de la sesión (Remote Attestation) mediante TPM 2.0

Para contrarrestar el argumento de que el examen se pueda estar ejecutando sobre un hipervisor modificado (KVM/QEMU), la imagen Debian utiliza el chip TPM 2.0 del hardware físico:

1. Durante la secuencia de arranque, los registros PCR (Platform Configuration Registers) del TPM 2.0 miden el código del firmware UEFI, el gestor de arranque GRUB, el kernel Debian y el hash del archivo SquashFS.
2. Al iniciar la sesión, el cliente genera una clave de atestación firmada por el TPM (TPM Quote).
3. La plataforma de LPI verifica criptográficamente que la firma del TPM corresponde a un hardware real y que la imagen cargada en memoria es exacta bit a bit a la ISO distribuida, sin modificaciones.

Comparativa: Entorno Debian Live vs. Cliente Propietario (OnVUE)

Conclusión

Sostener que no se pueden realizar exámenes de certificación en Linux por "motivos de seguridad" es una falacia técnica.

La tecnología existe, es más segura, respeta la privacidad del usuario y garantiza la integridad del proceso de forma muy superior a cualquier ejecutable comercial.

Con una imagen Debian Live, firmada mediante Secure Boot, aislada mediante Wayland/Cage, verificada por TPM 2.0 y transmitida vía WebRTC, se obtiene la infraestructura de examen definitiva.

Solo falta lo único que ningún código puede proveer: voluntad institucional.

La falsa seguridad de OnVUE y el "proctoring" en un examen OnLine

Como "Prueba de Concepto" (PoC) os dejo un ejemplo técnico paso a paso de cómo un usuario que controla su equipo anfitrion y el hipervisor de su máquina se puede saltar toda la arquitectura de detección de OnVUE.

PoC: Burlar la detección de hipervisores en KVM/QEMU

OnVUE intenta detectar si se está ejecutando dentro de una máquina virtual buscando "huellas" típicas de los hipervisores.
Un usuario que controla el sistema anfitrión (host) con Linux puede neutralizar cada una de estas comprobaciones a bajo nivel antes de que el código de OnVUE llegue a ejecutarse.

1. Engañar la instrucción CPUID (El registro de la CPU)

• Lo que hace OnVUE: Ejecuta la instrucción de ensamblador CPUID. Si el bit 31 del registro ECX devuelve un 1, o si la cadena de texto de la CPU devuelve KVMKVMKVM o VMwareVMware, OnVUE sabe que está en una máquina virtual y se bloquea.

Cómo se burla en el anfitrión (host): En el archivo de configuración de la VM en QEMU/KVM (libvirt), el usuario modifica la firma de la CPU para que clone exactamente una CPU física real (por ejemplo, un Intel Core i7) y oculte el hipervisor:XML

<cpu mode='host-passthrough' check='none'>
  <feature policy='disable' name='hypervisor'/>
</cpu>
<clock offset='utc'>
  <timer name='hypervclock' present='no'/>
</clock>

Al desactivar el flag hypervisor, la instrucción CPUID dentro de la VM devuelve exactamente lo mismo que un procesador real en metal desnudo (bare metal).

2. Falsear las tablas ACPI y SMBIOS (Información de la placa base)

• Lo que hace OnVUE: Lee la información del sistema operativo (en Windows, consulta registros como HELIOS_BOARD o cadenas en WMIC) buscando fabricantes como "QEMU", "BOCHS", "VirtualBox" o "VMware".

Cómo se burla en el anfitrión:El usuario extrae las tablas SMBIOS de su propia placa base física real y se las inyecta a la máquina virtual:Bash

# Extraer tablas reales del host
dmidecode -t 0 -u > bios_table.bin
dmidecode -t 1 -u > system_table.bin

Luego le indica a QEMU que suplante esos valores en la VM.
Para OnVUE, la memoria RAM y el firmware del sistema dicen que el equipo es una placa ASUS o Lenovo real.

3. Ocultar los dispositivos PCI y controladores

• Lo que hace OnVUE: Busca adaptadores de red virtuales (virtio-net), discos virtuales (QEMU HARDDISK) o controladores de pantalla de VirtualBox/VMware.
• Cómo se burla en el anfitrión:El usuario realiza VFIO / GPU Passthrough. Le "entrega" una tarjeta gráfica física secundaria (o la integrada), un controlador NVMe real y una tarjeta de red PCIe física directamente a la máquina virtual.
  Dentro de la VM, Windows no ve ningún componente emulado por software: ve componentes de silicio reales con sus propios controladores propietarios de Nvidia/AMD/Intel.

4. Parchear el Kernel de KVM para evadir ataques por temporización (Timing Attacks)

• Lo que hace OnVUE (Detección avanzada): Mide el tiempo que tardan ciertas instrucciones de la CPU usando RDTSC (Read Time-Stamp Counter). En una máquina virtual, una "salida del hipervisor" (VM-Exit) añade un pequeño retraso de microsegundos que no ocurre en el hardware real.
• Cómo se burla en el anfitrión (Modificando el módulo KVM / DKMS): Como el usuario tiene el control total de su Linux anfitrión, puede aplicar un parche al código fuente del módulo del kernel kvm_intel.ko o kvm_amd.ko: Modifica la gestión de las interrupciones del temporizador para que el hipervisor "resteste" artificialmente los ciclos de reloj perdidos durante la VM-Exit antes de devolverle el control a la VM.

¿Cuál es el resultado final?

Cuando OnVUE se ejecuta en ese Windows virtualizado, le pregunta al sistema operativo:

1. "¿Qué CPU tengo?" -> Respuesta: Intel i7 Físico (engañado vía CPUID).
2. "¿Qué placa base es esta?" -> Respuesta: Micro-Star International (engañado vía SMBIOS).
3. "¿Qué tarjeta de red y disco tengo?" -> Respuesta: Samsung NVMe & Realtek PCIe (Hardware real vía VFIO).
4. "¿Cuánto tardan las instrucciones de reloj?" -> Respuesta: Tiempos de silicio real (engañado vía parche en el módulo KVM del kernel Linux).

Conclusión: OnVUE se ejecuta perfectamente convencido de estar en un ordenador físico, mientras el usuario, desde su Linux anfitrión, puede estar grabando la pantalla con OBS desde fuera de la VM, ejecutando scripts sin que el entorno de Windows pueda enterarse jamás.

Esto demuestra que intentar vigilar la máquina desde dentro cuando el usuario controla el exterior es técnicamente imposible.

Por eso la solución lógica no es jugar al "gato y al ratón" con ejecutables invasivos en Windows, sino arrancar el equipo entero con un Live USB inmutable y firmado de Debian.