Seccomp en Linux: restringir aplicaciones de forma selectiva para una mayor seguridad

Seccomp Linux limita las aplicaciones exclusivamente a las llamadas al sistema que realmente necesitan, lo que reduce considerablemente la superficie de ataque del núcleo. Utilizo este mecanismo de forma específica para aislar contenedores, microservicios y servicios sensibles en una Sandbox bloquearlas sin impedir el funcionamiento de sus funciones principales.

Puntos centrales

Resumo los aspectos más importantes para ofrecer una visión general rápida y destaco cómo utilizo Seccomp en la práctica. De este modo, se obtiene una introducción clara a las políticas, los filtros y la protección de la carga de trabajo. Estos puntos me sirven de hilo conductor para la planificación, la puesta en marcha y la revisión. Ayudan a priorizar los riesgos y a elegir valores predeterminados adecuados. Teniendo en cuenta estos aspectos fundamentales, la Seguridad comprensible y manejable.

• Modo de filtrado: Los perfiles BPF de granularidad fina solo permiten las llamadas al sistema necesarias.
• Superficie de ataque: Un menor número de rutas de acceso al núcleo reduce el riesgo de exploits.
• Contenedor: Los perfiles predeterminados bloquean de forma fiable las llamadas de riesgo.
• Kubernetes: «seccompProfile» y «seccompDefault» unifican la protección.
• Flujo de trabajo: Analizar, perfilar, templar, probar, poner en marcha.

Analizo cada carga de trabajo, defino un perfil adecuado y compruebo su efecto en el funcionamiento. Así se consigue un sistema resistente Línea de base-Protección que podrá ampliarse posteriormente de forma específica.

Explicación breve de Seccomp: Modo de computación segura

Seccomp son las siglas de „Secure Computing Mode“ y limita Llamadas al sistema de un proceso a un conjunto claramente definido. Aplico el filtro allí donde las aplicaciones interactúan con el núcleo, por ejemplo, al abrir archivos, sockets o al crear otros procesos. La idea es sencilla: permitir lo que sea necesario y bloquear lo no permitido mediante un código de error o una orden «kill». Quien comprenda la interacción con el núcleo podrá crear rápidamente perfiles sólidos; un buen punto de partida es el artículo Entender las llamadas al sistema. Así se consigue una eficaz Sandbox, lo que dificulta las fugas y elimina las rutas del núcleo no deseadas.

Por qué Seccomp reduce la superficie de ataque en Linux

Cada llamada adicional al sistema aumenta potencialmente la Superficie de ataque. Reduzco esta superficie permitiendo únicamente aquellas llamadas al sistema que la aplicación utiliza de forma demostrable. De este modo, muchas cadenas de exploits pierden el acceso a funciones críticas del núcleo. Incluso cuando se ejecuta código en el proceso, un atacante a menudo se encuentra con puertas cerradas. Así es como evito que se acceda a subsistemas sensibles como ptrace, BPF o determinadas interfaces de depuración.

Lista de permitidos en lugar de lista de bloqueados: la estrategia adecuada

En entornos productivos, apuesto por Lista de permitidos: La acción predeterminada es „prohibir“, y solo se permite un conjunto de llamadas al sistema seleccionado de forma deliberada. Muchos entornos de ejecución proporcionan, por motivos de compatibilidad, perfiles de listas de bloqueo que solo bloquean las llamadas especialmente arriesgadas. Para los servicios sensibles, estrecho el cerco y solo permito lo que el análisis en tiempo de ejecución realmente muestra. Esto reduce las sorpresas ante los cambios en el núcleo y desplaza el control de „¿qué es peligroso?“ a „¿qué es necesario?“. Para cargas de trabajo genéricas, una lista de bloqueo sólida puede ser un buen punto de partida, pero en el caso de pasarelas, flujos de pago o servicios de autenticación, merece la pena dar el salto a una política de lista de permitidos con excepciones explícitas.

Modos y lógica de filtrado: de estricto a BPF

