Protección del sistema operativo y máquinas virtuales

Un programa necesita suficiente libertad para calcular rápidamente sin obtener el control de todo el equipo. El modo usuario le permite ejecutar instrucciones ordinarias directamente. El modo núcleo, también llamado modo supervisor, da al sistema operativo acceso a las instrucciones que controlan la máquina.

Deja que el hardware haga cumplir los privilegios

La CPU tiene un nivel de privilegio en cada momento. Las sumas, lecturas, escrituras y saltos normalmente se ejecutan a máxima velocidad, sujetos a los permisos de memoria. El núcleo no inspecciona cada instrucción mediante software. Esto es la ejecución directa limitada: ejecutar directamente hasta que una operación protegida o una interrupción requiera al núcleo.

Una instrucción privilegiada provoca una trampa si el código de usuario intenta ejecutarla. En x86-64, HLT, la escritura en el registro base de la tabla de páginas CR3 y la instalación de una tabla de interrupciones con LIDT necesitan privilegios del núcleo. De lo contrario, una aplicación podría detener la CPU, sustituir sus propios límites de memoria o redirigir la gestión de interrupciones.

Supón que una aplicación ejecuta HLT. La CPU genera un fallo de protección general en lugar de detenerse. Entra en el manejador registrado por el núcleo. Linux normalmente envía SIGSEGV al proceso y lo termina mientras los demás programas continúan. La aplicación no puede elegir una dirección conveniente dentro del núcleo y comenzar a ejecutarse allí.

Cruza el límite por una entrada controlada

Las trampas, excepciones e interrupciones entran por direcciones registradas por el núcleo. El hardware cambia el nivel de privilegio y transfiere el control al manejador; el código de entrada al núcleo conserva el estado necesario para regresar. Una instrucción especial de retorno restaura la ejecución en modo usuario en el contador de programa guardado. En x86-64, el retorno puede usar SYSRET o IRETQ.

El temporizador hace que este control sea útil incluso cuando un programa nunca solicita un servicio. Antes de ejecutarlo, el núcleo programa un temporizador. Cuando llega la interrupción, el planificador puede seleccionar otro proceso. El código de usuario no puede desactivar las interrupciones ni reprogramar ese temporizador, por lo que un bucle infinito no puede quedarse con un núcleo para siempre.

Interpreta correctamente los diagramas de privilegios

Las convenciones de numeración son diferentes: un número de anillo x86 menor significa más privilegios, mientras que un nivel de excepción ARM mayor significa más privilegios. La virtualización de Intel también añade los modos de funcionamiento VMX raíz y no raíz; estos son independientes del número de anillo.

Separa la identidad del modo de la CPU

Root es una identidad de usuario, UID 0, que reconoce el software del núcleo. El código ordinario de una aplicación root sigue ejecutándose en modo usuario y entra en el núcleo mediante llamadas al sistema. Un controlador de dispositivo que se ejecuta en modo núcleo tiene mucho más poder directo: un error de memoria allí puede dañar el estado del núcleo sin pasar por una comprobación de permisos de archivo.

La capa que hace cumplir un límite debe controlar la capa que está dentro de él. El núcleo hace cumplir los límites entre procesos mediante los modos de CPU y las tablas de memoria. Un hipervisor controla de forma similar los sistemas operativos invitados mediante el soporte de virtualización del hardware.

Una llamada al sistema es una solicitud controlada de un servicio del núcleo. Abrir archivos, crear procesos y enviar datos por la red requieren decisiones que una aplicación no puede tomar por sí misma de forma segura. Entrar en el núcleo da autoridad al manejador; no da a quien hace la llamada permiso para hacer todo lo que solicitó.

Sigue la solicitud

Una función envoltorio de la biblioteca C como open() coloca el número de llamada y los argumentos en registros. Usa SYSCALL en x86-64, SVC en ARM64 o ECALL en RISC-V. Después, el núcleo:

1. Entra por su punto de entrada registrado y guarda los registros de usuario.
2. Selecciona el manejador de la tabla de llamadas al sistema y rechaza los números desconocidos.
3. Lee la identidad y las credenciales de quien hace la llamada a partir del proceso actual.
4. Comprueba los argumentos, los derechos de acceso y los objetos implicados.
5. Realiza la operación o devuelve un error.
6. Restaura el estado guardado y vuelve al modo usuario.

La identidad procede de las credenciales del proceso, no de un nombre proporcionado por el usuario. Quien hace una llamada no puede obtener los derechos de otro usuario añadiendo su nombre a una solicitud.

Trata los argumentos como datos no confiables

Un puntero es solo un número proporcionado por quien hace la llamada. El núcleo debe verificar todo el rango de memoria de usuario solicitado, incluidas su longitud y la dirección del acceso. Linux usa rutinas que realizan comprobaciones, como copy_from_user y copy_to_user, para cruzar el límite de forma segura.

Para read(fd, buf, 4096), un buf que apunta a la memoria del núcleo no debe convertirse en destino de los datos del archivo. Linux devuelve EFAULT para ese búfer de usuario incorrecto. Un error diferente tiene una causa diferente: write() mediante un descriptor abierto con O_RDONLY falla con EBADF, porque al descriptor nunca se le concedió acceso de escritura. Una solicitud ordinaria denegada devuelve un error; no termina automáticamente el proceso. En C, la función envoltorio suele devolver −1 y establecer errno.

Comprueba el objeto que realmente se usa

Una condición de carrera entre comprobación y uso (TOCTTOU) separa una decisión del objeto que debía proteger. Un programa auxiliar privilegiado comprueba access("/tmp/report", W_OK) y después abre la ruta. Un atacante sustituye la ruta por un enlace simbólico a /etc/passwd entre esas operaciones. El nombre no cambia, pero el objeto abierto es distinto.

La solución consiste en realizar el acceso con las credenciales previstas sobre el objeto que realmente se abre. Reduce los privilegios antes de abrir y usa opciones como O_NOFOLLOW cuando no se quieran enlaces simbólicos. Copiar los argumentos una sola vez en la memoria del núcleo también evita confiar repetidamente en datos de usuario modificables; la estructura copiada debe seguir validándose.

Identifica en qué se debe confiar

Un monitor de referencia media en el acceso. Debe invocarse siempre que se obtiene acceso, estar protegido contra modificaciones y ser lo bastante pequeño para examinarlo con cuidado. Después de que el núcleo conceda un mapeo de memoria, las lecturas y escrituras individuales pasan por las comprobaciones de permisos de la MMU; no realizan cada una una llamada al sistema.

La base de computación de confianza (TCB) es el hardware, el firmware y el software privilegiado de cuyo funcionamiento correcto depende la protección. Incluye la CPU, la cadena de arranque, el núcleo y los componentes de confianza del inicio de sesión. Trasladar controladores o sistemas de archivos a servidores en modo usuario puede reducir la parte del núcleo de esta base, como hacen los diseños de micronúcleo. Una aplicación ordinaria comprometida hace un uso indebido de los derechos que se le concedieron; un componente de confianza comprometido puede socavar las propias comprobaciones.

La memoria virtual protege los programas además de traducir direcciones. Un proceso puede alcanzar los marcos físicos indicados por su tabla de páginas activa, con los permisos establecidos por el núcleo. Los marcos privados de otro proceso no aparecen en ella; los mapeos deliberados de memoria compartida son una excepción explícita.

Comprueba cada acceso a memoria

