Discussion :

[Catskan]

Bonjour à tous,

Je fais appel à vous car je bloque sur une étape de mon programme.
Je suis en train de faire une programme qui me permet d'éxécuter des commandes shell en cliquant sur des boutons.
Mais lorsque j'ai besoin d'éxécuter une commande en sudo, le programme plante.
J'ai essayé de faire un bouton avec la commande sudo et le mot de passe "en dur" mais impossible.
J'ai l'impression qu'il sort du shell ou qu'il ne m'écrit pas le mot de passe lorsqu'il le demande.

Savez-vous comment puis-je faire pour executer des commandes sudo ?

Merci d'avance pour votre aide.

[Obsidian]

Bonjour,

On suppose donc que tu travailles sous Unix ou sous Linux.

Ce n'est absolument à ton programme binaire d'appeler sudo lui-même. Ce serait une une grosse faille de sécurité. De plus, sudo, bien que très répandu, n'est pas une commande fondamentale mais un utilitaire, soumis à ses propres règles et ses fichiers de configuration.

Enfin, si tu cherches à appeler sudo, c'est que tu cherches à lancer un programme en tant que root et même là, cela doit se justifier. 90 % des débutants cherchent à faire cela pour contourner une limitation gênante plutôt que se demander pourquoi cette limitation est en vigueur.

Dis-nous ce que tu cherches à faire exactement au final.

[Catskan]

Par exemple, je dois executer la commande " sudo ifconfig en1 lladdr 00:00:00:00:00:00"
Mais pour cela il faut obligatoirement être authenfier en sudo pour l'exécuter ...
Il y a un autre moyen plus fiable ?

[Klaim]

Ce que tu cherches c'est les fonctions pour changer le niveau d'accès (demander a ce que ce soit un administrateur qui execute ton appli). Ce sont des fonctions dépendantes de l'OS, pas du language C++ ou C.

[Obsidian]

Par exemple, je dois executer la commande " sudo ifconfig en1 lladdr 00:00:00:00:00:00"
Mais pour cela il faut obligatoirement être authenfier en sudo pour l'exécuter ...
Il y a un autre moyen plus fiable ?

Ce que tu cherches c'est les fonctions pour changer le niveau d'accès (demander a ce que ce soit un administrateur qui execute ton appli). Ce sont des fonctions dépendantes de l'OS, pas du language C++ ou C.

Autrement dit : c'est à l'utilisateur d'appeler ton programme avec sudo, ou en tant que root. Ce n'est pas à ton logiciel d'aller acquérir ces privilèges seuls.

En principe, tu dois également te contenter de renvoyer le message d'erreur correspondant au code que tu reçois lorsqu'elle se produit. Tu peux à la limite préciser « need to be root » entre parenthèses, mais seulement si tu sais absolument ce que tu fais, car il est possible, notamment via les « capabilities », de conserver certains pouvoirs même en abandonnant l'identité root.

D'autre part, si tu codes en C ou en C++, c'est pour faire de la programmation système. Donc appeler une commande shell depuis un programme exécutable en langage machine, c'est passablement sale.

[Catskan]

Oui mais comment faire pour que l'utilisateur s'identifie ?
Il faut forcément entrer le mot de passe dans le programme non ? Ca je voudrai pas qu'il lance un Terminal pour que l'utilisateur entre son mot de passe.
Le programme ne servira qu'à moi de toute façon.
Ca fait 2h que j'éssaie de faire fonctionner cette commande qui a besoin d'être authentifié mais sans succès .

[Obsidian]

Oui mais comment faire pour que l'utilisateur s'identifie ?
Il faut forcément entrer le mot de passe dans le programme non ? Ca je voudrai pas qu'il lance un Terminal pour que l'utilisateur entre son mot de passe.

Ça dépend du système d'exploitation et de l'environnement choisi par l'utilisateur et c'est à lui de voir cela. Pas à toi. Au pire, si c'est toi qui te charges de faire le package pour ta distribution, il faudrait voir quels sont les sont les procédés mis en place par le bureau graphique pour faire cela. Sous Gnome 3, par exemple, il y a pkexec.

