Marca negra: cómo OpenShift protege contra las vulnerabilidades del contenedor con SELinux

¿Alguna vez ha hecho un trabajo difícil por el bien de la sociedad, pero no se dio cuenta de sus esfuerzos, porque se ha beneficiado durante tanto tiempo que todos están acostumbrados? Este es el tipo de trabajo para usted que hacen todos los miembros de la comunidad SELinux .



Y el 18 de febrero de este año, en gran parte gracias a su trabajo, el mundo se salvó de la peligrosa vulnerabilidad de impacto de contenedores CVE-2019-5736 .

Aunque hay otros sistemas operativos y otros proyectos de código abierto que usan controles de tipo y categoría, es raro que todos los componentes configurados con SELinux se incluyan de manera predeterminada y estén listos para funcionar. Incluso con menos frecuencia, esta configuración cubre todos los niveles, hasta la solución para la orquestación de contenedores, sobre la base de la cual funciona la nube pública.

Red Hat OpenShift ha estado utilizando mecanismos de control de acceso forzado de Linux como la aplicación de tipo (TE) y la seguridad de múltiples categorías (MCS) durante ocho años. SELinux se ha utilizado en OpenShift desde 2011. En Red Hat OpenShift Online, un servicio de alojamiento disponible públicamente donde miles de desarrolladores ejecutan código en contenedores todos los días, SELinux se ha utilizado desde el principio. ¿Qué pasa con la versión de OpenShift que se usa, por ejemplo, en el centro de datos de su operador móvil favorito? De hecho, el módulo de seguridad SELinux está incluido en la plataforma de contenedor Red Hat OpenShift por defecto, ¡por defecto! Y no solo encendido, sino totalmente configurado y listo para proteger contra amenazas reales.

A diferencia de otras distribuciones de Kubernetes, Red Hat cierra la brecha entre Linux y la plataforma de orquestación de contenedores instalada encima. Es decir, Red Hat OpenShift monitorea y elimina las amenazas de seguridad en toda la pila, y no solo en una capa. Y esto se hace por defecto, desde el primer día de trabajo.

OpenShift utiliza esta configuración de forma predeterminada en Red Hat Enterprise Linux (ni siquiera necesita saber qué hay allí). El asunto no se limita a ejecutar setenforce 1. en una computadora portátil. Las reglas de control de acceso para los tipos y categorías que el inquilino aplica para trabajar con contenedores en un clúster de Kubernetes se pueden extender a cientos de nodos que pueden ser utilizados por miles de otros inquilinos.

Piense en cómo se verá la configuración de SELinux con MCS después de algunos años de uso en una gran empresa que distribuye credenciales OpenShift de izquierda a derecha. Ahora imagine que proporciona sus credenciales para iniciar sesión en su clúster OpenShift, como lo hacemos en openshift.com. La lealtad de SELinux a menudo no se reconoce por todo lo que hace en una solución OpenShift. Si le parece que el sistema operativo no es tan importante en estos días, piense si estaba protegido de la vulnerabilidad CVE-2019-5736 hasta este febrero. En OpenShift, CVE-2019-5736 está protegido desde el principio, y puede pasar a esta solución ahora .

Marcas SELinux

Una de las características de seguridad predeterminadas más efectivas implementadas en Red Hat OpenShift es Security-Enhanced Linux (SELinux). SELinux es un módulo de seguridad del kernel de Linux que proporciona control de acceso basado en políticas de seguridad. La forma en que funciona SELinux es asignar etiquetas (nombres) a todos los procesos y objetos del sistema operativo. Por lo tanto, cada elemento involucrado en las operaciones del kernel se marca y clasifica, y luego se le otorga acceso basado en un conjunto de reglas existente.

Las reglas de política definen la relación entre los procesos etiquetados y los objetos etiquetados. Las reglas definidas por el usuario en las políticas se aplican a nivel del núcleo. De forma predeterminada, todo lo que no está permitido se niega automáticamente, por analogía con un firewall que niega el acceso a todos los procesos para los que no se configuran permisos explícitos. Las siguientes ilustraciones ilustran casos de uso simples.