La unidad de gestión de memoria (MMU) comprueba las entradas de la tabla de páginas en los accesos. Los permisos importantes incluyen presencia o validez, escritura, accesibilidad desde el modo usuario y ejecución. En x86, U/S distingue las páginas accesibles desde el modo usuario de las exclusivas del supervisor; NX o XD desactiva la ejecución. ARM llama XN a su restricción de ejecución.

Una infracción provoca un fallo de página. El fallo indica que ha fallado una comprobación de hardware; el núcleo decide si ese fallo es esperado y reparable. Considera dos escrituras en páginas de solo lectura:

• Un proceso sobrescribe una página de código que no es de copia en escritura. El núcleo lo trata como una escritura no válida y normalmente envía SIGSEGV.
• Después de fork(), un proceso escribe datos compartidos marcados como de copia en escritura. El núcleo asigna una copia privada, cambia el mapeo para permitir la escritura y vuelve a intentar la instrucción.

Ambos fallos parten de un bit de protección. Los registros del núcleo explican por qué los mapeos eran de solo lectura y determinan la respuesta. Por tanto, un fallo de página no supone automáticamente un fallo del programa ni una solicitud para traer datos del disco.

Protege los mapeos del núcleo en ambas direcciones

Las organizaciones tradicionales mapean la memoria del núcleo en los espacios de direcciones de los procesos como exclusiva del supervisor, lo que facilita la entrada al núcleo y bloquea las lecturas y escrituras en modo usuario. El ataque Meltdown de 2018 mostró que algunos procesadores podían filtrar esos datos mediante la ejecución especulativa. El aislamiento de las tablas de páginas del núcleo (KPTI) elimina la mayoría de los mapeos del núcleo mientras se ejecuta código de usuario en los sistemas afectados.

El código del núcleo también necesita protección para evitar que se lo redirija a memoria controlada por el usuario. SMEP en x86 impide la ejecución en modo núcleo desde páginas de usuario. SMAP bloquea los accesos a datos en páginas de usuario desde el modo núcleo, salvo durante operaciones de copia autorizadas deliberadamente. ARM proporciona protecciones relacionadas mediante PXN y PAN. Estas comprobaciones reducen las formas en que un atacante puede usar un error del núcleo para ejecutar código o proporcionar datos falsos al núcleo.

El acceso de solo lectura protege la integridad, no el secreto. Si un proceso puede leer una página mapeada, puede conocer su contenido aunque las escrituras fallen. Los datos confidenciales deben ser inaccesibles para ese proceso: déjalos sin mapear o aplica un límite adecuado de acceso exclusivo del supervisor.

Da a los dispositivos su propio límite

Las aplicaciones suelen solicitar operaciones a los dispositivos mediante un controlador. Los registros de los dispositivos normalmente son exclusivos del núcleo, aunque un proceso autorizado puede recibir determinados mapeos, como ocurre con los controladores gráficos o la entrada/salida en espacio de usuario de Linux.

Un dispositivo que realiza acceso directo a memoria (DMA) lee o escribe en la RAM sin enviar esos accesos a través de la MMU de la CPU. Los permisos de página de la CPU por sí solos no pueden impedir que un dispositivo defectuoso sobrescriba los marcos de otro proceso. Una IOMMU traduce y restringe las direcciones de los dispositivos mediante mapeos específicos para cada uno. Intel VT-d y AMD-Vi proporcionan este mecanismo.

Para un dispositivo asignado a una VM, la IOMMU restringe el DMA a la memoria asignada a esa VM. Por el lado de la CPU se necesita un límite paralelo: una segunda etapa de traducción de páginas mapea las direcciones físicas del invitado solo a los marcos permitidos por el hipervisor. Para proteger una carga de trabajo hay que cubrir tanto los accesos de la CPU como los de los dispositivos.

Un error de seguridad de memoria puede convertirse en un ataque cuando los datos corruptos cambian el flujo de control del programa. Un desbordamiento de búfer en la pila, por ejemplo, puede sobrescribir una dirección de retorno guardada. Las defensas del sistema operativo restringen lo que un atacante puede hacer con ese error; no reparan la escritura defectuosa.

Separa los datos del código ejecutable

El bit NX marca las páginas de datos como no ejecutables. Windows llama a esto prevención de ejecución de datos (DEP). Inyectar instrucciones en un búfer de la pila resulta menos útil cuando saltar a él provoca un fallo.

W^X, escritura o ejecución excluyentes, es más estricta: ninguna página permite la escritura y la ejecución al mismo tiempo. DEP por sí sola no prohíbe que un programa solicite explícitamente ese tipo de mapeo. Con W^X, un compilador en tiempo de ejecución escribe el código generado en memoria que permite escritura y después cambia sus permisos antes de ejecutarlo.

Un atacante puede reutilizar instrucciones ejecutables existentes. La programación orientada a retornos (ROP) encadena secuencias cortas de instrucciones llamadas gadgets. La aleatorización de la distribución del espacio de direcciones (ASLR) cambia las ubicaciones de las pilas, los montículos, las bibliotecas y los programas independientes de la posición, lo que dificulta predecir las direcciones de los gadgets.

Con una base de biblioteca elegida de manera uniforme entre $2^{28}$ posiciones, una suposición a ciegas tiene una probabilidad de éxito de 1 entre 268 435 456. Con solo $2^8=256$ posiciones y una distribución que se conserva tras los fallos de los procesos trabajadores, probar posiciones distintas requiere como máximo 256 intentos y 128,5 de media. Una dirección filtrada dentro de una biblioteca conocida revela su base y los desplazamientos de los gadgets de esa biblioteca. Una pila aleatorizada por separado puede seguir siendo desconocida.

Reduce los servicios que puede solicitar un atacante

Los filtros seccomp de Linux restringen las llamadas al sistema que puede realizar un proceso. Por ejemplo, se pueden denegar a un proceso de renderizado del navegador las llamadas para iniciar programas o abrir archivos directamente. Los procesos hijos heredan los filtros y estos no pueden eliminarse; los filtros posteriores pueden reforzar las restricciones. Un proceso de renderizado comprometido sigue teniendo sus operaciones permitidas, por lo que un filtro establece un límite para los servicios, no demuestra que el programa carezca de errores. pledge de OpenBSD y App Sandbox de macOS proporcionan restricciones relacionadas.

Comprueba el arranque y conserva las pruebas

El arranque seguro comprueba las firmas a lo largo de la cadena de arranque. El firmware comprueba un cargador de arranque de confianza; el cargador comprueba el núcleo; el núcleo puede exigir módulos firmados. Se rechaza un componente modificado que no tenga una firma de confianza. Esto ayuda a detener cambios persistentes en el software de arranque, pero una firma válida no demuestra que el software carezca de vulnerabilidades.

El arranque medido registra hashes de los componentes cargados, normalmente mediante un módulo de plataforma de confianza (TPM). Estas mediciones permiten la atestación: otra parte puede comparar lo que se inició con un estado esperado. Medir y negarse a iniciar son operaciones distintas.

El registro de auditoría recoge inicios de sesión, fallos de autenticación, denegaciones de permisos, cambios de cuentas y acciones privilegiadas como sudo. Los registros ayudan a detectar y reconstruir ataques. Un atacante que controla un anfitrión puede borrar los registros locales, por lo que el registro protegido o remoto conserva pruebas fuera de ese anfitrión.

Los atacantes pueden combinar una filtración de direcciones, un error de corrupción de memoria y un escape del entorno aislado. Las actualizaciones eliminan las vulnerabilidades subyacentes que estas defensas dejan presentes.

