Recientemente, he oído hablar de una nueva tecnología de virtualización llamada contenedores. Supongamos que el contenedor se ha comprometido, ¿significa esto que el host también está comprometido (ya que el contenedor es un proceso en un host)? En términos de seguridad, ¿es una máquina virtual (VM) más segura que los contenedores?
Si el núcleo está comprometido en el contenedor, el host está comprometido.
Aparentemente, un contenedor comprometido no debería poder dañar al host. Sin embargo, la seguridad del contenedor no es excelente, y generalmente hay muchas vulnerabilidades que permiten que un usuario de contenedor privilegiado ponga en peligro el host. De esta manera, los contenedores a menudo son menos seguros que las máquinas virtuales completas. Eso no significa que las máquinas virtuales no puedan ser pirateadas . Simplemente no son bastante tan malos.
Si el kernel se explota en una máquina virtual, el atacante aún necesita encontrar un error en el hipervisor. Si el kernel se explota en un contenedor, todo el sistema está comprometido, incluido el host. Esto significa que los errores de seguridad del núcleo, como clase, son mucho más graves cuando se usan contenedores.
Los contenedores a menudo se implementan utilizando espacios de nombres :
Un espacio de nombres envuelve un recurso del sistema global en una abstracción que lo hace parecer al proceso dentro del espacio de nombres que tienen su propia instancia aislada de un recurso global. Los cambios en el recurso global son visibles para otros procesos que son miembros del espacio de nombres, pero son invisibles para otros procesos.
Desafortunadamente, los espacios de nombres de Linux generalmente exponen un área de superficie de ataque mucho mayor desde el kernel. Many kernel vulnerabilidades are explotable en los espacios de nombres. Si bien no todas las soluciones de contenedor utilizan espacios de nombres de Linux, todas usan el mismo tipo de tecnología, con los mismos problemas de seguridad . Algunos contenedores, como Docker, son capaces de hacer uso de un marco de filtrado syscall llamado seccomp para reducir el área de superficie de ataque del kernel. Esto es una mejora, pero no siempre es suficiente.
De Daniel Shapira :
[...] las explotaciones del kernel pueden ser devastadoras para entornos de contenedor. Esto se debe a que los contenedores comparten el mismo kernel que el host, por lo que confiar en los mecanismos de protección integrados por sí solos no es suficiente.
Debido a que los contenedores no están tan aislados como las máquinas virtuales, sí, en cierto modo son menos seguros. Ver la respuesta del bosque.
Habiendo dicho eso, creo que vale la pena señalar que los contenedores también ofrecen algunos beneficios desde la perspectiva de seguridad de la aplicación. Debido a que normalmente ejecutan un solo proceso, limitan la superficie de ataque, por ejemplo, no hay un monitor cron o un demonio ssh ejecutándose dentro del contenedor. Las imágenes del contenedor son inmutables: al reiniciar, se cargan desde los binarios originales. No se puede sobrescribir la aplicación. La mayoría de las tecnologías de contenedores también permiten un control preciso sobre qué puertos están abiertos y para quién. Puede tener un contenedor para una base de datos al que no se puede acceder desde otra cosa que no sean sus otros contenedores.
Todo esto supone que estas características funcionan como se anuncia y no tienen fallas, por supuesto. Y si un atacante logra escapar del contenedor, nada de lo anterior se aplica. Añade un poco de sobrecarga, pero es posible un enfoque de cinturón y tirantes: contenedores encima de máquinas virtuales.
Lea otras preguntas en las etiquetas virtualization container