KSOS: el sistema Unix seguro de los 80 que anticipó el tipado seguro de Rust

Introducción

En 1982, mientras los equipos de desarrollo de UNIX seguían debatiendo si el lenguaje C era lo suficientemente seguro para kernels críticos, el Departamento de Defensa de EE.UU. (DoD) ya había puesto en producción un sistema operativo basado en UNIX que demostraba que la seguridad podía construirse desde el diseño: KSOS (Kernelized Secure Operating System). El código fuente de este sistema, perdido durante casi cuatro décadas, resurgió en 2026 gracias al trabajo de archivistas como Warren Toomey y Tom Perrine, revelando una arquitectura que anticipó conceptos que hoy asociamos a Rust o seL4.

Lo más llamativo de KSOS no es su antigüedad, sino su enfoque técnico:

• Lenguaje seguro: escrito en Modula (antecesor de Modula-2), un lenguaje con tipado estricto y soporte para verificación formal.
• Arquitectura: un kernel aislado del resto del sistema, con un diseño capability-based para limitar accesos.
• Producción real: desplegado en sistemas militares como el Trusted Downgrade System para fusión de inteligencia multi-nivel.

Para equipos de DevOps, SRE y seguridad, KSOS ofrece lecciones prácticas sobre cómo diseñar sistemas seguros incluso con hardware de los 70. No es un ejercicio académico: fue un sistema que funcionó en producción durante años.

Qué ocurrió

En julio de 2026, el Unix Heritage Society (TUHS) anunció la incorporación del código fuente de KSOS a su archivo histórico. El hallazgo es obra de Tom Perrine, uno de los desarrolladores originales del proyecto, quien en 2024 localizó un tarball con el código en un disco olvidado. Según su relato en la lista de TUHS:

> «KSOS-11 se desarrolló para PDP-11 en Ford Aerospace y luego se extendió en Logicon. No compartía código con UNIX, pero ofrecía compatibilidad con llamadas al sistema UNIX desde userland. Todo escrito en Modula.»

El sistema tenía dos versiones principales:

1. KSOS-11: Para minicomputadoras PDP-11 (1978–1982).
2. KSOS-32: Portado a VAX, donde el código en Modula-2 (derivado de Modula original) se generó automáticamente usando macros de Emacs sobre el código Modula original.

Perrine detalló en 2012 en DEF CON que KSOS se usó en sistemas como ACCAT-GUARD y USAFE-GUARD, herramientas de fusión de inteligencia multi-nivel para agencias de defensa. Su arquitectura se basaba en:

• Un kernel seguro aislado, con verificación formal de propiedades de seguridad.
• Un subsistema UNIX en userland que emulaba llamadas al sistema UNIX tradicional (como open() o read()), pero con políticas de acceso estrictas.
• Soporte para hardware commodity: PDP-11 y VAX, máquinas de gama media de la época.

La novedad no era solo la seguridad, sino su enfoque en la verificabilidad formal. Mientras que proyectos modernos como seL4 o Rust-based kernels (ej. Asterinas) requieren herramientas complejas como Isabelle/HOL, KSOS demostró que esto era posible décadas antes con herramientas más rudimentarias.

Impacto para DevOps / Infraestructura / Cloud / Seguridad

Para equipos de DevOps y SRE

KSOS desafía la narrativa actual de que la seguridad en kernels es un problema reciente. Su diseño muestra que:

1. La compatibilidad hacia atrás no sacrifica seguridad: KSOS ofrecía una API UNIX en userland pero con un kernel seguro por detrás. Esto es relevante hoy para entornos legacy en cloud (ej. migración de sistemas antiguos a contenedores con políticas de SELinux).
2. El hardware commodity puede ser seguro: PDP-11 y VAX no eran máquinas especializadas, sino hardware comercial. La lección es que la seguridad depende más del diseño que del hardware.

• KSOS-32 corría en VAX-11/780, una máquina con 128 KB de RAM (vs. los 128+ GB típicos en servidores cloud actuales). Aún así, ofrecía aislamiento de procesos.
• Su userland UNIX era un wrapper con aproximadamente 300 llamadas al sistema emuladas, pero con políticas de acceso basadas en capabilities (no en UID/GID tradicionales).

Para equipos de seguridad