Un inicio de sesión correcto conecta una identidad humana con credenciales de proceso mantenidas por el núcleo. La autenticación comprueba la identidad declarada; la autorización decide qué puede hacer esa identidad. Una entidad de seguridad puede ser una persona o una cuenta de servicio, y los procesos actúan en su nombre.

Lleva la identidad a los programas en ejecución

Los sistemas de tipo Unix identifican a los usuarios mediante UID numéricos y a los grupos mediante GID. /etc/passwd relaciona los nombres con los UID, los directorios personales y los intérpretes de comandos. Las comparaciones del núcleo usan los números: dos nombres de cuenta con un mismo UID son una sola identidad para las comprobaciones de acceso. El UID 0 es root y elude la mayoría de las comprobaciones ordinarias de permisos.

Windows usa identificadores de seguridad (SID) para usuarios y grupos. El token de acceso de un proceso registra su SID de usuario, los SID de grupo y los privilegios. En ambas plataformas, las credenciales del programa en ejecución proporcionan la identidad para las decisiones posteriores.

Un inicio de sesión típico con contraseña en Linux sigue esta secuencia:

1. Un servicio de inicio de sesión privilegiado, como login, sshd o un gestor de inicio de sesión gráfico, recibe las credenciales.
2. PAM, módulos de autenticación conectables, las comprueba mediante los módulos de autenticación configurados.
3. El servicio establece los grupos suplementarios y el GID del usuario y después cambia el UID para renunciar a root.
4. Inicia el intérprete de comandos. Los procesos hijos heredan estas credenciales mediante fork() y normalmente las conservan tras execve().

El orden importa. Renunciar a root antes de establecer los grupos puede hacer que el proceso no pueda sustituir su lista heredada de grupos privilegiados. Además, modificar la pertenencia a grupos de una cuenta no cambia las credenciales de los procesos que ya están en ejecución; una nueva sesión recibe la lista nueva.

Comprende un cambio controlado de privilegios

Un proceso tiene un UID real, que normalmente identifica quién lo inició; un UID efectivo, usado para la mayoría de las comprobaciones de acceso; y un UID guardado, que permite recuperar el anterior de forma controlada después de una reducción temporal. En los programas ordinarios los tres son iguales.

/usr/bin/passwd, propiedad de root, ilustra setuid. Su modo 4755, mostrado como -rwsr-xr-x, hace que el UID efectivo sea root cuando lo ejecuta un usuario ordinario. Si alice tiene el UID 1000, su UID real sigue siendo 1000 mientras el UID efectivo pasa a ser 0. El programa puede actualizar /etc/shadow y usa la identidad real de quien hace la llamada para limitar la contraseña que puede cambiar. Un ejecutable setgid cambia de forma similar el grupo efectivo.

Ese pequeño programa de confianza tiene una autoridad peligrosa. Un error puede exponer los derechos de root, por lo que los sistemas reducen al mínimo los programas setuid y rebajan pronto los privilegios. Para un servicio que solo necesita un puerto de número bajo, CAP_NET_BIND_SERVICE concede un privilegio de Linux más limitado que los derechos completos de root.

Administra sin compartir una identidad

sudo autentica al usuario que lo invoca, comprueba qué comandos puede ejecutar ese usuario y con qué identidad de destino, y registra su uso. Su política suele estar en /etc/sudoers. Las identidades individuales permiten atribuir responsabilidades, algo que se pierde al compartir una contraseña de root. En Windows, UAC normalmente inicia los programas de un administrador con un token filtrado y solicita consentimiento para elevar los privilegios.

Las aplicaciones de uso diario deben ejecutarse con derechos ordinarios, y los servicios deben tener cuentas específicas como www-data. Así, un visor de documentos comprometido hereda esas credenciales limitadas en lugar de la autoridad completa de un administrador.

Un verificador de contraseñas necesita reconocer una contraseña correcta sin almacenar una copia recuperable. Almacena un hash de contraseña con la información necesaria para repetir la comprobación. El inicio de sesión vuelve a calcular el hash a partir de la contraseña introducida y compara los resultados; nunca descifra el hash almacenado.

Protege el verificador almacenado

En Linux, /etc/shadow contiene hashes de contraseñas protegidos. /etc/passwd, legible por muchos usuarios, contiene información de las cuentas y una x en lugar de la contraseña. Un campo de contraseña de shadow registra un identificador de algoritmo, parámetros de coste, una sal y el hash resultante. $y$ identifica yescrypt, usado de forma predeterminada en Debian 11, Ubuntu 22.04, Fedora 35 y versiones posteriores; $6$ identifica SHA-512-crypt.

Un archivo de hashes robado permite un ataque sin conexión. El atacante calcula hashes de contraseñas candidatas en otro hardware sin las demoras del servicio de inicio de sesión. Un ataque de fuerza bruta enumera cadenas; un ataque de diccionario comienza con palabras probables, contraseñas filtradas y variantes como «Password1!».

Para exactamente ocho letras minúsculas, son posibles ${26}^8=208827064576$ cadenas. A ${10}^{10}$ intentos por segundo, agotar el espacio tarda unos 21 segundos. A ${10}^4$ intentos por segundo, tarda unos $\mathrm{2,09}\times {10}^7$ segundos, aproximadamente 242 días. Estos son tiempos de búsqueda completa, no garantías para una contraseña concreta. Doce letras minúsculas dan unos $\mathrm{9,5}\times {10}^{16}$ cadenas, aproximadamente 110 días incluso a la velocidad mayor.

Haz que atacar cada cuenta sea costoso

Una sal criptográfica es un valor aleatorio nuevo almacenado junto a cada hash de contraseña. Hace que contraseñas iguales produzcan hashes distintos e inutiliza las tablas precalculadas reutilizables. La sal es pública; su función es obligar a realizar un trabajo separado para cada cuenta.

Considera 1000 cuentas y una lista de ${10}^6$ contraseñas candidatas, comprobadas a ${10}^4$ hashes por segundo. Sin sales, calcular la lista una vez tarda 100 segundos y sirve para todas las cuentas. Las sales únicas requieren ${10}^9$ cálculos, unos ${10}^5$ segundos o 27,8 horas. Una contraseña común aún puede encontrarse cerca del principio de la lista.

Los esquemas de cálculo de hashes de contraseñas como bcrypt, scrypt, yescrypt, Argon2 y PBKDF2 tienen costes de trabajo ajustables. Scrypt, yescrypt y Argon2 también imponen costes de memoria. Un inicio de sesión práctico puede tolerar una fracción de segundo; una campaña de adivinación a gran escala repite ese gasto millones de veces. Un único cálculo rápido de SHA-256 carece de este coste deliberado.

Diseña la política de inicio de sesión en función de los intentos de adivinación

NIST SP 800-63B-4 (2025) exige sales de al menos 32 bits y un coste de cálculo de hashes de contraseñas tan alto como resulte práctico. Su guía sobre contraseñas exige al menos 15 caracteres para la autenticación solo con contraseña, o al menos ocho cuando la contraseña forma parte de MFA, y recomienda aceptar al menos 64 caracteres.

Rechaza las combinaciones obligatorias, como un dígito y un símbolo, y los cambios periódicos obligatorios de contraseña. Exige bloquear opciones comunes o comprometidas, limitar los intentos de adivinación en línea y obligar a cambiar la contraseña cuando haya indicios claros de compromiso. Los límites de frecuencia en línea protegen el servicio activo; el cálculo lento de hashes con sal protege los verificadores robados. Una contraseña más larga elegida de forma predecible de una lista común aún puede ser débil.

