¿Cómo se puede saber si un binario es seguro para otorgar permisos de sudo a un usuario que no es de confianza?

En general, es imposible saberlo con certeza, incluso un programa aparentemente perfectamente seguro podría tener vulnerabilidades que significan que puede usarse para acciones arbitrarias, pero aquí hay algunas cosas que debe verificar:

¿El programa hace algo de lo siguiente?

• Revele el contenido de archivos o dispositivos arbitrarios.
• Copie, mueva, escriba o elimine archivos arbitrarios.
• Establecer/modificar variables de entorno arbitrarias (que serán recogidas por otros procesos privilegiados) o realizar cambios arbitrarios en variables específicas.
• Invocar IOCTL o interactuar con dispositivos arbitrarios.
• Cambiar la propiedad o los permisos en archivos arbitrarios.
• Monte sistemas de archivos arbitrarios o cambie las opciones de montaje en los existentes.
• Permitir el acceso directo a la memoria del sistema o de un proceso arbitrario (como un depurador).
• Permitir iniciar programas arbitrarios.

Cualquier programa que haga algo de eso no seguro otorgar a un usuario con pocos privilegios sudo el acceso a los. Esto descarta, por ejemplo, cualquier programa con la capacidad de especificar un archivo de salida (generalmente a través de un -o o -f parámetro), procesar un archivo de entrada de cualquier manera que revele su contenido (incluso a través de un mensaje de error suficientemente informativo sobre el formato de entrada incorrecto) y la gran mayoría de los tiempos de ejecución de secuencias de comandos (incluidos los shells).

Si reemplaza arbitrario en esos cheques con limitado o específico , entonces ha reducido el problema un paso (o varios):haga cualquiera de las cosas que el programa puede hacer llevar a sucesos tan arbitrarios, posiblemente a través de múltiples niveles de indirección? Por ejemplo, si su programa le permite al usuario configurar una variable de entorno única, eso hará que un programa privilegiado lea un archivo diferente al esperado, y ese archivo diferente hará que el sistema permita a los usuarios montar un archivo de imagen de su elección como un sistema de archivos con el setuid poco respetado, entonces no debe permitir que usuarios no confiables ejecuten ese programa.

Sin embargo, el hecho de que un programa pase todas estas comprobaciones no significa que sea realmente seguro. Por ejemplo, si realiza determinadas acciones en la red (como escuchar en puertos restringidos o enviar paquetes sin formato), puede que no sea seguro porque puede haber otro programa en la red (o en la misma máquina), suponiendo que todos los procesos capaces de realizar tales acciones. things es propiedad de un usuario de confianza; después de todo, esas acciones requieren root, y ha roto esa suposición. Además, la lista de viñetas de arriba es solo algo en lo que pensé en unos minutos; es casi seguro que hay algunas vías para la escalada de privilegios que no incluí.

Finalmente, como con todas las cuestiones de seguridad, depende de su modelo de amenaza.

• ¿El atacante (usuario que no es de confianza) es local en la máquina con acceso físico o es remoto? Es extremadamente difícil evitar que un atacante determinado con acceso físico se haga root, especialmente si necesita poder (re)iniciar la máquina sin ayuda, así que considere qué riesgos está dispuesto a aceptar.
• ¿Se comparte la máquina entre los usuarios? Luego, debe considerar ataques adicionales entre usuarios, como la denegación de servicio (al consumir recursos excesivos o dejar la máquina inutilizable).
• ¿Requiere no repudio (la capacidad de probar quién hizo algo)? Luego, debe asegurarse de que puede vincular cualquier acción realizada a través de sudo al usuario que los hizo.
• ¿Necesita evitar que el usuario haga algunas cosas que incluso un usuario que no sea root puede hacer (como ejecutar programas arbitrarios en su propio contexto de usuario, incluso si esos programas son juegos o criptomineros, o abrir un cliente TCP conexiones a hosts y puertos arbitrarios)? Luego, debe considerar adicionalmente los medios por los cuales está aplicando esta restricción y evitar ejecutar como sudo cualquier programa que pueda conducir al usuario a eludir la restricción.

Etc. Aquí no será posible una respuesta verdaderamente completa; depende de demasiadas cosas. Sin embargo, diré esto:es muy difícil para garantizar que un usuario no confiable, dada la capacidad de ejecutar como raíz cualquier programa no trivial (que no fue diseñado explícitamente para ejecutarse de manera segura de esa manera), no pueda hacer algo inesperado. Incluso si uno de esos programas no permite nada que considere importante prevenir, podría ser posible encadenar varios programas de este tipo para lograr el objetivo del atacante.

Esencialmente se reduce al problema de la detención, puede auditar el código o aplicar ingeniería inversa al binario, sin embargo, incluso si no hay "características" que le permitan ejecutar comandos arbitrarios, aún podría haber vulnerabilidades en el binario o sudo que podría conducir a ejecución de comandos arbitrarios como root para los usuarios habilitados.