Este documento detalla la auditoría de seguridad realizada sobre el optimizador de Arch Linux para la laptop Dell Latitude 5480, las remediaciones técnicas implementadas y el análisis de riesgos remanentes aceptados.

A continuación se presenta el estado de los 6 hallazgos críticos detectados y resueltos en esta reestructuración modular:

• Riesgo: El script original enmascaraba el servicio wpa_supplicant.service sin configurar explícitamente a NetworkManager para utilizar el backend iwd, lo cual causaba la pérdida total del servicio WiFi tras el reinicio en entornos que no tuvieran esta directiva previamente activa.
• Remediación: Implementado en el módulo modules/60-network-wifi.sh. Se crea el archivo de configuración /etc/NetworkManager/conf.d/wifi-backend.conf conteniendo wifi.backend=iwd antes de enmascarar wpa_supplicant. Adicionalmente, en entornos activos se ejecutan comandos de validación de salud (systemctl is-active iwd, systemctl is-active NetworkManager y la consulta del adaptador/dispositivo vía iwctl) para garantizar que la pila de red inalámbrica funciona correctamente tras la transición.

• Riesgo: Descargar el llavero de firmas desde GitHub e importarlo a ciegas al keyring del sistema mediante pacman-key es vulnerable a ataques de secuestro DNS, descargas truncadas o inyección de llaves maliciosas en el host.
• Remediación: Implementado en el módulo modules/10-repos-cachyos.sh. La descarga ahora se efectúa en un directorio temporal seguro con permisos restrictivos y mediante curl -sf. Antes de realizar cualquier acción de importación, el script ejecuta validaciones binarias sobre la firma:
  1. Verifica que el archivo sea un conjunto válido de paquetes OpenPGP ejecutando gpg --list-packets.
  2. Valida mediante gpg --show-keys que el llavero descargado contenga exactamente el Key ID oficial de CachyOS (F3B607488DB35A47). Si alguna prueba falla, aborta la instalación de inmediato.

• Riesgo: Confiar en un fallback hardcodeado a "osiris" cuando fallaba la detección dinámica causaba que el script aplicara configuraciones de usuario en directorios inexistentes o rompiera permisos del sistema si se ejecutaba bajo cuentas o entornos no estándar.
• Remediación: Implementado en la función detect_real_user de lib/common.sh. Se realiza una inspección rigurosa de variables de entorno de sudo ($SUDO_USER) y de inicio de sesión (logname), con un fallback adicional que escanea las sesiones de usuario activas en TTYs excluyendo a root. Si aun así no es posible determinar de forma 100% segura el usuario real del entorno gráfico, el script aborta inmediatamente con un mensaje de error y no realiza ninguna acción.

• Riesgo: Considerar un servicio como "activo" o "exitoso" simplemente porque systemctl enable --now retornó código 0, sin validar si el demonio realmente está aplicando las directivas de seguridad en caliente.
• Remediación: Implementado en el módulo modules/99-services.sh. Al habilitar la seguridad del sistema:
  1. Se ejecuta aa-status para comprobar activamente que el kernel tiene AppArmor habilitado y que existen perfiles cargados en modo Enforce.
  2. Se valida el estado del firewall UFW consultando ufw status para confirmar que se encuentra en estado Status: active y aplicando las reglas basales de red.

• Riesgo: El uso indiscriminado de tuberías finalizadas en || true ocultaba fallos en comandos vitales (como remounts de almacenamiento temporal en RAM, configuraciones de fstab o descargas fallidas), dejando el sistema en un estado inconsistente difícil de diagnosticar.
• Remediación: Se implementó un manejador de excepciones global en lib/common.sh mediante set -o errtrace y un trap en la señal ERR. Si un comando crítico falla en cualquier módulo, el manejador captura el comando exacto, el número de línea y el código de error devuelto, registrándolo en /var/log/arch-optimizer.log y marcando el estado del sistema en /var/lib/arch-optimizer/global_status as failed. Se eliminaron los || true de todas las operaciones no opcionales del flujo.

