Llamar a un script desde un programa setuid root C - script no se ejecuta como root

Question

Necesito ejecutar un script bash como root (sudo o su no viable sin contraseña) y como no puede establecer un script en Linux, pensé en llamar desde un ejecutable y hacer que setuid:

$ cat wrapper.c 
int main(void) 
{ 
     system("/bin/bash ./should_run_as_root.sh"); 
} 
$ gcc -o wrapper wrapper.c 
$ sudo chown root wrapper 
$ sudo chmod ug+s wrapper 
$ ll wrapper 
-rwsr-sr-x 1 root users 6667 2009-02-17 11:11 wrapper 
$ 

Esto funciona - al igual que en la secuencia de comandos se ejecuta correctamente - pero el script se ejecuta como el usuario que ejecuta "./wrapper".

¿Por qué? ¿Y cómo implementar esto correctamente?

Gracias!

Answer 1

Desde el bit suid en ejecutables sólo cambia el UID efectivo (EUID) el ejecutable se ejecutará como, y no el verdadero UID (RUID) que getuid() devoluciones, y además de la restricción de suid guiones interpretarse (cualquier principio ejecutable con "#!"), algunos shells como bash como una medida de seguridad adicional volverán a configurar el EUID en el RUID. En este caso, deberá usar la llamada setuid(0) en el código C antes de ejecutar el script.

Ver las páginas del mansetuid, seteuid, getuid, y geteuid para aprender la semántica exacta de los UID real y efectivo.

(ADVERTENCIA) Por supuesto, esto es un punto apropiado mencionar que la restricción de suid scripts en muchos sistemas UNIX, conchas e intérpretes, están ahí por una razón, y es que si el guión no es muy cuidadoso sobre la desinfección de su entrada y el estado del entorno cuando se ejecuta, son peligrosos y pueden ser explotados para la escalada de seguridad. Así que ten mucho cuidado al hacer esto. Establezca el acceso a su secuencia de comandos y envoltorio tan estrictamente como sea posible, solo permita este script muy específico que desea ejecutar, y borre el entorno dentro de su programa C antes de iniciar el script, estableciendo variables de entorno como PATH para contener exactamente lo que es necesario en el orden correcto y no hay directorios que puedan escribirse a otros.

Answer 2

Otra cosa a tener en cuenta aquí es que la limitación aquí es de bash y no del propio sistema * nix. Bash realmente realiza verificaciones en los scripts SUID para ejecutarlos solo con la raíz EUID. Si toma conchas más viejas, a menudo obtendrá lo que quería de la caja. Por ejemplo, sh no hace que este tipo de verificaciones:

$ cat wrapper.c 
int main(void) 
{ 
      system("/bin/sh -c whoami"); 
} 

$ ls -l wrapper 
-rwsr-sr-x 1 root users 8887 Feb 17 14:15 wrapper 
$ ./wrapper 
root 

Con bash:

$ cat wrapper.c 
int main(void) 
{ 
      system("/bin/bash -c whoami"); 
} 

$ ls -l wrapper 
-rwsr-sr-x 1 root users 8887 Feb 17 14:18 wrapper 
$ ./wrapper 
skinp 

Sin embargo, la respuesta de Tom es generalmente el camino a seguir para la fabricación de un contenedor para los programas de root

Answer 3

Agregue el setuid (0) en el script y complételo. Debería funcionar después de esto.

$ cat wrapper.c 
int main(void) 
{ 
     setuid(0); 
     system("/bin/bash ./should_run_as_root.sh"); 
} 
$ gcc -o wrapper wrapper.c 
$ sudo chown root wrapper 
$ sudo chmod ug+s wrapper 
$ ll wrapper 
-rwsr-sr-x 1 root users 6667 2009-02-17 11:11 wrapper 
$ 

Answer 4

¿Por qué sudo no es viable?Evita que rabia agujeros de seguridad, tales como:

bash-3.2$ cat test 
#!/bin/bash 
echo ima shell script durp durp 
bash-3.2$ chmod +x test 
bash-3.2$ ./test 
heh heh 
bash-3.2$ 

Debido al ambiente no ser desinfectados adecuadamente, por ejemplo, en este caso:

export echo='() { builtin echo heh heh; }' 

sudo desinfecta este caso, y tal vez otros casos extremos y trampas que sería bueno no escribir en un envoltorio suid personalizado.

Answer 5

Los ejemplos son terriblemente inseguros y permiten a cualquier persona con dos bits de conocimiento ejecutar cualquier programa que desee como usuario de setuid.

Nunca pase por un intérprete de comandos a menos que primero desinfecte el entorno, la mayoría de los ejemplos que se muestran aquí son vulnerables a tener IFS y PATH configurados antes de ejecutarlo.