¿Es seguro permitir que los estudiantes accedan a Terminal.app en un entorno compartido?

Antecedentes: Tenemos un laboratorio de computadoras Macintosh, todas ejecutando 10.10.3 actualmente, que son para la instrucción en el salón de clases. Los estudiantes generalmente usan su propio inicio de sesión/contraseña a través de Active Directory para iniciar sesión en estas máquinas; sin embargo, también está disponible el acceso de invitado (anónimo). Tradicionalmente, nunca habíamos permitido que los estudiantes abrieran/usaran Terminal.app ya que la sala se usaba principalmente para el arte, pero recientemente las máquinas se están usando para la ciencia y los instructores solicitaron acceso a la CLI. Los estudiantes no son administradores y no podrían usar sudo.

¿Es seguro eliminar la restricción que impide que los estudiantes abran Terminal.app y permitirles acceso completo al shell bash? ¿Estamos siendo demasiado cautelosos? De no ser así, ¿a qué tipos de riesgos estaríamos expuestos o tendríamos que abordar antes de permitir dicho acceso?

Espero que 'Preguntar diferente' sea un lugar apropiado para esta pregunta, también consideré colocarlo en 'Superusuario' o 'Seguridad de la información'.
Si sus profesores de ciencias pueden decirle exactamente qué es lo que harán sus estudiantes que requiere el uso de Terminal y siempre que ese requisito de uso pueda cumplirse sin darles a los estudiantes acceso a sudo, entonces es posible que tenga suficiente información para tomar una decisión informada de una forma u otra. el otro.
Como se indicó, los estudiantes no tendrán la capacidad o la necesidad de usar sudo. A algunos de mis colegas les preocupa que permitir el uso de Terminal sea un agujero de seguridad, pero han proporcionado, en mi opinión, poca evidencia. Espero que alguien pueda proporcionar un argumento sólido a favor o en contra.

Respuestas (1)

Es importante darse cuenta de que los estudiantes ya tienen otras vías de acceso a los shells bash (y otros). Los estudiantes pueden descargar programas de terminal alternativos, como iTerm , a sus directorios de inicio para obtener acceso a shell/CLI. Además, los scripts de shell se pueden ejecutar a través de Automator.app .

Por lo tanto, especialmente para los estudiantes emprendedores, bloquear la aplicación Terminal.app predeterminada no les ha proporcionado mucho desde el punto de vista de la seguridad.

Realmente, si el acceso CLI es apropiado se reduce a los permisos intactos en todo el sistema de archivos combinados con la configuración adecuada de la cuenta de usuario. Si los estudiantes se ejecutan como cuentas estándar o administradas (no administrativas) y los permisos del sistema de archivos están intactos, eso es lo que limita el acceso de los estudiantes. Las cuentas que no son de administrador no deberían poder ejecutar herramientas de nivel raíz ni modificar archivos de configuración de nivel raíz.

Es bueno saberlo, gracias. Obviamente, no incluí toda la configuración de nuestra política en mi información de antecedentes, actualmente no permitimos que los archivos ejecutables se ejecuten fuera de /Aplicaciones, y solo los administradores pueden escribir en /Aplicaciones.
Claro, es difícil enumerar una política de seguridad completa en una breve publicación. No sabía que había una manera de no permitir el lanzamiento de aplicaciones en el propio directorio de inicio. Está fuera de tema, pero sería interesante saber cómo lo haces. Aun así, Automator.app está en /Aplicaciones y se puede usar para hacer cosas similares a una concha.