• Riesgo: Clonar y compilar directamente desde las ramas principales de AUR (yay-bin y preload) expone al sistema a que una actualización maliciosa en el repositorio de la comunidad (AUR) se compile y ejecute con privilegios de root de forma inmediata.
• Remediación: Se introdujo soporte nativo para git commit pinning. Los hashes de commits probados y validados para yay-bin y preload se encuentran definidos en config/vars.env. El módulo modules/40-aur-bootstrap.sh realiza un checkout obligatorio a ese commit exacto tras clonar. Esto asegura que la compilación sea reproducible y previene la inyección de código de terceros sin revisión previa.

El usuario y los administradores del sistema aceptan los siguientes riesgos residuales debido a necesidades de usabilidad del entorno local:

• Detalle: Para asegurar el correcto funcionamiento de plataformas multijugador, Steam y navegación diaria, se configuró UFW con la directiva ufw default allow outgoing.
• Riesgo: Si un malware infecta el host, podrá realizar conexiones de retorno (reverse shells) o exfiltrar información hacia el exterior sin bloqueo de red en capa de transporte.
• Justificación de Aceptación: Bloquear puertos de salida por defecto requiere un mantenimiento de listas blancas extremadamente complejo e interrumpe la experiencia del usuario final en una laptop de escritorio común. La seguridad de red se delega a la higiene del navegador (LibreWolf) y las defensas del kernel (AppArmor).

• Detalle: El sistema confía plenamente en la firma del repositorio CachyOS para obtener kernels optimizados (linux-cachyos) y aplicaciones precompiladas.
• Riesgo: Si el servidor de compilación o la clave privada de CachyOS son comprometidos, el atacante podría firmar y distribuir paquetes maliciosos a través de las actualizaciones de pacman.
• Justificación de Aceptación: Se asume este riesgo para obtener las optimizaciones extremas de compilación a nivel de CPU (instrucciones x86_64_v3) y scheduling de procesos, evitando tener que compilar el kernel localmente durante horas. El riesgo se mitiga mediante la validación previa de la clave pública del mirror oficial.

• Descripción: El script scripts/verify-uki.sh y su hook configs/95-verify-uki.hook realizan únicamente un chequeo estructural de completitud post-build:

  1. Que la UKI contenga una sección .linux embebida (objdump -h | grep .linux)
  2. Que el tamaño sea > 5 MB

  No es integridad criptográfica. No calcula, almacena ni compara ningún hash. Un atacante que reemplace la UKI por una imagen maliciosa estructuralmente válida (con sección .linux y tamaño > 5 MB) pasaría este chequeo sin detección.

• Hardware disponible: El sistema tiene un TPM 2.0 Nuvoton NPCT650 ya en uso activo (ssh-tpm-agent, tpm2-tools, tpm2-totp).

• Solución técnica pendiente: Implementar sellado (sealing) del hash SHA256 de la UKI contra PCRs del TPM tras cada build exitoso, y verificar ese sello en el hook. Esquema básico:

  # Tras mkinitcpio exitoso — sellar hash en TPM
  UKI_HASH=$(sha256sum /boot/EFI/Linux/*.efi | awk '{print $1}')
  tpm2_nvwrite -i <(echo "$UKI_HASH") 0x1500001 --auth=<policy>
  
  # En el hook de verificación — comparar contra TPM
  SEALED_HASH=$(tpm2_nvread 0x1500001)
  CURRENT_HASH=$(sha256sum /boot/EFI/Linux/*.efi | awk '{print $1}')
  [ "$SEALED_HASH" = "$CURRENT_HASH" ] || { echo "⛔ UKI hash mismatch vs TPM"; exit 1; }

• Alternativa más robusta: Secure Boot con clave propia (enroll MOK), firmando la UKI con sbsign. El gestor de boot (systemd-boot) verificaría la firma en cada arranque antes de ejecutar el kernel — esto sí es integridad anti-tampering real en el path de boot.

• Estado actual: Riesgo aceptado temporalmente. El chequeo estructural existente detecta corrupción accidental de la UKI (builds truncados, errores de escritura), pero no sustituye a integridad criptográfica real.