Las contraseñas demuestran conocimiento. Otros autenticadores demuestran la posesión de un objeto o un rasgo físico. El sistema operativo acaba asociando la identidad autenticada a los procesos, pero la vía para obtener esa identidad influye en la facilidad con que un atacante puede suplantar al usuario.

Combina distintos tipos de factores

Los tres tipos de factores son algo que sabes, como una contraseña o un PIN; algo que tienes, como un teléfono, una tarjeta inteligente o una llave de seguridad; y algo que eres, como una huella dactilar. La autenticación multifactor (MFA) combina distintos tipos. Una contraseña más una pregunta de seguridad repite el factor de conocimiento.

Las contraseñas de un solo uso basadas en el tiempo (TOTP) usan un secreto compartido y un intervalo de tiempo, normalmente de 30 segundos, para producir códigos coincidentes en un autenticador y un servidor. RFC 6238 define el método. Un código caduca rápidamente, pero una página de inicio de sesión falsa puede retransmitir un código reciente antes de que caduque. Los códigos de aplicaciones evitan el intercambio de SIM; los códigos SMS dependen del control del número de teléfono y pueden redirigirse si alguien toma el control de él.

Demuestra la posesión sin enviar la clave

Un autenticador de clave pública firma un desafío nuevo con una clave privada. El servidor lo verifica con una clave pública almacenada, que por sí misma no puede reutilizarse para firmar un inicio de sesión. Las llaves de seguridad FIDO2 y las claves de acceso también vinculan la autenticación a la identidad del sitio, por lo que una respuesta para un sitio falso no puede autenticar en el real. Una clave SSH ordinaria también demuestra posesión, pero no debe suponerse que tenga el mismo mecanismo de vinculación al sitio web.

El almacenamiento cambia el riesgo. Las claves vinculadas a un dispositivo en una llave de seguridad física, un TPM o un enclave seguro firman dentro del hardware sin exponer la clave privada. Las claves de acceso sincronizadas copian material de claves cifrado entre dispositivos mediante una cuenta de plataforma, lo que facilita la recuperación, pero incorpora esa cuenta al límite de confianza. Una clave privada SSH ordinaria es un archivo protegido por permisos y, opcionalmente, por una frase de contraseña.

Interpreta los errores biométricos

Un sistema biométrico compara las características medidas con una plantilla almacenada. Acepta cuando una puntuación de similitud alcanza un umbral; no exige una imagen idéntica cada vez.

Dos impostores aceptados de 10 000 dan una FAR del 0,02 %. Treinta rechazos de 1000 intentos legítimos dan una FRR del 3 %. Elevar el umbral de similitud reduce la FAR y aumenta la FRR. Una coincidencia más exigente reduce las suplantaciones exitosas, pero hace más frecuentes los nuevos intentos legítimos.

Un rasgo biométrico filtrado no puede cambiarse como una contraseña, y los sensores necesitan defensas frente a fotos o huellas copiadas. Un diseño útil usa la biometría localmente para desbloquear una clave protegida y envía solo una firma al servidor.

Autentica también a los procesos

Para una conexión local de dominio Unix, SO_PEERCRED de Linux obtiene las credenciales del otro extremo desde el núcleo en lugar de confiar en un nombre enviado por el cliente. Entre máquinas, los servicios usan claves, certificados o tokens almacenados con acceso restringido a la cuenta de servicio. Después de iniciar sesión, las comprobaciones ordinarias de acceso del sistema operativo usan el UID o el token de acceso; no preguntan si el usuario escribió una contraseña o tocó una llave.

Una decisión de acceso tiene tres partes: un sujeto solicita realizar una operación sobre un objeto. El sujeto suele ser un proceso que actúa en nombre de una entidad de seguridad; los objetos incluyen archivos, dispositivos y otros procesos. Una matriz de acceso representa los derechos en celdas, con los sujetos como filas y los objetos como columnas.

Almacena los mismos derechos de dos formas

Supón que alice puede leer y escribir report.txt, bob solo puede leerlo y el servicio de copias de seguridad puede leer tanto report.txt como payroll.db. Bob también puede leer y escribir payroll.db. Alice y bob pueden usar la impresora; el servicio de copias de seguridad no. La mayoría de las celdas de la matriz mucho mayor de un sistema real están vacías.

Una lista de control de acceso (ACL) almacena una columna junto con su objeto. La lista de report.txt nombra a alice, bob y backup con sus respectivos derechos. Una lista de capacidades almacena una fila junto con el sujeto. Bob posee tokens para leer el informe, leer y escribir la nómina y usar la impresora.

Una capacidad identifica tanto un objeto como las operaciones permitidas y su poseedor no puede falsificarla ni ampliarla. Se permiten la copia y la delegación autorizadas. El núcleo puede conservar el token real mientras el código de usuario tiene un índice; otro diseño protege el token mediante criptografía.

Sigue un descriptor después de abrir un archivo

Unix combina ambos enfoques. open() comprueba a quien hace la llamada frente a los permisos del archivo y después devuelve un descriptor de archivo que registra el acceso concedido. Las lecturas y escrituras posteriores comprueban ese identificador abierto. Un proceso hijo puede heredarlo mediante fork(), o un proceso puede recibirlo por un socket de dominio Unix.

Alice abre app.log para escribir. Su propietario cambia el modo a 444. El descriptor que alice ya tiene abierto puede seguir usándose para escribir; un nuevo intento de abrir el archivo para escritura encuentra el nuevo modo. Actualizar la ACL que rige las aperturas futuras no cancela todas las capacidades ya emitidas. Los identificadores de Windows siguen el mismo patrón general.

Capsicum de FreeBSD hace que esto sea útil para el confinamiento. Después de cap_enter(), un proceso no puede abrir una ruta absoluta arbitraria. Puede operar mediante descriptores existentes, recibir descriptores y usar openat() bajo un descriptor de directorio que posea. Por tanto, un proceso padre puede dar a un trabajador exactamente los archivos que necesita. Los núcleos basados en capacidades, como seL4 y Fuchsia, extienden la idea a los objetos del núcleo en general.

Distingue el otro significado de capacidad en Linux

Las capacidades de Linux dividen los privilegios de root en categorías. CAP_NET_BIND_SERVICE permite asociarse a puertos de número bajo; CAP_DAC_OVERRIDE elude las comprobaciones ordinarias de acceso a archivos. Estos privilegios no identifican un objeto concreto, por lo que son distintos de una capacidad de la matriz de acceso. Un único privilegio de Linux puede autorizar una clase de operaciones sobre muchos objetos.

Los permisos de Unix asignan derechos al propietario, al grupo propietario y a todos los demás. Para decidir sobre un acceso, identifica primero la operación y el objeto correspondiente. Leer el contenido de un archivo, atravesar un directorio y eliminar un nombre requieren permisos distintos.

Descifra y selecciona los bits

Lectura es 4, escritura 2 y ejecución 1. Suma estos valores para cada clase: 754 significa rwxr-xr--; 640 significa rw-r-----. chmod 640 notes.txt establece un modo, mientras que chmod g+w,o-r notes.txt modifica determinados bits. El propietario o root pueden cambiar el modo; cambiar la propiedad requiere autoridad de root, representada por CAP_CHOWN en Linux.

El núcleo selecciona la primera clase que coincide: propietario si coincide el UID efectivo; en caso contrario, grupo si coincide un grupo del proceso; de lo contrario, otros. No combina clases ni vuelve a intentar con una más permisiva. Alice es propietaria de un archivo con modo 077: sus bits de propietario están vacíos, por lo que no puede leerlo aunque el grupo y los demás tengan todos los derechos. Como propietaria, aún puede cambiar el modo.