El enfoque de KSOS en verificación formal es un recordatorio de que:

• La seguridad no es solo parches o firewalls: KSOS demostró que un kernel podía ser provably secure con herramientas de la época.
• La transparencia era clave: a diferencia de sistemas como Multics (cuyo código era secreto), KSOS tenía su código abierto y documentado.

Para equipos de Cloud

La arquitectura de KSOS sugiere un modelo para sistemas modernos:

1. Separación de privilegios: El kernel manejaba seguridad; el userland ofrecía compatibilidad UNIX. Esto es análogo a:

– MicroVMs (como Firecracker) donde el hypervisor es mínimo y seguro.

1. Tipado seguro antes de Rust: Modula ya ofrecía type safety en 1978. Hoy, equipos pueden usar:

– Lenguajes con soporte para verificación (como Ada o SPARK) en componentes críticos.

En Kubernetes, un Pod con políticas de SELinux puede emular el modelo de KSOS:

• El kubelet (como el kernel) aplica políticas de seguridad.
• Los contenedores (como el userland) ofrecen compatibilidad hacia atrás con APIs antiguas.

Detalles técnicos

Arquitectura de KSOS

1. Kernel seguro:

– Tipado estricto: Evitaba buffer overflows y accesos a memoria inválidos (similar a los borrow checker de Rust).

– Verificación formal: Se usaban técnicas como abstract interpretation para probar propiedades de seguridad (ej. «un proceso no puede acceder a memoria fuera de su capability domain«).

– Soporte para hardware:

– PDP-11: Direccionamiento de 16 bits (64 KB de espacio de direcciones).

– VAX: Direccionamiento de 32 bits (4 GB de espacio de direcciones).

– Sin MMU en PDP-11: El aislamiento se lograba con registros de protección en hardware, no con paginación.

1. Subsistema UNIX en userland:

– Llamadas al sistema emuladas: El código en Modula-2 traducía llamadas como open() a operaciones seguras en el kernel.

– Ejemplo de código (traducción simplificada de una llamada read()):

     PROCEDURE Read(fd: INTEGER; buf: ARRAY OF CHAR; nbytes: INTEGER): INTEGER;
     (*
       fd: descriptor de archivo.
       buf: buffer de destino.
       nbytes: bytes a leer.
       Retorna bytes leídos o error.
     *)
     VAR
       cap: Capability; (* Capacidad de acceso *)
       result: INTEGER;
     BEGIN
       cap := GetCapability(fd); (* Obtiene la capacidad de acceso *)
       IF NOT HasPermission(cap, READ) THEN
         RETURN -1; (* Error: sin permisos *)
       END;
       result := KernelRead(cap, buf, nbytes); (* Llamada al kernel seguro *)
       RETURN result;
     END Read;
     

1. Modelo de seguridad:

– Sin superuser: A diferencia de UNIX tradicional, no había un UID 0 con acceso total. El kernel aplicaba políticas estrictas.

Herramientas de la época

• Compilador: Modula original (no Modula-2). Perrine mencionó en 2024 que aún falta encontrar el compilador original para reconstruir el sistema.
• Emacs macros: Para la versión VAX, el código Modula se transformó automáticamente a Modula-2 usando macros de Emacs (un ejemplo temprano de code generation).
• Documentación: El Executive Summary de 1978 (15 páginas) detalla el diseño del kernel, incluyendo diagramas de flujo de llamadas seguras.

Limitaciones y desafíos

• Rendimiento: La verificación formal añadía overhead. En PDP-11, el kernel ocupaba ~32 KB de memoria.
• Hardware: Sin soporte para MMU en PDP-11, el aislamiento dependía de hardware específico. Esto limitaba su portabilidad.
• Legado: El código Modula-2 de KSOS-32 no compilaba directamente en sistemas modernos debido a dependencias de hardware (ej. manejo de interrupciones en VAX).

Qué deberían hacer los administradores y equipos técnicos

1. Evaluar el modelo de seguridad de KSOS para entornos modernos

• Para sistemas legacy en cloud:

– Ejemplo con Podman:

    podman run --security-opt label=type:svirt_sandbox_file_t \
                --cap-drop=ALL --cap-add=NET_BIND_SERVICE \
                alpine sh
    

