¿Qué hace que systemd-nspawn siga siendo "inadecuado para configuraciones de contenedor seguras"?

Esto se indica en la página del manual para systemd-nspawn

Tenga en cuenta que, aunque se tomen estas precauciones de seguridad, systemd-nspawn no es adecuado para configuraciones de contenedores seguros. Muchas de las características de seguridad pueden eludirse y, por lo tanto, son principalmente útiles para evitar cambios accidentales en el sistema host desde el contenedor. El uso previsto de este programa es la depuración y prueba, así como la creación de paquetes, distribuciones y software relacionados con el arranque y la gestión de sistemas.

Esta misma pregunta se hizo posteriormente en la lista de correo en 2011 , pero la respuesta parece estar desactualizada.

systemd-nspawn contiene código para ejecutar CLONE_NEWNETusando la --private-networkopción ahora. Esto parece cubrir el AF_UNIXproblema del espacio de nombres privado , y supongo que los problemas CAP_NET_RAWy CAP_NET_BINDmencionados.

¿Qué problemas persisten en este momento y qué hace, por ejemplo, LXC además de lo que systemd-nspawnpuede hacer actualmente?

security systemd lxc

— user239558
fuente

AF_UNIX se aísla a medias con CLONE_NEWNET: sockets abstractos - separados, basados en sistemas de archivos - unidos (a menos que no haya sistemas de archivos compartidos entre el host y el contenedor). Esto hace que sea conveniente iniciar aplicaciones X que restringen la red para una aplicación en particular (ya que Xorg abre tanto el zócalo UNIX abstracto como el sistema de archivos).

— Vi.

LXC es un poco mejor porque puede ejecutar contenedores como usuarios sin privilegios . Esto es posible con systemd-nspawn, pero solo para escenarios en los que solo necesita un usuario (en lugar de múltiples), lo que puede ser difícil o menos seguro para procesos múltiples en escenarios de contenedor. Si desea saber por qué docker, lxc y systemd-nspawn no son un mecanismo de seguridad sólido, lea esto: https://opensource.com/business/14/7/docker-security-selinux . Básicamente, los contenedores aún tienen acceso al kernel y cualquier explotación del kernel obtiene el control de toda la máquina. En un núcleo monolítico como Linux, las vulnerabilidades del núcleo no son infrecuentes.

— CameronNemo
fuente

Esta respuesta es incorrecta. systemd-nspawn admite la eliminación de privilegios a un usuario diferente: freedesktop.org/software/systemd/man/systemd-nspawn.html

— David Timothy Strauss

Estoy bastante seguro de que todo lo que hace es ejecutar la consola / shell como un usuario sin privilegios, pero ejecuta todo lo demás como root. ¿Puedes mirar eso?

— CameronNemo

Ok, retomo mi última declaración. Sin embargo, no tiene un manejo subuid / subgid adecuado, solo un usuario sin privilegios por contenedor.

— CameronNemo

Solo poder pasar a un usuario no privilegiado por contenedor en lugar de admitir el manejo completo de subuid / subgid no es un problema de seguridad. Es una limitación de características.

— David Timothy Strauss

Si lo se. Solo estaba señalando la diferencia.

— CameronNemo