Seccomp cuenta con un modo estricto, que solo permite las operaciones «read», «write», «exit» y «sigreturn», y el modo altamente flexible Modo de filtrado a través de BPF. En la práctica, casi siempre utilizo filtros, ya que me permiten analizar con detalle las llamadas al sistema y sus argumentos. El núcleo comprueba cada llamada con el programa almacenado y decide si la permite, devuelve un error o termina el proceso. De este modo, puedo bloquear variantes concretas de una llamada al sistema, como, por ejemplo, indicadores específicos de «clone» o «unshare». Esta granularidad permite Políticas Sencillo y eficaz a la vez.

Campañas de devolución y nivel de control

Controlo de forma específica el comportamiento ante infracciones mediante acciones: permitir, errores definidos (en la mayoría de los casos EPERM o EACCES) y devolverlo mediante TRAP activar una señal, con TRACE Habilitar la depuración o finalizar el proceso o el hilo de forma sistemática. A menudo basta con devolver un error, lo que mejora la tolerancia a los errores; sin embargo, para rutas especialmente delicadas, recurro a acciones de finalización forzada. Cuando necesito realizar un diagnóstico, utilizo el registro del núcleo o acciones con registro para reducir gradualmente el perfil en entornos de prueba sin perturbar innecesariamente el funcionamiento.

El «sandboxing» y la protección mediante contenedores en la práctica

Los entornos de ejecución de contenedores ofrecen soluciones probadas Por defecto-Perfiles que bloquean las llamadas al sistema de riesgo. Partiendo de ahí, restrinjo aún más las funciones mount, unshare, bpf, ptrace, así como keyctl y perf_event_open. Las aplicaciones que procesan entradas no fiables se benefician doblemente: menos interfaz del núcleo y un caso de error claro en caso de infracciones. Incluso los navegadores web y las herramientas de sandbox se basan en esta separación entre el acceso necesario y el peligroso. De este modo, el sistema en tiempo de ejecución se mantiene manejable y previsible.

Notificación en el espacio de usuario: excepciones controladas

Para excepciones poco frecuentes, pero legítimas, utilizo el Notificador del espacio de usuario-Enfoque: un proceso de supervisión recibe solicitudes relativas a llamadas al sistema bloqueadas y puede autorizarlas o rechazarlas de forma selectiva. De este modo, reproduzco los patrones de intermediario, por ejemplo, para que solo determinadas montar-Permitir operaciones en directorios definidos. Esto reduce la necesidad de incluir excepciones generales en la política y, aun así, mantiene la flexibilidad operativa. En este sentido, es importante contar con una gobernanza clara: ¿qué comandos se permiten, cómo se auditan y cómo se evita que el propio notificador se convierta en un punto único de fallo?

Seccomp en Kubernetes y OpenShift

En Kubernetes, defino en el manifiesto del pod, a través del SecurityContext, qué perfil está activo. El perfil «seccompDefault» en el nodo garantiza que las cargas de trabajo que no especifiquen uno propio utilicen directamente un perfil adecuado. Estándar-Perfil. OpenShift y Podman también lo integran, incluida la transferencia mediante –security-opt. Puedo proporcionar los perfiles de forma centralizada e incorporarlos mediante anotaciones o enlaces de campos. De esta forma, establezco reglas claras en todo Espacios de nombres lejos.

Diseño de políticas para equipos y plataformas

Estructuro los perfiles según Clases de carga de trabajo en lugar de por equipos: interfaces web, workers, clientes de bases de datos, flujos de datos. Cada clase recibe un perfil probado, que solo completo mínimamente para casos especiales. En Kubernetes, establezco mediante una política de admisión que los pods tengan como mínimo RuntimeDefault utilizar, mientras que los espacios de nombres especialmente sensibles requieren una Localhost-Forzar el perfil. Para situaciones de depuración o incidencias, existe una vía de excepción bien definida con una vigencia limitada y una reducción adicional de la red y las capacidades, de modo que siga siendo posible realizar diagnósticos sin reducir el nivel de seguridad en general.

Creación de perfiles: flujo de trabajo desde el análisis hasta la puesta en marcha

