Ejecución de un programa posiblemente dañino en Linux

Estoy escribiendo un programa que evaluará programas escritos por estudiantes. Me temo que no puedo confiar en ellos y necesito asegurarme de que no terminará mal para la computadora que lo ejecuta.

Estaba pensando en hacer un usuario de prueba de choque con acceso limitado a los recursos del sistema y ejecutar programas como ese usuario, pero por lo que he encontrado en la red hasta ahora, hacer un sistema virtual sería la opción más segura ...

¿Alguien puede ayudarme a elegir el enfoque correcto? La seguridad es una gran preocupación para mí. Por otro lado, no quiero una solución que sea exagerada y pierda mucho tiempo tratando de aprender algo que realmente no necesito.

• La máquina virtual puede brindarle la mayor seguridad sin reiniciar, pero el rendimiento más bajo.

• Otra opción, para una seguridad aún mayor que una máquina virtual: inicie un CD / DVD / pendrive "en vivo" sin acceso al disco duro (deshabilite temporalmente el HDD en el BIOS; si no puede, al menos no monte la unidad / desmontarlo, si se monta automáticamente, pero esto es mucho menos seguro)

• Un contenedor docker es una alternativa un poco menos segura que una máquina virtual completa. Probablemente la diferencia crucial (en términos de seguridad) entre estos dos es que los sistemas que se ejecutan en Docker realmente usan el núcleo de su sistema host.

• Existen programas como el aislamiento que crearán un entorno especial y seguro, que generalmente se denomina sandbox , que generalmente están basados ​​en chroot, con supervisión adicional, encuentre uno que se adapte a usted.

• Un chroot simple será menos seguro (especialmente en lo que respecta a la ejecución de programas), aunque tal vez un poco más rápido, pero ... Necesitarás construir / copiar un árbol raíz completamente separado y usar montajes de enlace para /devetc. (ver Nota 1 abajo!). Por lo tanto, en general, este enfoque no se puede recomendar, especialmente si puede usar un sandboxentorno más seguro y, a menudo, más fácil de configurar .

Nota 0: en el aspecto de un "usuario especial", como lanobodycuenta: esto apenas proporcionaseguridad, mucho menos que un simplechroot. Unnobodyusuario aún puede acceder a archivos y programas que tienenpermisos de lectura y ejecución establecidos para otros . Puedes probarlo consu -s /bin/sh -c 'some command' nobody. Y si tiene algún archivo de configuración / historial / caché accesible para cualquiera (por error o un pequeño agujero de seguridad), un programa que se ejecuta connobodylos permisos puede acceder a él, grep para datos confidenciales (como "pass =" etc.) y en muchas formas lo envían por la red o lo que sea.

Nota 1: Como Gilles señaló en un comentario a continuación , un entorno chroot simple proporcionará muy poca seguridad contra exploits que apuntan a la escalada de privilegios. Un único chroot tiene sentido desde el punto de vista de la seguridad, solo si el entorno es mínimo, que consiste solo en programas confirmados por seguridad(pero aún existe el riesgo de explotar vulnerabilidades potenciales a nivel del kernel), y todos los programas no confiables que se ejecutan en el chroot se están ejecutando como un usuario que no ejecuta ningún proceso fuera del chroot. Lo que previene chroot (con las restricciones mencionadas aquí) es la penetración directa del sistema sin escalada de privilegios. Sin embargo, como Gilles señaló en otro comentario, incluso ese nivel de seguridad puede eludirse, permitiendo que un programa salga del chroot.

Utiliza una máquina virtual. Cualquier cosa menos no proporciona mucha seguridad.

Hace unos años, podría haber sugerido un usuario dedicado chrooteado o algo así. Pero el hardware se ha vuelto más poderoso, y el software de máquina virtual se ha vuelto más fácil de usar. Además, los ataques comerciales se han vuelto más sofisticados. Ya no hay ninguna razón para no ir hasta aquí.

Yo recomendaría ejecutar VirtualBox. Puede configurar la máquina virtual en un par de minutos, luego instalar una distribución de Linux dentro de ella. La única configuración no predeterminada que recomiendo es la configuración de red: cree una interfaz "NAT" (para comunicarse con el mundo) y una interfaz "solo host" (para que pueda copiar fácilmente archivos desde y hacia el host, y ssh en la VM). Deshabilite la interfaz NAT mientras ejecuta los programas de sus alumnos¹; habilítelo solo cuando esté instalando o actualizando paquetes de software.

Dentro de la máquina virtual, cree un usuario por alumno.

¹ _{Puede restringir la interfaz NAT a una lista blanca de usuarios, pero eso es más avanzado de lo que necesita en una configuración simple y precisa.}

Aquí hay una explicación muy completa de por qué usar Chroot sigue siendo una opción muy viable, y por qué el sistema operativo completo o la virtualización de hardware completa es especialmente exagerada en escenarios específicos.

No es más que un mito que Chroot no es una característica de seguridad. existen herramientas que construirán el sistema de archivos chroot automáticamente para usted, y Chroot está integrado en muchas aplicaciones convencionales como una característica de seguridad útil.

Contrariamente a la creencia popular, no todas las situaciones requieren una virtualización completa del sistema operativo o una simulación completa del hardware. Esto puede significar tener más superficie de ataque para tratar de cubrir. a su vez, lo que significa un sistema menos seguro . (supuestamente para administradores de sistemas menos informados)

las reglas son bastante simples: no coloque nada dentro del chroot que no sea necesario. No ejecutes un demonio como root. no ejecute un demonio ya que cualquier usuario ejecuta un demonio fuera del chroot.

elimine cualquier aplicación insegura, binarios setuid, enlaces simbólicos / enlaces duros sin propietario. vuelva a montar carpetas innecesarias utilizando nosuid, noexec y nodev. construya la última versión estable del demonio en ejecución desde la fuente. y, sobre todo, ¡ asegure el sistema base!

Voy a agregar esto, mucho después de que la pregunta sea respondida oficialmente: MAGIA: Envejecimiento malicioso en circuitos / núcleos , que desafortunadamente está encerrado detrás del muro de pago de ACM. El resultado final del papel es que las trazas de ancho muy pequeño en los circuitos en uso hoy en día envejecen durante el uso y eventualmente se rompen. Al encontrar la (s) instrucción (es) correcta (s) y repetirla una y otra vez, un atacante puede envejecer rápidamente los circuitos integrados.

Ninguno de VM o sandbox o contenedor o chroot jail evitaría este tipo de destrucción maliciosa de hardware. Los autores del artículo encontraron tales secuencias de instrucciones, y el hardware experimentalmente envejecido hasta el fallo, pero no dieron las instrucciones, por lo que puede no ser una amenaza real por un tiempo.

En los Unix derivados de BSD (incluido Mac OS X) hay una instalación llamada sandbox. La página del manual dice

DESCRIPCIÓN
La instalación de sandbox permite que las aplicaciones restrinjan voluntariamente su acceso a los recursos del sistema operativo. Este mecanismo de seguridad está destinado a limitar el daño potencial en caso de que se explote una vulnerabilidad. No es un reemplazo para otros controles de acceso al sistema operativo.

Esto es independiente de la chrootinstalación que también está disponible.