Root normalmente elude las comprobaciones de lectura y escritura. Para ejecutar un archivo ordinario bajo las comprobaciones discrecionales habituales de Linux, debe estar activado al menos un bit de ejecución. La política obligatoria puede imponer más restricciones.

Interpreta los bits de directorio y los bits especiales

La lectura de un directorio permite listar nombres; la ejecución permite atravesarlo y buscar en él; la escritura junto con la ejecución permite crear, eliminar y renombrar entradas. Eliminar un nombre modifica su directorio, por lo que alguien con los derechos necesarios sobre el directorio puede eliminar un archivo con modo 000.

Setuid añade 4000 en octal al modo de un ejecutable y cambia la identidad efectiva de usuario al ejecutarlo. Setgid añade 2000 y cambia el grupo de forma similar; en un directorio hace que los archivos nuevos hereden el grupo del directorio. El bit de permanencia añade 1000. Un directorio como /tmp, con modo 1777, permite la eliminación o el cambio de nombre solo al propietario del archivo, al propietario del directorio o a un proceso privilegiado, y siguen siendo necesarios los permisos ordinarios del directorio.

Elimina bits al crear archivos

Una umask desactiva bits del modo que solicita un programa. Es una operación con bits, no una resta octal. Con las solicitudes habituales de 666 para archivos y 777 para directorios:

Una umask no puede añadir derechos de ejecución que estaban ausentes de la solicitud para el archivo.

Interpreta listas de acceso más detalladas

Las ACL POSIX añaden usuarios y grupos con nombre. setfacl -m u:bob:r report.txt da a bob una entrada de lectura con nombre; getfacl la muestra y ls -l marca la ACL ampliada con +. La máscara de ACL limita a los usuarios y grupos nombrados y al grupo propietario, por lo que una entrada con nombre puede mostrar más derechos de los que son efectivos.

Windows NTFS usa un descriptor de seguridad con un SID de propietario y una DACL de ACE ordenadas de autorización o denegación. La evaluación se detiene cuando se deniega un derecho solicitado o se han concedido todos los derechos solicitados; los derechos que no se conceden se deniegan. El orden preferido sitúa las entradas explícitas antes de las heredadas, con las de denegación antes de las de autorización dentro de cada grupo. Por tanto, una autorización explícita puede resolver una solicitud antes de llegar a una denegación heredada. Una SACL independiente selecciona los eventos de acceso que se auditan.

Los distintos modelos de control de acceso responden a distintas preguntas de gestión. ¿Quién puede conceder acceso? ¿Puede un programa comprometido compartir los datos de un usuario? ¿Cómo puede un administrador cambiar los derechos de muchos empleados sin editar cada archivo? Un sistema operativo puede aplicar varios modelos a una misma solicitud.

Distingue la elección del propietario de la política del sistema

En el control de acceso discrecional (DAC), el propietario de un objeto decide quién puede usarlo. Los modos y las ACL de Unix son mecanismos conocidos. Su debilidad es que un programa malicioso que actúe como el usuario puede ejercer los derechos de este, incluida la copia de los datos que puede leer a otro lugar.

En el control de acceso obligatorio (MAC), la política de un administrador para todo el sistema limita el acceso independientemente de los deseos del propietario. El núcleo aplica MAC además de DAC. Ambas comprobaciones deben permitir el acceso, por lo que un modo de archivo permisivo no anula una denegación obligatoria.

El modelo de Bell–LaPadula protege la confidencialidad con niveles ordenados y dos reglas: no leer hacia arriba y no escribir hacia abajo. Un proceso de nivel Secreto puede leer datos Confidenciales y escribir en un destino de nivel Alto secreto. No puede leer datos de nivel Alto secreto ni escribir datos Confidenciales. Un programa no puede trasladar información de Secreto a Confidencial simplemente leyéndola y volviéndola a escribir. Biba invierte las direcciones de lectura y escritura para proteger la integridad.

Confina un servicio incluso cuando es root

SELinux etiqueta los archivos con tipos y ejecuta los procesos en dominios. La política indica qué operaciones puede realizar cada dominio sobre cada tipo; el acceso no incluido se deniega. Un servidor web en httpd_t puede leer páginas etiquetadas como httpd_sys_content_t mientras se bloquea su acceso a user_home_t, aunque los modos Unix ordinarios permitan la lectura. ls -Z muestra las etiquetas.

En modo de aplicación, SELinux bloquea y registra las infracciones. En modo permisivo, registra sin bloquear. Root en un dominio confinado sigue teniendo que cumplir la política en modo de aplicación. Por tanto, tener UID 0 y tener acceso sin restricciones son afirmaciones distintas.

AppArmor confina programas mediante perfiles basados en rutas de archivos y capacidades permitidas. Se usa habitualmente en Ubuntu y SUSE. SELinux y AppArmor funcionan mediante puntos de integración de los módulos de seguridad de Linux (LSM) en las decisiones de seguridad. Android combina UID específicos para cada aplicación con SELinux; los sistemas de Apple también usan perfiles de aislamiento de aplicaciones.

Asigna puestos en lugar de derechos individuales

En el control de acceso basado en roles (RBAC), los permisos se asocian a roles y los usuarios reciben esos roles. Cambiar a una persona de puesto modifica su pertenencia a roles en lugar de muchos permisos independientes sobre objetos.

Supón que 50 empleados necesitan 20 permisos cada uno. La asignación directa necesita 1000 vínculos de permiso a usuario. Si cinco roles tienen 20 permisos cada uno y cada empleado tiene un rol, la gestión necesita 50 vínculos de usuario a rol y 100 vínculos de permiso a rol: 150 en total. El ahorro procede de patrones de trabajo compartidos, no de eliminar permisos necesarios.

Los grupos de Windows usados como roles y las políticas de sudo basadas en grupos implementan este patrón. DAC es adecuado para archivos gestionados por sus propietarios, MAC contiene servicios mediante reglas aplicadas de forma centralizada y RBAC organiza las asignaciones administrativas. Un servicio puede recibir los derechos de su función mediante un rol mientras DAC y MAC comprueban su acceso real a los archivos.

Una máquina virtual (VM) proporciona a un sistema operativo completo su propio equipo aparente. Ese sistema operativo es el sistema invitado. El equipo físico es el anfitrión, y el hipervisor, o monitor de máquina virtual (VMM), asigna tiempo real de procesador, memoria y dispositivos a los invitados.

Conserva el comportamiento mientras mantienes el control

El marco de Popek y Goldberg de 1974 identifica tres propiedades. Equivalencia significa que los programas se comportan como en una máquina real, salvo por los tiempos y los recursos disponibles. Control de recursos significa que el hipervisor mantiene el control del hardware. Eficiencia significa que la mayoría de las instrucciones del invitado se ejecutan directamente en el procesador.

El hipervisor planifica las CPU virtuales (vCPU) en los núcleos físicos. Un cambio de máquina guarda todo el estado de ejecución de una VM, incluidos los registros privilegiados y la configuración de interrupciones, y después restaura el de otra. Un invitado ve su propio estado incluso cuando comparte un núcleo físico con otros invitados.

KVM convierte el propio núcleo de Linux en un hipervisor y suele clasificarse como de tipo 1. Sigue estando disponible un anfitrión Linux completo, lo que hace menos clara la distinción sencilla entre dos tipos. Para razonar sobre la protección, identifica qué componente controla realmente la virtualización de CPU y memoria.

Usa la abstracción de máquina