Empiezo con un análisis de tiempos de ejecución y observo cuáles Llamadas al sistema que utiliza la aplicación en funcionamiento normal. A continuación, elaboro un perfil inicial que permita precisamente estas llamadas y excluya las rutas poco frecuentes. Después, sigo perfeccionándolo eliminando las llamadas poco frecuentes o arriesgadas, o restringiéndolas aún más. Una fase de pruebas detecta las lagunas y muestra si faltan funciones o si los códigos de error son adecuados. Solo entonces implemento la Política en producción y asigna una versión a cada cambio.

Aspectos relacionados con la arquitectura y el ABI

Las llamadas al sistema varían en función de la arquitectura y la generación del núcleo. Me aseguro de que los perfiles Multi-Arch cubran bien (por ejemplo, x86_64 y arm64) y que las variantes más recientes, como openat2 o si se tienen en cuenta las llamadas al sistema time64. En contenedores con sistemas base más antiguos, compruebo si existen rutas heredadas (por ejemplo, a través de socketcall o determinadas llamadas a la IPC). Quien libseccomp o utiliza el tiempo de ejecución para la generación, se beneficia de correspondencias estables entre los nombres de los símbolos y los números de llamadas al sistema; renuncio deliberadamente a utilizar números fijos para garantizar la portabilidad. Importante: los filtros son heredable y solo monótono se puede endurecer; lo que una vez se ha prohibido, sigue estando prohibido, incluso después de execve.

Gestión de actualizaciones y compatibilidad

Las actualizaciones de las bibliotecas y del núcleo introducen nuevas llamadas al sistema o modifican los patrones de llamada. Por eso tengo previsto realizar Pruebas de humo después de las actualizaciones y dispongo de un entorno de prueba que, en caso de duda, se puede utilizar con LOG-Acciones. Así puedo ver qué nuevas solicitudes hay antes de bloquear el entorno de producción. Además, documento deliberadamente las diferencias entre las imágenes (por ejemplo, contenedores basados en musl frente a los basados en glibc), ya que estas pueden utilizar distintas rutas de acceso a la API del kernel. Para las reversiones, es fundamental que los perfiles cuenten con un sistema de versionado claro; en caso de incidencia, cambio temporalmente a una política menos estricta, con un plazo de caducidad corto y una supervisión muy rigurosa.

Detectar patrones de error: registro y clasificación

Las llamadas al sistema bloqueadas deben poder localizarse; de lo contrario, uno anda a ciegas en el Oscuro. Activo el registro en el entorno de ejecución y analizo las métricas que muestran concentraciones y valores atípicos. Los mensajes con EPERM o EACCES suelen indicar que las reglas son demasiado restrictivas. Atribuyo los cierres inesperados al componente afectado y compruebo los indicadores o argumentos correspondientes. A continuación, ajusto la Filtros Ajusta el valor al mínimo y vuelve a probar.

Manual de solución de problemas

• Reproducir: repetir exactamente la misma entrada/tráfico y correlacionar los registros.
• Identifique: registrar la llamada al sistema en cuestión con sus argumentos (por ejemplo, mediante el registro de tiempo de ejecución o la salida de auditoría).
• Tarifa: ¿Es necesaria esta llamada? ¿Existe alguna variante que suponga menos riesgo (por ejemplo, «openat» en lugar de «open», o indicadores más específicos)?
• Personalizar: permitir el nivel mínimo, lo ideal es utilizar filtros de argumentos; mantener la acción predeterminada en «estricta».
• Asegurar: en casos excepcionales delicados, aplicar además una reducción de capacidades, un sistema de archivos de solo lectura o refinar los espacios de nombres.
• Nuevas pruebas y telemetría: tras la corrección, realizar pruebas específicas, supervisar las métricas y configurar alertas.

Comparación con SELinux, AppArmor y Capabilities

Seccomp actúa en la interfaz entre la aplicación y el núcleo, mientras que SELinux y AppArmor regulan principalmente el acceso a los objetos. Las capacidades controlan las operaciones privilegiadas, que además reduzco considerablemente. Junto con Espacios de nombres y cgroups Se crea un modelo de protección de varias capas. Separo los recursos, elimino los privilegios innecesarios y limito las rutas del núcleo a través de Seccomp. Esta combinación permite mantener las cargas de trabajo bien gestionadas y fáciles de controlar.

