Servidor para las tareas de codificación de la escuela

Lo que necesita es relativamente simple: debe asegurarse de que las cuentas no privilegiadas de sus estudiantes estén bien confinadas. Si no tiene un entorno gráfico involucrado, su situación es relativamente simple. Debe comenzar implementando las siguientes acciones:

• asegúrese de que los usuarios se creen sin privilegios administrativos (no sudo , no admin o wheel group)
• asegúrate de que los usuarios no puedan emular una pantalla de inicio de sesión para falsificar tu pantalla de inicio de sesión (un clásico para la universidad, algo que he visto)
• asegure una política polkitd adecuada que evite que los usuarios suspendan / apaguen el host
• asegúrese de que no ejecuta los servicios vulnerables / obsoletos suid / sgid en el host ( vea cómo listarlos )
• asegúrese de que ningún usuario individual pueda agotar los recursos del sistema (configurando Systemd.cgroup para imponer límites de uso de recursos en la sesión completa de cada usuario)
• refuerce su control de acceso obligatorio instalando y configurando adecuadamente SELinux (para limitar a los estudiantes a un rol de estudiante donde solo pueden escribir en su casa y en / tmp)
• caduque las cuentas cuando sea necesario para evitar cuentas persistentes con contraseñas comprometidas ( vea esta pregunta en el sitio de Unix )
• incluso puede ejecutar las sesiones de los estudiantes en contenedores separados utilizando Systemd.nspawn que está diseñado para ejecutarse sistemas que funcionan completamente de forma independiente, utilizando espacios de nombres de Linux . Esta es la forma correcta de encarcelar una sesión, no chroot

Es posible que luego note que los estudiantes usan las máquinas para fines distintos a los permitidos. Puede limitar el acceso a las máquinas a horarios específicos utilizando pam_time aunque eso podría impiden que los estudiantes realicen su trabajo y deben equilibrarse con los beneficios que proporciona. Además, asegúrese de que los administradores de su red sepan qué tráfico esperar en este host para que puedan detectar el tráfico no deseado.

Dicho todo esto, no veo el punto en los binarios específicos de la lista blanca (inútil ya que los estudiantes pueden compilar y ejecutar su propio código), ya que puede impedir que los estudiantes utilicen herramientas de desarrollo legítimas, por ejemplo. compiladores alternativos, cadenas de herramientas de construcción, herramientas de análisis de código, herramientas de control de versiones de código, etc.

Mientras los usuarios solo puedan hacerse daño a ellos mismos y tengan garantías sólidas de eso, el trabajo está hecho. De todos modos, este no es exactamente un sistema de producción a largo plazo, los estudiantes solo lo utilizan para jugar con el código educativo.

Está lejos de estar completo, pero un grupo de compañeros de mi universidad está desarrollando Mumuki . La versión en inglés parece estar dañada no tiene contenido en inglés en este momento, pero puedes leer su intención allí. También puede unirse al proyecto y hacer que ejecute C ++ (tengo comience con C ).

La idea de la plataforma es crear ejercicios con pruebas unitarias que los revisen.

Hemos empezado a pensar en cómo ejecutar el código de manera aislada, pero hasta ahora no hay nada implementado.

Sí hay. Para empezar, no es una mala idea usar SSH, pero para mejorar la seguridad puede hacer lo siguiente:

• Use chroot jails para bloquear a todos los usuarios "estudiantes" que inician sesión a través de SSH en un entorno limitado.
• No les dé acceso a sudo, en lugar de eso, use scripts / comandos específicos en la lista de sudoers para permitir un subconjunto limitado de los comandos de administración.
• Hacer que el servidor no sea de acceso público en ningún puerto > 1024. (ejecute ssh en un número de puerto alto para evitar el acceso de script para niños).
• Mientras esté en ello, anímelos a que usen ssh-keys para iniciar sesión. Estos son desde un punto de vista de seguridad muy superior al nombre de usuario / contraseña (siempre que estén encriptados con una contraseña).
• Como alternativa, puedes usar git y la integración continua para esto. (El combo de Gitlab y Jenkins, por ejemplo) tiene la ventaja adicional de que solo puede darles acceso a través de un entorno web seguro (cuando usa una configuración TLS, por lo tanto, 'https', use un certificado adecuado!) Y todo el acceso es auditable.

Sí, hay enfoques alternativos. Sin embargo, creo que su pregunta se basa en suposiciones erróneas. Mientras que permitir inicios de sesión de shell a más personas obviamente tendrá impactos de seguridad, no significa necesariamente que la seguridad del sistema resultante no se pueda administrar de manera efectiva. Estos sistemas están diseñados para ser sistemas multiusuario y tienen la facilidad de administrar este acceso de manera que no comprometa la seguridad (o al menos, administre el nivel de riesgo hasta un punto aceptable). El verdadero desafío en estos entornos es que normalmente no tiene los recursos para hacerlo. Por ejemplo, es poco probable que un solo perfil de estudiante sea adecuado: necesitaría perfiles para reflejar las diferentes necesidades. Un curso de programación de introducción probablemente no necesite el mismo acceso que un curso de programación de red o de programación de sistemas. El problema se convierte entonces en tener tiempo suficiente para administrar todos estos perfiles diferentes y garantizar que sean apropiados.

Habiendo dicho todo eso, creo que hoy en día, hay enfoques alternativos que probablemente sean más manejables y apropiados. Por ejemplo, usar máquinas virtuales puede ser muy productivo. Estos pueden configurarse para que cada estudiante esté aislado unos de otros y se pueda hacer para que puedan "actualizar" su entorno virtual a un "buen estado" conocido. Luego hay soluciones basadas en cosas como Docker o Vagrant, que se pueden usar para permitir a los estudiantes crear un entorno estándar y consistente en sus propias máquinas. En lugar de que su servidor sea una plataforma en la que los alumnos inician sesión para realizar su trabajo, su servidor se convierte en un mecanismo de distribución que les permite descargar un entorno de trabajo que pueden ejecutar ellos mismos. Esto también permite la posibilidad de crear entornos personalizados que se han modificado para satisfacer los requisitos específicos del curso.