La solicitud era sencilla: tras actualizar sh0 desde el panel, el usuario debía ejecutar systemctl restart sh0 en el host. Pero ya estaba en el panel. ¿Por qué necesitaría SSH?
sh0 ya contaba con un terminal de contenedor -- xterm.js en el navegador, WebSocket hacia el backend, Docker exec en el contenedor. La pregunta era: ¿podemos hacer lo mismo para el host?
La brecha arquitectónica
Los terminales de contenedor son fáciles. La API exec de Docker proporciona un flujo bidireccional con soporte TTY. Se crea una instancia exec, se inicia con Attach=true, Tty=true, y se obtiene una conexión HTTP actualizada que transmite bytes PTY sin procesar. El backend simplemente conecta los frames WebSocket con el flujo de Docker.
Los terminales de host son diferentes. No hay API de Docker. Hay que crear un PTY real en el sistema operativo del host. Esto implica:
openpty()para crear un par PTY maestro/esclavofork()+setsid()+TIOCSCTTYpara configurar un terminal de controlexec()del shell con el fd esclavo como stdin/stdout/stderr- I/O no bloqueante en el fd maestro para lectura/escritura asíncrona
- Limpieza adecuada:
SIGHUP(al cerrar el PTY), luegoSIGKILL, luegowaitpid()
Todo dentro de un runtime asíncrono de Rust (tokio), donde bloquear el bucle de eventos está prohibido.
Lo que construimos
Backend (host_access.rs, ~550 líneas de Rust):
- PTY creado dentro de spawn_blocking para evitar bloquear tokio
- fd maestro encapsulado en AsyncFd<OwnedFd> para I/O no bloqueante
- Un helper pty_write_all() que maneja EAGAIN y escrituras parciales
- Recolección del proceso hijo vía Child::wait() (no waitpid directo)
- Explorador de archivos usando tokio::fs con canonicalización de rutas
Frontend: la misma configuración xterm.js que el terminal de contenedor, pero conectándose a /api/v1/host/terminal en lugar de /api/v1/apps/:id/terminal. Un explorador de archivos con el mismo diseño de dos paneles, reutilizando el componente FileTree existente mediante una nueva prop browseFn.
Lo que encontraron dos auditores
Ejecutamos dos agentes de auditoría independientes de forma simultánea. Coincidieron en los problemas críticos y cada uno encontró vulnerabilidades únicas que el otro no detectó.
Ambos auditores detectaron: evasión por traversal de enlaces simbólicos
El sistema de protección de rutas verificaba /tmp/file contra una lista de bloqueo de /proc, /sys, /bin, etc. Pero un administrador podía crear /tmp/evil -> /etc/shadow y luego escribir en /tmp/evil. La cadena /tmp/evil pasa todos los controles. El sistema de archivos sigue el enlace simbólico.
Corrección: tokio::fs::canonicalize() antes de verificar las protecciones. Si /tmp/evil se resuelve a /etc/shadow, la escritura se bloquea.
Auditor 1: doble cierre del fd esclavo
Stdio::from_raw_fd(slave_fd) toma posesión del fd. Luego libc::close(slave_fd) en el padre lo cierra de nuevo. Si otro hilo abre un fd entre los dos cierres, cerraríamos el fd equivocado.
Corrección: dup() del fd esclavo para cada uno de stdin/stdout/stderr. Cerrar el original una sola vez.
Auditor 2: escrituras bloqueantes en el runtime asíncrono
El lado de lectura usaba correctamente AsyncFd::readable() con try_io(). Pero el lado de escritura usaba libc::write() directo -- bloqueante. Si el buffer PTY se llena (el shell no lee), el hilo worker de tokio entero se bloquea.
Corrección: pty_write_all() usando AsyncFd::writable() + try_io(), con reintentos EAGAIN y manejo de escrituras parciales.
Auditor 2: /dev/zero causa OOM
metadata.len() devuelve 0 para archivos de dispositivo. La verificación de tamaño pasa. tokio::fs::read() lee indefinidamente. Memoria agotada.
Corrección: verificar metadata.is_file() para rechazar archivos de dispositivo. Usar AsyncReadExt::take(MAX_READ_SIZE) en lugar de confiar en los metadatos.
La metodología
Construir, luego auditar, luego auditar de nuevo, luego decidir. Cada sesión optimiza localmente. El primer auditor detecta el problema de enlaces simbólicos pero puede pasar por alto la condición de carrera de EAGAIN. El segundo auditor, con una mirada fresca, detecta las escrituras bloqueantes pero puede no notar el doble cierre. Juntos, encontraron 15 problemas en las categorías Crítico/Importante.
La implementación tomó aproximadamente 30 minutos. La doble auditoría unos 5 minutos (agentes en paralelo). Las correcciones unos 15 minutos. Total: menos de una hora para un terminal de host listo para producción con una revisión de seguridad completa.
El resultado
La página de Configuración ahora tiene una pestaña "Host Access" con un banner de advertencia rojo y dos sub-vistas: Terminal y Archivos. Los administradores pueden ejecutar comandos en el host, explorar el sistema de archivos, editar archivos de configuración y reiniciar servicios -- todo desde el navegador. La funcionalidad que motivó este trabajo (reiniciar sh0 tras una actualización) es ahora una tarea de 5 segundos en lugar de "abrir una sesión SSH separada".