Seguridad de LXC en comparación con OpenVZ

6

Durante años, ahora uso OpenVZ en mi servidor, pero el soporte descontinuado para Debian y Ubuntu, las versiones actuales parecen centrarse en LXC ahora, lo cual no es una mala idea desde el punto de vista cómodo.

Pero ¿qué pasa con la seguridad? Recuerdo que leí una vez que LXC no proporciona el mismo nivel de separación de procesos y contenedores que OpenVZ. Desafortunadamente, ya no puedo encontrar el documento, pero estoy de acuerdo en que puede haber algunos problemas de seguridad al menos en la configuración predeterminada de LXC. Por ejemplo, con un rootfs completamente personalizado que manejé una vez (en una versión anterior de LXC) para cambiar el terminal del host desde un contenedor LXC usando chvt 1 y al presionar Ctrl + C, se reinició mi entorno X11 cuando intenté reproducirlo. hoy. Lo sé, todas las soluciones de contenedores usan el mismo kernel y un hack del kernel puede llevar a una ruptura de contenedores, eso no es lo que pregunto. Pero no debería ser tan fácil influir en el host u otros contenedores desde un contenedor.

¿Cuánta seguridad puedo esperar de OpenVZ y LXC?

Mi servidor expone algunos puertos invitados a Internet, así que realmente me preocupo por este aspecto, pero tengo que tomar una decisión porque las herramientas utilizadas actualmente deben actualizarse. El uso de KVM o similar no es una opción ya que mi servidor tiene una CPU de bajo rendimiento.

PS: Estoy hablando de la implementación real de OpenVZ con vzctl 4.7.2-1. Algunas implementaciones más nuevas de vzctl utilizan técnicas LXC.

    
pregunta Daniel Alder 31.01.2015 - 14:18
fuente

2 respuestas

2

(Descargo de responsabilidad: No soy no una autoridad en OpenVZ. Esta respuesta es más objetiva de lo que suelen ser mis respuestas, ¡así que siéntase libre de criticar!)

OpenVZ puede ser "más" seguro ya que no se integra con todo el kernel, por lo que su superficie de ataque es un poco menor. Sin embargo, esencialmente OpenVZ es lo que sirvió de inspiración para los espacios de nombres y, por lo tanto, en última instancia, LXC y Docker. No creo que vaya a continuar por mucho tiempo ahora que esas soluciones más completas están, bueno, completas.

Como señala WhiteWinterWolf, una de las grandes diferencias es que LXC finalmente puede usar el espacio de nombres de usuario, lo que abre la capacidad de los usuarios sin privilegios para ejecutar contenedores y garantiza que el código contenido que se desprenda del contenedor retenga los privilegios de los usuarios sin privilegios. Además, los contenedores basados en el espacio de nombres pueden eventualmente estar completamente etiquetados con SELinux. Los contenedores Docker normalmente ya lo están, y Dan Walsh está trabajando en una manera de hacer que SELinux imponga automáticamente una capa adicional de aislamiento entre contenedores al utilizar categorías generadas aleatoriamente para procesos contenidos.

En resumen, los contenedores son mejores porque: - Pueden frustrar parcialmente algunos desgloses de contenedores (limitándolos a un UID sin privilegios), haciendo que la escalada de privilegios dentro del contenedor sea irrelevante. - Son más compatibles y se desarrollan más activamente, y en particular se beneficiarán enormemente de la asistencia de SELinux.

Y son peores porque: - Su TCB es muy grande, a lo largo de todo el kernel y se producirán errores de vez en cuando, lo que conducirá a explotaciones y brotes. - El espacio de nombres de usuario me parece ser una especie de caso de ventaja. Por lo general, logra una escalada de privilegios a través de un error en el SCI (que podría reproducir después de su ruptura) o ataques confusos de agentes en un servicio privilegiado (que es probable que sigan existiendo fuera de su contenedor en primer lugar). Por lo tanto, aún tendría que limitar estrictamente el UID que se ejecuta en contenedores a los contenedores en ejecución.

En resumen, siga practicando a fondo la defensa y piense en cómo permite que los procesos contenidos interactúen con el mundo exterior y cómo ejecuta los contenedores. Las diferencias existen pero, como puedes ver, son mínimas.

    
respondido por el Steve DL 01.05.2015 - 23:16
fuente
1

Una de las técnicas de seguridad más nuevas y prometedoras específicas para LXC es el uso de contenedores de bajos privilegios, lo cual es posible solo gracias a la estrecha integración de LXC en el kernel de Linux. Se basa en los espacios de nombres de los usuarios, lo que permite a los usuarios del LXC ser vistos como "sub-usuarios" del propietario del contenedor.

Si el propietario del contenedor es root, como se requiere para la mayoría de los sistemas similares a los contenedores, esto no cambiará nada en términos de seguridad (o al menos notablemente). Sin embargo, la "magia" aquí es que el contenedor puede ser propiedad de un usuario sin privilegios, y en este caso el usuario raíz del contenedor tendrá el mismo privilegio en el sistema que el propietario del contenedor, es decir. el usuario sin privilegios.

Una buena fuente de información sobre todo esto proviene de Stéphane Grabers 'blog , uno de los desarrolladores involucrados en el proyecto LXC.

    
respondido por el WhiteWinterWolf 31.01.2015 - 14:44
fuente

Lea otras preguntas en las etiquetas