Il y a aussi les bits setuid et setgid qui sont la manière officielle, sous Unix, de lancer automatiquement un programme avec une identité donnée (généralement root mais pas forcément). Mais il faut absolument justifier leur utilisation.

Le programme ne servira qu'à moi de toute façon. Ca fait 2h que j'éssaie de faire fonctionner cette commande qui a besoin d'être authentifié mais sans succès .

C'est normal parce que ce n'est pas de cette manière qu'il faut procéder.
Encore une fois : que cherches-tu à faire au final ?

[Catskan]

Je suis sous OS X donc je pense que je dois bits setuid et setgid.
Au final, je veux qu'en cliquant sur des boutons il m'execute les commandes souhaitées.

Par exemple : Charger adresse mac : sudo ifconfig en1 lladdr 00:00:00:00:00:00
Purger mémoire : purge ...

Les commandes sans avoir besoin d'être administrateur fonctionnent parfaitement.
Pour le moment la seule commande que j'ai sous la main pour laquelle il faut être root est celle de l'adresse mac.

[Klaim]

Ce que tu n'as pas l'air de comprendre c'est que ici "sudo" est une application qui va, une fois qu'il aura vérifié que l'utilisateur est super-user, executer le reste de la ligne de commande en tant que root.

Donc en gros, l'application elle même ne fais pas la demande d emots de passet etc. Au mieu, comme dis au dessus, elle repère qu'elle n'a pas de droits d'accès pour faire son boulot et sois gère ce cas, soit juste affiche le probleme et quitte.

[Catskan]

Oui j'ai compris que sudo est un programme mais alors comment puis-je faire exactement pour executer cette commande qui le demande. C'est ça que je n'ai pas compris

[Klaim]

En gros ce que tu veux faire c'est lancer un autre processus, et tu le fais via une fonction et tu t'occupes pas de sudo.

Si ça rate parcequ'il fallait sudo, alors l'utilisateur de TON application devras lancer TON application avec sudo et ensuite ton application lancera l'autre application avec la fonction de lancement de processus.

Cette fonction est aussi dépendante de l'os, je ne me souviens plus de son noms sur les unix-like mais ça dois se trouver facilement je pense.

[Obsidian]

Oublie complètement sudo si tu n'as pas l'intention d'utiliser la console.

Ensuite, pour les applications purement Unix, ça vaut le coup de rester proche de l'authentique, mais quand on travaille sur un système à base d'Unix mais qui met en avant sa propre interface, spécialement si elle implique l'IHM, ce qui est le cas de Mac OS mais également de GNOME, alors c'est vers lui qu'il faut se pencher et se demander ce que cet environnement prévoit pour gagner des privilèges proprement.

Cette page devrait donc t'intéresser :
https://developer.apple.com/library/...roduction.html

[Emmanuel Deloget]

Oui mais comment faire pour que l'utilisateur s'identifie ?
Il faut forcément entrer le mot de passe dans le programme non ? Ca je voudrai pas qu'il lance un Terminal pour que l'utilisateur entre son mot de passe.
Le programme ne servira qu'à moi de toute façon.
Ca fait 2h que j'éssaie de faire fonctionner cette commande qui a besoin d'être authentifié mais sans succès .

Si le programme ne sert qu'à toi, pourquoi ne pas le lancer en tant que root ? Une autre solution serait de mettre l'owner/group à root:root et de rajouter le bit setuid sur le programme - de cette manière, il n'aura pas besoin de faire de sudo. Je ne vois pas réellement de problème ici : une fois en setuid root:root, ton programme pourra appeler ifconfig sans avoir besoin de faire un sudo (normallement).

[ternel]

D'une manière générale, la gestion des droits n'est pas l'affaire du programme, mais de l'admin qui l'a installé.