La consolidación de servidores reúne sistemas poco utilizados. Doce servidores que usan cada uno una media del 5 % de un equipo de ocho núcleos necesitan en conjunto el 60 % de un equipo de ese tipo. Esa media sugiere que la consolidación es posible, pero los picos simultáneos y la demanda de RAM y dispositivos siguen requiriendo margen.

Una instantánea guarda el estado de una VM para restaurarlo más adelante. Copiar solo una imagen de disco no captura una CPU en ejecución ni su memoria. La migración en vivo transfiere una VM en ejecución a otro anfitrión, copiando la memoria y cambiando la ejecución con una breve pausa. Estas operaciones son posibles porque el estado de la máquina invitada se representa como datos que gestiona el hipervisor.

Las VM también permiten probar sistemas antiguos, separar software incompatible y ejecutar distintos sistemas operativos en hardware compatible. Una VM puede ejecutar un invitado Windows junto a un invitado Linux, cada uno con su propio núcleo. Las instancias de servidores en la nube suelen usar este límite.

Separa la virtualización de la emulación completa

Un emulador puede interpretar o traducir un conjunto de instrucciones para un procesador diferente, como código ARM en x86. La virtualización por hardware normalmente ejecuta las instrucciones del invitado directamente en un procesador compatible e interviene ante eventos sensibles. Esto explica tanto su velocidad como su necesidad de soporte de la CPU.

Los núcleos invitados separados forman un límite útil: tomar el control de un núcleo invitado no da directamente el control del núcleo anfitrión. El límite sigue dependiendo del funcionamiento correcto del hipervisor y del código de los modelos de dispositivos. Un escape de VM explota esa capa, mientras que un canal lateral puede filtrar datos a través del hardware compartido sin conceder acceso ordinario a la memoria. Elegir una VM reduce las interfaces expuestas a un invitado no confiable; no hace infalible el hardware compartido.

Un núcleo invitado espera controlar su máquina. El hipervisor debe mantener esa apariencia sin ceder el equipo real. La virtualización de la CPU permite que las instrucciones ordinarias del invitado se ejecuten directamente e intercepta las operaciones que necesitan cambiar el estado de la máquina virtual.

Intercepta y emula el estado virtual

En la intercepción y emulación clásica, se reducen los privilegios del núcleo invitado. Su intento de cargar un registro de tabla de páginas o instalar una tabla de trampas provoca una trampa hacia el hipervisor. El hipervisor actualiza el registro o la tabla virtual del invitado y reanuda la ejecución. No permite que el invitado sustituya las estructuras de control reales del hipervisor.

Una llamada al sistema del invitado puede requerir varios cruces en este diseño. La aplicación invitada provoca una trampa hacia el manejador real del hipervisor. El hipervisor transfiere la ejecución al manejador registrado del núcleo invitado con privilegios reducidos. Cuando el núcleo invitado retorna, ese retorno privilegiado provoca otra trampa; el hipervisor completa el retorno real a la aplicación invitada.

La condición de Popek y Goldberg para esta técnica es que toda instrucción sensible debe ser privilegiada. Sensible significa que cambia la configuración de la máquina o se comporta de forma diferente según los privilegios. Privilegiada significa que provoca una trampa fuera del modo más privilegiado. Las diferencias silenciosas no pueden emularse si el hipervisor nunca sabe que ocurrieron.

Comprende el obstáculo del x86 clásico

El análisis de Robin e Irvine de 2000 identificó 17 instrucciones x86 sensibles no privilegiadas. Por ejemplo, POPF puede restaurar el indicador de habilitación de interrupciones con suficientes privilegios, pero lo deja sin cambios de forma silenciosa con privilegios reducidos. Un invitado con privilegios reducidos puede creer que desactivó las interrupciones aunque ninguna trampa avisó al hipervisor para que actualizara su estado virtual de interrupciones.

Tres enfoques resuelven este problema:

VMware usó la traducción binaria en 1999; Xen usó la paravirtualización en 2003. Intel VT-x llegó en 2005 y AMD-V en 2006. Las aplicaciones ordinarias del invitado pueden seguir ejecutándose directamente cuando el código del núcleo necesita traducción o hiperllamadas.

Separa el número de anillo del modo de virtualización

Con Intel VT-x, el hipervisor funciona en modo VMX raíz y un invitado en modo no raíz. Allí, el núcleo invitado puede usar el anillo 0. El anillo 0 de un invitado no da control sobre el anfitrión físico.

Los eventos configurados provocan una salida de la máquina virtual, que guarda el estado de la vCPU en una estructura de control como la VMCS. El hipervisor gestiona el evento y reanuda la ejecución mediante una entrada en la máquina virtual. Muchas llamadas al sistema pueden permanecer por completo dentro del invitado. ARM usa EL2 para el hipervisor; RISC-V proporciona una extensión de hipervisor.

Si un invitado ejecuta HLT y ese evento está configurado para provocar una salida, el hipervisor marca su vCPU como en espera y planifica otro trabajo hasta que llega una interrupción virtual. El núcleo físico no tiene por qué permanecer inactivo. Las salidas y entradas siguen costando tiempo, normalmente de cientos a miles de ciclos, por lo que la agrupación y las interfaces paravirtuales siguen siendo valiosas.

Una aplicación invitada usa una dirección virtual del invitado. Su núcleo la traduce a una dirección física del invitado, que es la perspectiva que este tiene de la RAM. Después, el hipervisor mapea esa dirección a una dirección física del anfitrión, o de máquina. Cada invitado puede creer que su RAM comienza en cero mientras usa marcos reales diferentes.

Conserva el desplazamiento dentro de la página

Usa páginas de 4 KiB. El invitado mapea la página virtual 2 al marco 7 del invitado; el hipervisor mapea el marco 7 del invitado al marco 42 de la máquina. Para la dirección 0x2ABC:

1. Divídela en la página 2 y el desplazamiento 0xABC.
2. Sustituye la página 2 por el marco 7 del invitado, lo que da 0x7ABC.
3. Sustituye el marco 7 del invitado por el marco 42 de la máquina, 0x2A en hexadecimal.
4. Conserva el desplazamiento, lo que da la dirección de máquina 0x2AABC, o 174 780 bytes desde la dirección cero.

Solo cambia el número de página. Tratar la dirección física del invitado como una dirección real de RAM eludiría la decisión de asignación y aislamiento del hipervisor.

Compara la traducción por software y por hardware

Las tablas de páginas sombra mapean las páginas virtuales del invitado directamente a marcos de máquina. La MMU real usa estas tablas, construidas por el hipervisor. El hipervisor protege contra escritura las páginas que contienen las tablas de páginas del invitado e intercepta los cambios y las sustituciones de sus tablas para que las tablas sombra sigan siendo consistentes. Por tanto, los cambios frecuentes de espacio de direcciones del invitado provocan trampas adicionales.

La paginación anidada, Intel EPT o AMD NPT, proporciona ambas etapas a la MMU. El hardware recorre las tablas del invitado y las tablas que traducen direcciones físicas del invitado a direcciones de máquina. Las actualizaciones de las tablas de páginas del invitado ya no requieren todas una interceptación por software. La TLB almacena en caché la traducción final combinada.

Un fallo de caché aún puede ser costoso. Con cuatro niveles en cada etapa, cada una de las cuatro entradas de la tabla del invitado necesita cuatro referencias a la tabla anidada más la propia entrada: 20 referencias. Traducir la dirección física de los datos finales del invitado añade cuatro más, lo que suma 24 referencias de traducción antes del acceso a los datos. Las páginas grandes y las cachés de recorrido de tablas de páginas reducen este trabajo en el peor caso sin caché.