Imagine un sistema en el que necesita definir tipos para objetos como gatos y perros. El gato y el perro son tipos de procesos.


* Todos los dibujos son de Máirín Duffy

La clase de objetos con los que interactuarán los procesos es la alimentación. Agregue tipos de feed: cat_chow y dog_chow (Ohm-nom-nom).


Establecemos permiso para que el perro coma comida para perros (dog_chow) y para la comida para gatos y gatos (cat_chow). Escribimos estos permisos como una regla de política de SELinux:

allow cat cat_chow:food eat; allow dog dog_chow:food eat; 

De acuerdo con estas reglas, el proceso "gato" se permitirá a nivel del núcleo comer alimentos con la etiqueta cat_chow, y el perro podrá comer alimentos con la etiqueta dog_chow.


Pero recordamos que en SELinux, por defecto, todo está prohibido. Por lo tanto, si el perro intenta comer cat_chow, el núcleo no lo permitirá.


Este es el control de tipo, que juega un papel importante en la protección del sistema host de los procesos de contenedor. Los procesos de contenedor solo pueden leer y ejecutar archivos del directorio / usr y escribir datos solo en archivos de contenedor. Esta restricción protege de manera confiable el host de los contenedores, pero no protege algunos contenedores de otros, porque todos están marcados con el mismo tipo. Para proteger los contenedores unos de otros, deberá implementar el control de etiquetas MCS.

MCS no tira de un gato por la cola

El uso de MCS no está directamente relacionado con la protección de OpenShift de CVE-2019-5736 , pero es útil familiarizarse con este tema para comprender mejor los principios del uso de SELinux en OpenShift. Asignar etiquetas MCS desde el punto de vista del usuario o administrador del sistema es bastante simple. Solo necesita configurar un conjunto de categorías que sean simples etiquetas de texto (por ejemplo, Fido o Spot), y agregarles usuarios. El administrador del sistema primero configura las categorías y luego les agrega usuarios, después de lo cual los usuarios pueden usar estas etiquetas como lo deseen. Esto es conveniente porque MCS le permite usar etiquetas SELinux estándar para administrar objetos. Volvamos nuevamente al sistema imaginario del ejemplo anterior.

Agregue otra parte de la etiqueta que se aplicará al proceso del perro y al feed dog_chow. Asigne el proceso "dog" a dog: random1 (Fido) y dog: random2 (Spot).


Asignamos a la comida para perros las etiquetas dog_chow: random1 (Fido) y dog_chow: random2 (Spot).


De acuerdo con los principios de operación de MCS, si las reglas de control forzado se cumplen por tipo y las etiquetas arbitrarias de MCS coinciden exactamente, entonces se permite el acceso, y en todos los demás casos se deniega.

Intentos de Fido (perro: aleatorio1) de comer cat_chow: se negará la comida debido a los controles de tipo forzado.

Defensa en profundidad

El módulo de seguridad predeterminado de SELinux utilizado por OpenShift es un excelente ejemplo de defensa en profundidad. OpenShift, como muchas otras plataformas basadas en Kubernetes, utiliza políticas SCC / PSP que prohíben ejecutar contenedores con privilegios de root. Esta limitación también protege contra CVE-2019-5736 . En OpenShift, los contenedores que son propiedad del usuario raíz están bloqueados de manera predeterminada, pero este parámetro se puede cambiar . Incluso si permite que los contenedores se ejecuten como root, la configuración estándar de SELinux en OpenShift aún protege contra CVE-2019-5736 . Este es otro nivel de protección que realmente vale la pena en esta situación y está lejos de ser el único en OpenShift. Se puede encontrar más información en el documento 10 niveles de seguridad del contenedor .

Para obtener más información sobre CVE-2019-5736 , incluido el parche Red Hat Enterprise Linux para el tiempo de ejecución del contenedor, consulte la revisión de vulnerabilidad de Red Hat .