¿Qué tan peligroso es no cargar las reglas 'seccomp' para los contenedores de desarrollo (LXC)?

2

Muchos administradores desactivan seccomp en su plataforma de contenedorización en una transacción con facilidad de uso / aplicación.

Sin embargo, la desactivación de una configuración de seguridad tan básica que está tan ligada al sandboxing está, hasta cierto punto, anulando el propósito de la contenedorización. Desde el punto de vista de seguridad / estabilidad, I consideraría conveniente mantener la lista negra de la mayoría de las llamadas al sistema cuando se ejecutan los contenedores LXC / Docker en servidores (según lo configurado por LXC por defecto en /usr/share/lxc/config/common.seccomp ) :

2
blacklist
[all]
kexec_load errno 1
open_by_handle_at errno 1
init_module errno 1
finit_module errno 1
delete_module errno 1

Preguntas

No 'carga de reglas de compcomp para el rendimiento de los contenedores LXC:

  1. significativo * ¿problemas de seguridad?
  2. ¿Algún otro problema técnico (aplicación o estabilidad)?

* Pregunta de bonificación: ¿Cuáles serían los riesgos al asumir que uno es el único que utiliza el sistema "madre" y sus contenedores LXC (por ejemplo, en un laboratorio de pruebas experimentales, donde puede ser menos evidente tener múltiples usuarios, pero en contenedores) ¿Todavía ofrece muchos beneficios, como la fácil creación de instantáneas / clonación de entornos experimentales)?

    
pregunta woosting 25.08.2016 - 11:08
fuente

1 respuesta

2

La seguridad no es una cosa absoluta como parece suponer: ninguna cosa es peligrosa por sí misma, las cosas solo son peligrosas cuando se considera una amenaza específica.

La seguridad solo se puede definir contra un conjunto de amenazas precisas y objetivas que pueden afectar el uso previsto de su plataforma.

Lo que dices en tu pregunta, según entiendo, es que no planeas usar LXC con fines de seguridad (es decir, no confías en LXC para aislar una aplicación comprometida, por ejemplo), en cambio confías en LXC únicamente para facilitar la clonación y la creación de instantáneas de entornos experimentales personales locales.

A partir de eso, lo único que importaría es que el uso de LXC disminuya la seguridad del sistema subyacente de alguna manera: la respuesta es no; en el peor de los casos, LXC no proporcionará beneficios de seguridad, pero no disminuirá la seguridad de el sistema subyacente (tendrá simplemente el mismo efecto que un chroot ). Ejecutar una aplicación en una máquina habilitada para LXC no será menos seguro que ejecutar la misma aplicación en el mismo sistema sin LXC.

No olvide que, si utiliza LXC para almacenar sistemas Linux completos (lo que creo que es el caso más común), las mismas reglas de seguridad de seguridad se aplican tanto al sistema host como al sistema huésped:

  • No utilice contraseñas débiles,
  • Aplicar actualizaciones de seguridad,
  • Etc.

Para una máquina de desarrollo, dependiendo de sus necesidades reales, la superficie de ataque puede reducirse en gran medida impidiendo que los servicios alojados en LXC sean accesibles a través de la red. Al mantener dicha aplicación para escuchar solo en las interfaces locales, puede desarrollar lo que desea y al mismo tiempo asegurarse de que un atacante remoto no pueda aprovechar algunos defectos en su trabajo o el invitado subyacente para acceder a su sistema.

Según los problemas de estabilidad / aplicación técnica, no tengo conocimiento de nada en particular. Si encuentra alguno de estos problemas, debe tratarlo individualmente en Unix.SE o en lista de correo LXC por ejemplo.

    
respondido por el WhiteWinterWolf 02.09.2016 - 11:48
fuente

Lea otras preguntas en las etiquetas