Ce n'est pas une bidouille quelconque dans le code qui sera valable, aussi "belle" soit-elle.

[Obsidian]

Une autre solution serait de mettre l'owner/group à root:root et de rajouter le bit setuid sur le programme - de cette manière, il n'aura pas besoin de faire de sudo.

C'est ce que l'on a dit plus haut, mais j'aimerais être sûr que c'est parfaitement justifié avant de lui faire prendre l'habitude d'y recourir (même si c'est toujours mieux qu'un « system("sudo"); »).

Si c'était un tout petit utilitaire console, à la limite, mais il parle d'une application graphique avec des boutons, etc. qui s'appuie probablement elle-même sur un framework particulier pour les générer facilement. Lancer tout cela sous root de manière systématique et transparente, ça me dérange un peu.

[Emmanuel Deloget]

D'une manière générale, la gestion des droits n'est pas l'affaire du programme, mais de l'admin qui l'a installé.

Ce n'est pas une bidouille quelconque dans le code qui sera valable, aussi "belle" soit-elle.

C'est à la fois vrai, à la fois faux. Si c'était complètement vrai alors le programme sudo n'aurait pas de fichier de configuration : c'est bien le programme qui, une fois sa configuration lue, décide quoi faire (même si le fichier en question est défini par l'administrateur, c'est le programme qui prends ses décisions). Mais en même temps, sudo (et les programmes/mécanismes similaires sur d'autres OS, telle l'impersonnation sur Windows) fait un peu figure d'exception.

C'est ce que l'on a dit plus haut, mais j'aimerais être sûr que c'est parfaitement justifié avant de lui faire prendre l'habitude d'y recourir (même si c'est toujours mieux qu'un « system("sudo"); »).

Si c'était un tout petit utilitaire console, à la limite, mais il parle d'une application graphique avec des boutons, etc. qui s'appuie probablement elle-même sur un framework particulier pour les générer facilement. Lancer tout cela sous root de manière systématique et transparente, ça me dérange un peu.

Au final, il faut savoir ce que tu veux

Si tu distribuait ton programme, ça serait un gros NON tout de suite. La plupart des framework graphiques sont trop important et cachent de nombreux problèmes de sécurité (buffer overflow exploitables, etc...). Mais si tu le garde pour toi uniquement, alors tu as cette possibilité - parce qu'utiliser un vecteur d'attaque ne peut se faire que si le vecteur d'attaque est connu, et en le gardant pour toi, tu n'a aucune chance qu'un attaquant puisse le découvrir.

Tu peut en outre conditionner l'exécution du programme, en testant l'uid et le gid de celui qui lance le programme (un process possède un uid, un gid, un euid (effective uid) et un egid (effective gid)).

Code getuid.c :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
#include <unistd.h>
#include <stdio.h>
#include <sys/types.h>
 
int main()
{
	uid_t uid, euid;
	gid_t gid, egid;
 
	uid = getuid();
	euid = geteuid();
 
	gid = getgid();
	egid = getegid();
 
	printf("uid = %d ; euid = %d\ngid = %d ; egid = %d\n", 
		uid, euid, gid, egid);
 
	return 0;
}

Code shell :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
$ gcc -o getuid getuid.c
$ ls -l
-rwxr-xr-x 1 edt  edt  7364 oct.   5 11:52 getuid*
-rw-r--r-- 1 edt  edt   286 oct.   5 11:52 getuid.c
$ ./getuid
uid = 2039 ; euid = 2039
gid = 2039 ; egid = 2039
$ sudo su
# chown root:root getuid
# chmod +s getgid
# exit
$ ls -l
-rwsr-sr-x 1 root root 7364 oct.   5 11:52 getuid*
-rw-r--r-- 1 edt  edt   286 oct.   5 11:52 getuid.c
$ ./getuid
uid = 2039 ; euid = 0
gid = 2039 ; egid = 0