Recupera memoria con conocimiento limitado del invitado

La sobreasignación de memoria promete más memoria total a los invitados de la que tiene el anfitrión. Cuatro VM de 16 GiB suman 64 GiB en un anfitrión de 48 GiB. Esto solo funciona mientras sus necesidades activas quepan en la memoria disponible; si todas pasan a estar ocupadas, es necesario recuperar memoria o recurrir al intercambio.

Un controlador globo dentro de un invitado asigna páginas a petición del hipervisor. El sistema operativo invitado elige qué liberar, mientras que el hipervisor recupera los marcos de máquina correspondientes a las páginas del globo. Esto reduce la brecha de información: el invitado sabe qué datos importan, mientras que el hipervisor ve las asignaciones sin conocer todo su significado.

La compartición de páginas, como Linux KSM, fusiona páginas idénticas en una copia de solo lectura y las separa al escribir. El intercambio por parte del hipervisor ofrece otra opción, pero puede elegir mal porque carece del conocimiento del invitado. Un dispositivo asignado directamente a la VM también necesita una IOMMU para traducir y restringir sus direcciones DMA.

Compartir páginas idénticas entre clientes tiene un coste para la privacidad: el tiempo de copia en escritura puede revelar si otro invitado tiene los mismos datos. Los proveedores de nube suelen desactivar esa forma de compartición entre clientes aunque ahorre memoria.

Una VM necesita almacenamiento, conexión de red y otros dispositivos, además de tiempo de CPU y RAM. La interfaz del dispositivo afecta a la compatibilidad, el rendimiento y el código al que puede acceder un invitado no confiable. Una interfaz rápida y una interfaz de confianza reducida son decisiones de diseño relacionadas, pero no son la misma propiedad.

Elige cómo accede el invitado a un dispositivo

Un programa auxiliar como QEMU puede emular una tarjeta de red Intel e1000. El controlador ordinario del invitado escribe en registros conocidos; el programa auxiliar implementa el efecto. Los accesos frecuentes a registros pueden provocar muchas salidas y operaciones de software.

En cambio, un controlador virtio intercambia solicitudes mediante colas en memoria compartida. Puede poner varias operaciones en cola y notificar una sola vez al componente que las atiende. Los dispositivos vmxnet3 de VMware y VMBus de Hyper-V siguen diseños relacionados preparados para la virtualización. Un controlador de dispositivo paravirtual no significa que todo el núcleo invitado deba usar operaciones de CPU paravirtuales.

En la asignación directa de dispositivos, el invitado dispone de un dispositivo físico o una función virtual SR-IOV. La IOMMU limita el DMA a la memoria de la VM. La asignación directa reduce la mediación del software, pero transferir el estado del dispositivo a otro anfitrión puede dificultar la migración en vivo.

Trata los discos virtuales como estado gestionado

Un disco virtual suele ser un archivo del anfitrión, como qcow2, VMDK o VHDX, o un volumen de almacenamiento. Las imágenes con copia en escritura permiten que muchos invitados compartan una base mientras registran cambios separados. Las instantáneas pueden conservar el estado del disco con poco coste, y una instantánea completa de una VM en ejecución también necesita su estado de ejecución y de memoria. La clonación y la migración dependen de la capacidad del hipervisor para gestionar estas representaciones.

Identifica el límite que debe cruzar un atacante

Un núcleo invitado comprometido ya controla esa VM, pero llegar al anfitrión requiere un escape de máquina virtual u otro fallo del límite. La vulnerabilidad VENOM de 2015 afectaba al controlador de disquetes emulado de QEMU y podía permitir que el código invitado se ejecutara en el proceso QEMU del anfitrión. Mantener la emulación de dispositivos en un proceso aislado independiente limita la autoridad expuesta por un error de este tipo.

Las cachés de CPU, los predictores de saltos y los buses de memoria compartidos también crean canales laterales. Spectre y L1TF mostraron que el aislamiento no puede evaluarse solo a partir de los mapeos de páginas. Las medidas de mitigación incluyen actualizaciones del procesador y del microcódigo, limpieza del estado pertinente entre invitados y evitar colocar simultáneamente a distintos clientes en los hilos de hardware del mismo núcleo.

La computación confidencial, que incluye AMD SEV-SNP e Intel TDX, protege la memoria del invitado frente al hipervisor con claves de cifrado mantenidas por el hardware y permite la atestación del entorno iniciado. Amplía el límite de confianza frente a un anfitrión u operador comprometido. No elimina todos los canales laterales ni todas las formas en que un anfitrión puede interrumpir el servicio. La seguridad de una VM sigue dependiendo del hipervisor, las interfaces de dispositivos, el hardware y su configuración.

Un contenedor Linux es un conjunto de procesos que usan el núcleo del anfitrión con vistas y privilegios restringidos. No tiene un núcleo separado ni un equipo emulado. Los espacios de nombres dan a los procesos instancias privadas de recursos que de otro modo serían globales.

Relaciona cada espacio de nombres con su vista

clone() con opciones de espacios de nombres crea un proceso hijo en los nuevos espacios seleccionados. unshare() separa el contexto de espacios de nombres, y setns() se une a un espacio existente mediante un descriptor como uno abierto desde /proc/1234/ns/net. La reasociación de PID afecta a los procesos hijos posteriores sin mover a quien hace la llamada. Para los espacios de nombres de tiempo, unshare(CLONE_NEWTIME) también prepara un espacio para los hijos posteriores; setns() puede mover a quien hace la llamada a un espacio de nombres de tiempo existente. Los espacios de nombres de tiempo se crean con unshare().

Por tanto, unshare --pid --fork --mount-proc bash usa --fork para crear el intérprete dentro del nuevo espacio de nombres de PID. Ese intérprete es allí el PID 1 aunque su PID en el anfitrión sea 48213. El PID 1 adopta procesos huérfanos; si termina, el núcleo termina los procesos restantes del espacio de nombres. Los procesos de un espacio de nombres antecesor pueden ver a sus descendientes, mientras que los procesos de su interior no pueden ver hacia fuera, a los espacios de nombres de PID antecesores.

Separa los archivos y la red

Un espacio de nombres de montajes proporciona una lista de montajes privada. Un entorno de ejecución reúne un árbol de archivos y lo convierte en raíz mediante pivot_root. Un contenedor puede usar /etc y /usr de otra distribución Linux mientras sigue llamando al núcleo del anfitrión. chroot por sí solo solo cambia el punto de partida de la búsqueda de rutas; no es un límite seguro frente a un proceso privilegiado.

Un espacio de nombres de red nuevo tiene una interfaz de bucle local. Un entorno de ejecución puede conectarlo mediante un par veth, con un extremo dentro y otro conectado a un puente del anfitrión. Las pilas separadas permiten que dos contenedores escuchen en el puerto 80 sin competir por un puerto del mismo espacio de nombres.

Traduce identidades entre los límites de un espacio de nombres de usuarios

Una línea de /proc/<pid>/uid_map enumera el primer identificador interno, el primer identificador externo y la longitud del intervalo. La línea 0 100000 65536 asigna los identificadores internos 0–65535 a los identificadores 100000–165535 del anfitrión. Por tanto, el UID interno 1000 se corresponde con el 101000 externo. Los identificadores sin una correspondencia utilizable se muestran normalmente como el UID de desbordamiento 65534.

