Appeler un script à partir d'un programme racine C setuid - script ne fonctionne pas en tant que root

Question

Je dois exécuter un script bash en tant que root (passwordless sudo ou su non viable) et puisque vous ne pouvez pas setuid un script sous Linux, je pensais à l'appeler 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 le script fonctionne correctement -. Mais le script est exécuté en tant que l'utilisateur qui exécute « ./wrapper »

Pourquoi? Et comment implémenter 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 sur les scripts interprété suid (tout début exécutable avec « #! »), des coquilles comme bash comme une mesure de sécurité supplémentaire donnera le EUID retour au RUID dans ce cas, vous devrez utiliser le setuid(0) d'appel dans le code C avant d'exécuter le script.

Voir les man du setuid, seteuid, getuid et geteuid d'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 sur les scripts de suid 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 attention à désinfectante son entrée et l'état de l'environnement lorsqu'il est exécuté, ils sont dangereux et peuvent être exploités pour l'escalade de la sécurité. Soyez donc très prudent lorsque vous faites cela. Définir l'accès à votre script et emballage aussi strictes que vous pouvez, autoriser que ce script très spécifique que vous avez l'intention d'exécuter et effacer l'environnement dans votre programme C avant de commencer le script, la définition des variables d'environnement telles que PATH contenir exactement ce que est nécessaire dans l'ordre et pas des répertoires qui sont inscriptibles à d'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 faire des vérifications sur les scripts suid ne les exécuter avec la racine de EUID. Si vous prenez des coquilles plus âgés, vous obtiendrez souvent ce que tu voulais sortir 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

Pourtant, 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 le compiler. Il devrait fonctionner 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

Les exemples sont horriblement peu sûr et permet à toute personne deux bits de connaissances pour exécuter un programme qu'ils veulent que l'utilisateur setuid.

Ne jamais passer par un obus à moins que vous désinfectez l'environnement d'abord, la plupart des exemples présentés ici sont vulnérables à avoir mis en avant IFS et PATH exécuter.

Answer 5

Pourquoi pas viable sudo? Il évite fait rage failles de sécurité telles 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; }'

aseptise ce cas sudo, et peut-être d'autres cas de pointe et gotchas qui seraient bien ne pas écrire dans une enveloppe personnalisée suid.