Executer sudo dans un programme c++

Version imprimable

  • 04/10/2012, 14h27
    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.
  • 04/10/2012, 14h29
    Obsidian
    Citation:
    Envoy� par Emmanuel Deloget Voir le message
    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.
  • 05/10/2012, 12h01
    Emmanuel Deloget
    Citation:
    Envoy� par leternel Voir le message
    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.

    Citation:
    Envoy� par Obsidian Voir le message
    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:
    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:
    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).
  • 05/10/2012, 13h19
    Obsidian
    Citation:
    Envoy� par Emmanuel Deloget Voir le message
    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.

    Citation:
    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.

    Citation:
    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.
  • 14/10/2012, 15h00
    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 :).