Appel d'un script à partir d'une racine setuid C - le script ne s'exécute pas en tant que root

Question

Je dois exécuter un script bash en tant que root (sudo sans mot de passe ou su pas viable) et comme vous ne pouvez pas définir un script sous Linux, j'ai pensé appeler il d'un exécutable et de faire il 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 
$ 

Cela fonctionne - comme dans fonctionne correctement le script - mais le script est exécuté en tant que l'utilisateur qui exécute « ./wrapper ».

Pourquoi? Et comment mettre en œuvre correctement cela?

Merci!

Answer 1

Depuis le bit suid sur executables ne modifie l'UID effectif (EUID) l'exécutable fonctionnera comme, et non l'UID réel (RUID) qui getuid() rendements, et en plus de la restriction suid scripts interprété (tout début exécutable avec "#!"), certains obus comme bash comme une mesure de sécurité supplémentaire va remettre l'EUID au RUID dans ce cas, vous devrez utiliser l'appel setuid(0) dans le code C avant d'exécuter le script.

Voir les man pages du setuid, seteuid, getuid et geteuid pour apprendre la sémantique exacte des UIDs réelles et efficaces.

(AVERTISSEMENT) Bien sûr, cela est un point approprié de mentionner que la restriction suid scripts dans de nombreux systèmes Unix, des coquillages et des interprètes, sont là pour une raison, qui est que si le script est pas très prudent À propos de la désinfection de son entrée et de l'état de l'environnement lors de son exécution, ils sont dangereux et peuvent être exploités pour une escalade de la sécurité. Soyez donc très prudent quand vous faites cela. Définissez l'accès à votre script et encapsuleur aussi strict que possible, n'autorisez que ce script très spécifique que vous avez l'intention d'exécuter et effacez l'environnement de votre programme C avant de démarrer le script, en définissant des variables d'environnement telles que PATH est nécessaire dans le bon ordre et pas de répertoires qui sont accessibles en écriture pour les autres.

Answer 2

Une autre chose à noter ici est que la limitation ici est de bash et non le système * nix lui-même. Bash fait des vérifications sur les scripts SUID pour les exécuter uniquement avec la racine EUID. Si vous prenez des coquilles plus vieilles, vous obtiendrez souvent ce que vous voulez hors de la boîte. Par exemple, sh ne fait pas ce genre de vérifications:

$ 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 

Avec 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 

encore, la réponse de Tom est généralement la voie à suivre pour faire un wrapper pour les programmes SUID root

Answer 3

Ajoutez le setuid (0) dans le script et conformez-le. Il devrait travailler après cela.

$ 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

Pourquoi sudo n'est-il pas viable?Il évite fait rage trous de sécurité tels que:

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$ 

En raison de l'environnement ne sont pas correctement filtrées, par exemple dans ce cas:

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

sudo assainit ce cas, et peut-être d'autres cas de pointe et gotchas que serait bien de ne pas écrire dans un wrapper suid personnalisé.

Answer 5

Les exemples sont horriblement peu sûrs et permettent à n'importe qui avec deux bits de connaissances d'exécuter n'importe quel programme en tant qu'utilisateur setuid.

Ne passez jamais par un shell à moins de désinfecter l'environnement en premier, la plupart des exemples montrés ici sont vulnérables à la mise en place d'IFS et PATH avant de l'exécuter.