Rendimiento y sobrecarga

Un perfil Seccomp bien diseñado solo provoca un ligero Sobrecarga: El núcleo comprueba un pequeño programa BPF por cada llamada al sistema. En la práctica, esto apenas se nota en las cargas de trabajo habituales de la web y los servicios. Las rutas de alta frecuencia que realizan muchas llamadas al sistema (por ejemplo, el procesamiento de paquetes o los trabajadores con un uso intensivo de IPC) pueden resultar críticas. Por eso, mantengo el número de reglas reducido, utilizo filtros de argumentos en lugar de listas largas y pruebo las rutas más transitadas con pruebas de rendimiento. Si un perfil ralentiza el sistema de forma apreciable, compruebo primero si hay duplicados, coincidencias imprecisas y si determinadas llamadas poco frecuentes pueden trasladarse a un proceso independiente.

Buenas prácticas para valores predeterminados seguros

Empiezo con el perfil predeterminado del entorno de ejecución y lo adapto en función de Carga de trabajo. Los servicios de alta sensibilidad, como las puertas de enlace o los servicios de autenticación, están sujetos a normas especialmente estrictas. Incorporo los cambios en los perfiles a la integración de CI/CD y los pruebo automáticamente. Además, recomiendo una reducción drástica de las capacidades, sistemas de archivos de solo lectura y la política «NoNewPrivs». Encontrarás una guía sobre mecanismos generales de protección de hosts en Fortalecimiento del núcleo, que se complementa muy bien con Seccomp.

Endurecimiento avanzado: lo que compruebo además

Además de los sospechosos habituales (montar, dejar de compartir, bpf, ptrace, keyctl, perf_event_open) reviso las siguientes solicitudes y, según el contexto, las limito considerablemente o las bloqueo por completo:

• setns: evita el salto a otros espacios de nombres.
• process_vm_readv/process_vm_writev: impide el acceso directo a la memoria de otros procesos.
• kexec_load y reinicio: protegen contra los intentos de reinicio o de sustitución del núcleo.
• swapon/swapoff y init_module/finit_module: limitan los mecanismos de carga del sistema y de los módulos.
• clone3 con opciones de riesgo (por ejemplo, espacios de nombres): limitarlas de forma granular mediante argumentos.
• io_uring_setup: dependiendo de la carga de trabajo, permitirlo o limitarlo estrictamente, ya que se trata de una interfaz muy potente.

La pauta a seguir es: tanto como sea necesario, tan poco como sea posible; y es preferible una pequeña excepción documentada que una regla estándar demasiado amplia.

Integración en CI/CD y Teams

Trato los perfiles Seccomp como Código: crear versiones, revisar, probar. Los trabajos del pipeline comprueban si los perfiles se ajustan a la imagen y si se producen bloqueos. Las pruebas de humo con datos de prueba detectan los cambios de comportamiento más rápidamente que los clics manuales. Los desarrolladores reciben un breve manual que explica cómo funciona el registro y dónde pueden ajustar las firmas. Así es como la Seguridad directamente en el flujo de desarrollo y se mantiene actualizado.

Brevemente resumido

Seccomp limita la Llamadas al sistema limitar una aplicación a lo estrictamente necesario y, de este modo, eliminar muchas vías de ataque. Empiezo con una configuración predeterminada sólida, mido el comportamiento real y, a continuación, voy restringiendo paso a paso. Las plataformas de contenedores como Kubernetes u OpenShift me ahorran mucho trabajo básico cuando configuro «seccompDefault» y distribuyo los perfiles de forma centralizada. En combinación con las capacidades, SELinux/AppArmor, así como los espacios de nombres y los cgroups, se crea una protección múltiple eficaz. Quien siga este enfoque de forma sistemática reduce el riesgo de vulnerabilidades del núcleo y, al mismo tiempo, mantiene las cargas de trabajo bien controlable.