– Objetivo: Limitar accesos a lo mínimo necesario (principio de least privilege).

• Para migraciones a contenedores:

– Ejemplo con Docker:

    FROM gcr.io/distroless/base-debian12
    COPY mi-app /mi-app
    USER nonroot:nonroot
    CMD ["/mi-app"]
    

2. Adoptar principios de tipado seguro en infraestructura

• Tipado estricto en scripts de automatización:

    # En tu CI/CD, valida tipos estáticamente
    pip install mypy
    mypy --strict tu_script.py
    

– Alternativa con Go: Para herramientas personalizadas (ej. controladores de cloud), Go ofrece tipado seguro y compilación a binarios estáticos.

• Verificación formal en componentes críticos:

– Ejemplo con Creusot (Rust):

    // Usando Creusot para verificar propiedades de una función
    #[creusot::spec]
    fn divide(a: i32, b: i32) -> Option<i32> {
        if b == 0 { None } else { Some(a / b) }
    }
    

3. Documentar y archivar sistemas legacy antes de que se pierdan

• Identificar hardware y software crítico:

– Ejemplo:

    sudo lshw -short -class system > hardware_inventory.txt
    

• Preservar código y dependencias:

– Código fuente original.

– Documentación técnica (ej. manuales de hardware).

– Entorno de build emulado (ej. usando QEMU para PDP-11).

– Ejemplo de estructura:

    ksos-legacy/
    ├── kernel/
    │   ├── modula/          # Código fuente original
    │   └── build/           # Scripts de compilación
    ├── docs/
    │   ├── design_1978.pdf  # Diseño original
    │   └── hardware_vax.pdf
    └── emulation/
        ├── pdp11.qcow2       # Imagen de disco para QEMU
        └── README.md         # Instrucciones para reconstruir
    

4. Actualizar políticas de seguridad en cloud

• Configurar SELinux/AppArmor para contenedores:

  # Politica estricta para un pod Kubernetes
  cat <<EOF | kubectl apply -f -
  apiVersion: v1
  kind: Pod
  metadata:
    name: secure-pod
  spec:
    containers:
    - name: app
      image: alpine
      securityContext:
        seLinuxOptions:
          level: "s0:c123,c456"
  EOF
  

• Usar gVisor para aislar cargas de trabajo:

  # En un Deployment de Kubernetes
  apiVersion: apps/v1
  kind: Deployment
  metadata:
    name: secure-app
  spec:
    template:
      spec:
        runtimeClassName: gvisor
        containers:
        - name: app
          image: alpine
  

Conclusión

KSOS no es una curiosidad histórica, sino un testimonio de que la seguridad en sistemas operativos no es una innovación reciente, sino una práctica olvidada. Su código resurge en un momento donde equipos de DevOps y SRE enfrentan desafíos similares:

• Cómo migrar sistemas legacy a entornos modernos sin sacrificar seguridad.
• Cómo aplicar principios de least privilege en arquitecturas distribuidas.
• Cómo verificar formalmente propiedades de seguridad, incluso con herramientas rudimentarias.

La lección principal es clara: la seguridad se construye en el diseño, no en los parches. Modula en 1978, Rust en 2024, o Ada con SPARK: el lenguaje es secundario. Lo crítico es el modelo de seguridad subyacente. Para equipos técnicos, KSOS ofrece un manual práctico para:

1. Auditar sistemas con políticas de capabilities.
2. Adoptar tipado seguro en infraestructura.
3. Preservar conocimiento antes de que se pierda.

Como dijo Tom Perrine en su charla de DEF CON 2012:

> «Lo que hicimos en KSOS no era magia. Era ingeniería. Y hoy, con herramientas más poderosas, no tenemos excusa para no hacerlo mejor.»

Fuentes

• The Unix Heritage Society: Anuncio de KSOS
• Tom Perrine: «The Kernelized Secure Operating System (KSOS)» (USENIX ;login:, 2002)
• DEF CON 20: Charla de Tom Perrine sobre KSOS (2012)
• FOSDEM 2025: «Confidential Computing’s Recent Past…» (menciona KSOS en slide 8)
• AWS Containers Blog: Artículos sobre seguridad en contenedores
• First.org: Métricas de seguridad y CVSS