Bref, en testant l'uid et le gid du lanceur du programme, tu peux très simplement restreindre l'utilisation de ton programme, dès les premières lignes de main(), et donc priver un pirate de la possibilité d'exécuter ton programme (sauf s'il parvient à le lancer depuis ton compte, auquel cas, il peut l'exécuter comme s'il était toi).

[Obsidian]

Si tu distribuait ton programme, ça serait un gros NON tout de suite. La plupart des framework graphiques sont trop important et cachent de nombreux problèmes de sécurité (buffer overflow exploitables, etc...).

Je crois qu'on voit les choses de la même façon.

Mais si tu le garde pour toi uniquement, alors tu as cette possibilité - parce qu'utiliser un vecteur d'attaque ne peut se faire que si le vecteur d'attaque est connu, et en le gardant pour toi, tu n'a aucune chance qu'un attaquant puisse le découvrir.

Mouais, je ne tablerais pas trop là-dessus. Si j'ai envie d'écrire un rootkit, il me suffit de lancer un « find » à la racine « / » cherchant les fichiers ordinaires disposant à la fois du bit w pour l'utilisateur en cours et du bit s. Ça se fait en une ligne que je tairai volontairement. Si j'en trouve un, il suffit d'écrire dedans pour gagner l'identité de la victime. Et comme ces bits sont généralement utilisés justement pour passer root, un chmod mal écrit suffit à introduire une faille.

Cela dit, ça reste quand même la manière la plus propre de le faire.

Bref, en testant l'uid et le gid du lanceur du programme, tu peux très simplement restreindre l'utilisation de ton programme, dès les premières lignes de main(), et donc priver un pirate de la possibilité d'exécuter ton programme (sauf s'il parvient à le lancer depuis ton compte, auquel cas, il peut l'exécuter comme s'il était toi).

Moi, sous Linux, j'utilise plutôt les capabilities, qui me permettent ensuite de redescendre de root à l'utilisateur normal tout en conservant des pouvoirs sur certains domaines prédéfinis, comme CAP_NET_BIND_SERVICE qui permet de continuer à utiliser les ports réseau inférieurs à 1024 même en tant qu'utilisateur ordinaire. Pour configurer les interfaces, il suffit d'obtenir CAP_NET_ADMIN. Mais on est sous Mac OS X.

Ce que je veux dire ici, c'est qu'un tel système, même s'il est basé sur Unix pour l'exécution des softs, s'appuie massivement sur son interface graphique et sur le framework des couches supérieures et qu'en principe, on demande à l'utilisateur si on doit vraiment faire telle ou telle action. Par exemple : « accéder aux données de géolocalisation ». Et si l'on veut faire un programme qui sera installé durablement, même si ce n'est que pour soi, autant se renseigner sur les méthodes en usage sur le système cible.

GNOME, qui prend Mac OS comme modèle, propose déjà « pkexec » qui est un sudo graphique. Mais il y a aussi des modes spéciaux avec des curseurs à glissières permettant de « déverrouiller » certaines parties des applications, etc.

Pour Mac OS, je pense qu'il doit y avoir derrière le lien que je lui ai donné la manière « officielle » de demander des droits au système qui, lui même, va poser à la question à l'utilisateur et lui proposer de « toujours l'autoriser », etc. L'avantage est que le système peut ensuite facilement révoquer ces permissions, soit sur demande explicite, soit automatiquement au vu d'informations nouvelles, comme la publication d'une liste de failles, etc.

[Catskan]

Bonjour à tous,

Tout d'abord, veuillez m'excuser pour ce message si tardif mais j'ai eu pas mal de boulot pour mes études alors difficile d'avoir du temps pour moi .
Ayant lu vos réponses, pour lesquelles je vous remercie grandement, je pense abandonné cette idée de programme. Bien trop compliqué pour le moment de gérer toutes les permissions et tout ça (Je suis encore assez débutant dans la programmation et j'ai un peu de mal).
Je garde ce topic précieusement qui m'être utile dans un futur programme .

Je vous en remercie encore d'avance .