Root dentro de ese espacio de nombres tiene capacidades sobre los recursos que este gobierna, no autoridad sobre todo el anfitrión. Cargar un módulo del núcleo o cambiar el reloj real del sistema sigue requiriendo privilegios en el espacio de nombres de usuarios inicial. Una correspondencia de UID no protege un socket privilegiado del entorno de ejecución que se entregue al contenedor.

Una vista privada tampoco limita el consumo. Un proceso con sus propios espacios de nombres de PID y montajes puede seguir consumiendo CPU y RAM. Los cgroups limitan las cantidades, mientras que los límites de capacidades y seccomp restringen las operaciones.

Un grupo de control, o cgroup, agrupa procesos para contabilizar y controlar sus recursos. Los espacios de nombres determinan su vista; los cgroups gobiernan cantidades como el tiempo de CPU, la memoria y el número de tareas. Los procesos hijos heredan el grupo de su padre, y la jerarquía impide que un grupo hijo escape de los límites de un antecesor.

Interpreta los archivos de cgroup v2

Cgroup v2 usa una jerarquía unificada, normalmente en /sys/fs/cgroup. Un padre habilita controladores para sus hijos mediante cgroup.subtree_control, por ejemplo +cpu +memory +pids. Los archivos individuales de cada hijo contienen límites y contadores.

Los controladores incluyen cpu, cpuset, memory, io, pids, hugetlb y rdma. Gobiernan el tiempo de CPU, la ubicación en CPU y nodos de memoria, la memoria ordinaria, la entrada/salida de bloques, el número de tareas, las páginas enormes y los recursos RDMA. Los eventos de rendimiento compatibles con cgroups permiten realizar mediciones, y cgroup.freeze pausa la ejecución de un grupo.

Distingue un límite de CPU de una proporción

cpu.max contiene la cuota y el periodo en microsegundos. 50000 100000 permite 50 ms de ejecución de CPU por cada 100 ms, lo que equivale a la mitad de una CPU. 200000 100000 permite el tiempo equivalente a dos CPU, que puede repartirse entre núcleos. max 100000 significa que no hay límite de cuota. Una vez consumida la cuota, el grupo espera al siguiente periodo aunque haya una CPU inactiva.

cpu.weight establece una proporción relativa durante la competencia, de 1 a 10 000 con el valor predeterminado 100. Para grupos ejecutables con la misma ubicación en cuatro CPU, los pesos 100 y 300 dividen el tiempo disponible en proporción 1:3: aproximadamente una CPU y tres CPU. Si el grupo de mayor peso queda inactivo, el otro puede usar las cuatro, salvo que intervenga otro límite. Un peso no es una reserva ni un límite estricto.

Contén el agotamiento de memoria y tareas

memory.high aplica presión para recuperar memoria y ralentiza las tareas por encima de su umbral. memory.max impone un límite estricto. El núcleo intenta primero recuperar memoria, incluida la caché y el espacio de intercambio disponible. Si no puede recuperar suficiente, la gestión OOM del cgroup termina un proceso elegible dentro del grupo afectado.

Para un memory.max de 512M, el límite es de 536 870 912 bytes, o 512 MiB. Un proceso con una fuga puede forzar la recuperación de memoria y finalmente una terminación por falta de memoria, pero el núcleo selecciona a la víctima y no se garantiza que sea ese proceso. El límite del grupo contiene el evento en lugar de elegir un proceso no relacionado del anfitrión.

pids.max cuenta procesos e hilos. Con un límite de 100, la creación de más procesos o hilos falla con EAGAIN, lo que contiene el crecimiento de tareas de una bomba fork. Un límite de entrada/salida como 8:0 rbps=10485760 en io.max limita las lecturas del dispositivo de bloques 8:0 a 10 MiB/s.

Estos archivos no ocultan los procesos ni los nombres de archivos del anfitrión. Además, /proc/meminfo y las herramientas que lo leen pueden mostrar la RAM del anfitrión en lugar de memory.max; el total mostrado por sí solo no demuestra que un cgroup carezca de límite. Las mediciones de recursos deben leerse en la capa que aplica el límite.

Un límite útil para un contenedor combina vistas, controles de recursos y autoridad restringida. Un árbol de archivos privado por sí solo no detiene las llamadas al sistema peligrosas, y una cuota de CPU no impide el acceso a un archivo expuesto del anfitrión. El núcleo del anfitrión aplica cada uno de estos controles.

Reduce la autoridad del proceso

Un entorno de ejecución combina espacios de nombres, cgroups y una imagen del sistema de archivos que contiene programas y bibliotecas. Puede reforzar el límite mediante estas medidas:

• Ejecutar la carga de trabajo como un usuario distinto de root o establecer correspondencias de identificadores del contenedor mediante un espacio de nombres de usuarios.
• Eliminar capacidades de Linux, especialmente poderes amplios como CAP_SYS_ADMIN y CAP_SYS_MODULE.
• Aplicar seccomp para restringir llamadas innecesarias.
• Aplicar una política de SELinux o AppArmor.
• Hacer que el sistema de archivos raíz sea de solo lectura cuando resulte práctico.
• Establecer no_new_privs para que la ejecución de programas setuid no pueda elevar los privilegios.

Cada control cubre una vía diferente. Un sistema de archivos raíz de solo lectura sigue permitiendo las operaciones de red autorizadas; un filtro seccomp sigue permitiendo las llamadas de su lista. El diseño debe ajustarse a las operaciones que la aplicación realmente necesita.

Identifica el riesgo del núcleo compartido

Todos los contenedores ordinarios comparten el núcleo del anfitrión. Por tanto, un error del núcleo al que se pueda acceder puede comprometer el anfitrión y otros contenedores. En una VM, explotar el núcleo invitado da el control de ese invitado; llegar al anfitrión requiere otro fallo en el límite del hipervisor o de los dispositivos.

Root dentro de un contenedor es especialmente delicado. Sin un espacio de nombres de usuarios, es el UID 0 para el núcleo del anfitrión, limitado por las capacidades, los filtros y la política obligatoria. El modo privilegiado o el acceso al sistema de archivos raíz del anfitrión pueden eliminar esas restricciones. Un socket del entorno de ejecución propiedad de root también es peligroso: su cliente puede pedir al entorno que realice acciones privilegiadas. Asignar root del contenedor a un identificador sin privilegios del anfitrión no hace seguro ese socket ni elimina las vulnerabilidades del núcleo.

Elige un límite para la carga de trabajo

Un contenedor Linux necesita un núcleo Linux. Por ello, las plataformas de Windows y macOS suelen proporcionar una VM Linux debajo de los contenedores Linux. Las VM arrancan un sistema operativo y asignan memoria para cada núcleo; los contenedores inician procesos ordinarios y pueden alojar cargas de trabajo con mayor densidad.

Reconoce los diseños intermedios

gVisor gestiona muchas llamadas al sistema del contenedor en un núcleo en espacio de usuario, lo que reduce el contacto directo con el núcleo del anfitrión. Kata Containers proporciona a cada entorno aislado, normalmente un pod de Kubernetes, una VM ligera; los contenedores de ese entorno comparten su núcleo invitado. Firecracker proporciona micromáquinas virtuales con un modelo mínimo de dispositivos para plataformas que ejecutan funciones o cargas de trabajo de contenedores, incluida AWS Lambda.

Los sistemas en la nube suelen colocar contenedores dentro de VM: una VM separa a los clientes mientras los contenedores organizan las aplicaciones de un cliente. Los núcleos invitados y el núcleo del anfitrión siguen siendo distintos, por lo que un escape de contenedor dentro de una VM no demuestra por sí solo un escape del hipervisor.