C’est peut-être possible en donnant le bit suid root, en d’autres termes en donnant le script à root et disant que tout utilisateur qui lance le script le fait en tant que root. Tu t’en doutes, c’est dangereux. Tu peux limiter les dégâts en interdisant à tout le monde de le lancer, sauf aux membres d’un groupe que tu as créé pour l’occasion.

--
On ne prête qu’aux riches, et on a bien raison, parce que les autres remboursent difficilement.
-+- Tristan Bernard (1866-1947) -+-

Poste le Sunday 19 February 2006 12:35:05

heu... merci pour la réponse mais excuse moi, je debute, je n'ai rien compris a ta réponse.

Poste le Sunday 19 February 2006 12:38:05

Regarde la page de manuel de chmod, et lis une page sur les droits Unix des fichiers.

--
On ne prête qu’aux riches, et on a bien raison, parce que les autres remboursent difficilement.
-+- Tristan Bernard (1866-1947) -+-

Poste le Sunday 19 February 2006 13:30:09

je viens de lire la page de man de chmod mais ce que je ne sais pas faire c'est "donner le script a root" et ce n'est pas expliqué dans le manuel de chmod, en effet, quand je vais dans les propriétés du script, je vois qu'il est a 'nico' (utilisateur simple) mais je ne sais pas comment le donner a root.

Poste le Sunday 19 February 2006 14:08:50

Citation
windob
Bonjour,

J'ai ecrit un petit script qui utilise la commande iwconfig cette commande n'est accessible qu'en root et j'aimerais ne pas avoir besoins d'ouvrir le terminal et de me logguer en root pour
executer le script...
Merci

Je suggère de ne pas lancer ce script comme utilisateur, mais sous root. Une solution simple, mais qui constitue un trou de sécurité possible, et d'utiliser sudo (ou peut-être aussi super que je ne connais que de nom) qui permet, une fois convenablement configuré, d'executer une commande sous root.

Par exemple je peux taper

sudo ifdown eth0

(comme utilisateur basile) pour arrêter le réseau.

Il faut être conscient que pour ça, sudo doit être configuré (dans le fichier /etc/sudoers) et qu'il y a alors un trou de securité: toute personne (malveillante ou maladroite) qui accède à votre compte peut alors obtenir les permissions de root, et donc tout lire ou tout casser sur votre système.

Pratiquement, il faut faire attention à ce qu'on fait, et avoir un mot de passe long (au moins 11 caractères, avec chiffres et lettres....) donc difficile à craquer. C'est particulierement vrai si on autorise l'accàs à sa machine à distance par ssh ou autre.



----

Basile STARYNKEVITCH

Membre de l'APRIL « promouvoir et défendre le logiciel libre » - adhérez vous aussi à l'APRIL!

Projet logiciel libre: RefPerSys

Poste le Sunday 19 February 2006 14:50:32

Citation
Basile STARYNKEVITCH
Je suggère de ne pas lancer ce script comme
utilisateur, mais sous root. Une solution simple,
mais qui constitue un trou de sécurité possible,
et d'utiliser sudo (ou peut-être aussi super que
je ne connais que de nom) qui permet, une fois
convenablement configuré, d'executer une commande
sous root.

Par exemple je peux tapersudo ifdown eth0(comme
utilisateur basile) pour arrêter le réseau.

Il faut être conscient que pour ça, sudo doit être
configuré (dans le fichier /etc/sudoers) et qu'il
y a alors un trou de securité: toute personne
(malveillante ou maladroite) qui accède à votre
compte peut alors obtenir les permissions de root,
et donc tout lire ou tout casser sur votre
système.

Je voudrais préciser qu'au niveau de la sécurité, sudo, permet un réel gain par rapport à un suid bête et méchant ( qui ne s'utilise pas sur un script shell ) parcequ'il tout à fait possible de restreindre l'accès à une commande ou l'on peut meme préciser le ou les options autorisées.

Par contre en utilisant sudo avec un script shell, il faut effectivement etre très vigilant sur les droits du script car si l'écrire dans le fichier script est autorisé, il y a effectivement un gros probème de sécurité.

Il y a peut etre pour ce cas bien précis, un configuration de pam qui pourrais pallier à ce gros défaut mais c'est à vérifier



--
Brugmans Frédéric

[www.brugmans.net]
[triathlon.sport-challenge.be]

Poste le Sunday 19 February 2006 15:32:08

C’est chown pour donner le script à quelqu’un d’autre, attention, une fois ceci fait tu ne pourras plus le modifier autrement qu’en étant root.

--
On ne prête qu’aux riches, et on a bien raison, parce que les autres remboursent difficilement.
-+- Tristan Bernard (1866-1947) -+-

Poste le Sunday 19 February 2006 17:20:36

Il faut arréter avec sudo ! C'est vrai que c'est un trou de sécurité, mais bien configuré ça n'est quand même pas si dangereux, sur une machine pour usage personnel c'est tout à fait utilisable., à condition de bien mettre les chemins d'accès dans le sudoers (par exemple marquer /sbin/shutdown -h now et pas shutdown -h now ...) !
De toute façon le suid est aussi un trou de sécurité, alors ...

[catwell.info]

Poste le Sunday 19 February 2006 19:42:46

Je ne pense pas que ce soit un trou de sécurité ! Il faut rester prudent en l'utilisant.
Je pense sincèrement qu'autoriser telnet et nettement plus dangereux

--
Brugmans Frédéric

[www.brugmans.net]
[triathlon.sport-challenge.be]

Poste le Sunday 19 February 2006 19:53:46

je voulais dire que sudo est un potentiel trou de sécurité (pour ma part, je le configure en me permettant d'executer toute commande sous root sans taper de mot de passe) simplement parce qu'en réussissant à s'introduire sur mon compte on peut sans problème contrôler ma machine.

En pratique ça ne m'empêche pas de dormir, d'abord parce que je surveille mes fichiers de log, et ensuite parce que mon mot de passe est difficile à craquer, et que ma machine a très peu de services ouverts sur l'extérieur.

Dans la réalité, la seule faille serait mon imprudence; mais je crois connaître suffisamment Linux pour éviter les bourdes immédiates.

Souvenirs hors sujets

Ca fait 20 ans que j'utilise Unix (j'ai commençé avec SunOS3.2 sur une Sun3) - mes premières erreurs ont été

rm -rf /

et quand on passe plusieurs heures à réinstaller, à partir des cassettes, le système, le metier rentre vite.

Ma première bourde informatique -j'avais 14 ans, et j'ai eu la chance de programmer en PL/1 sur des cartes perforées en 1974 - c'était de poser mon paquet de cartes sur une imprimante (un gros bahut, plus gros que 2 ou 3 frigos actuels, qui s'ouvrait automatiquement quand il fallait changer le papier)... L'imprimante s'est ouverte, et mon paquet de cartes est tombé par terre....

Nostalgie, nostalgie....

retour sur sudo

En pratique, c'est très utile, mais il faut quand même éviter de trop taper de commandes sudo quand on est épuisé, fievreux, etc.... Il faut juste prendre la peine de reflechir une seconde avant de taper return.


----

Basile STARYNKEVITCH

Membre de l'APRIL « promouvoir et défendre le logiciel libre » - adhérez vous aussi à l'APRIL!

Projet logiciel libre: RefPerSys

Poste le Sunday 19 February 2006 20:29:20

Citation
nicola
C’est peut-être possible en donnant le bit suid
root, en d’autres termes en donnant le script à
root et disant que tout utilisateur qui lance le
script le fait en tant que root. Tu t’en doutes,
c’est dangereux. Tu peux limiter les dégâts en
interdisant à tout le monde de le lancer, sauf aux
membres d’un groupe que tu as créé pour
l’occasion.

--
La seule excuse de Dieu est qu’il n’existe pas.
Stendhal

Le suid ne fonctionne que pour un exécutable. Et un script shell n'est pas un exécutable, c'est un script interprété par l'exécutable "/bin/bash". A la limite on peut donner le suid au programme "/bin/bash" mais ça, c'est vraiment le truc à ne pas faire...

Citation
windob
heu... merci pour la réponse mais excuse moi, je
debute, je n'ai rien compris a ta réponse.

Hum... le suid (ou sgid) est un mécanisme un peu spécial.
Ce qu'il faut comprendre, c'est que quand un utilisateur (uid=X, gid=Y) lance un exécutable, il y a création d'un processus qui appartient à l'utilisateur (même si l'exécutable appartient à un autre utilisateur). Donc le processus possède alors un uid=X et gid=Y (identiques au uid/gid de celui qui lance l'exécutable). Et si le processus doit accéder à un fichier quelconque, le système regarde le uid/gid du processus pour vérifier les droits d'accès au fichier. Exemple: si tu lances le programme "vi" qui appartient à "root", ben le processus lancé aura tes droits et non ceux de root. Donc tu ne pourras ouvrir que les fichiers pour lesquels tu as une autorisation de lecture et les modifier que si tu as une autorisation d'écriture (bien que l'exécutable "/bin/vi" appartienne à root).

Bon, ça c'est la base des droits Unix. Cependant il y a parfois des cas particuliers où tu as besoin de droits qui ne sont pas les tiens (généralement des droits plus forts que les tiens mais pas forcément). Par exemple, quand tu modifies ton mot de passe, la commande "passwd" que tu lances va aller écrire dans le fichier "/etc/shadow" alors que tu n'as pas le droit d'y écrire. Ce mécanisme est donné par le "suid". Il suffit pour cela de positionner le suid sur un exécutable. Quand il est positionné, tout utilisateur qui lancera cet exécutable génèrera un processus qui aura un uid=X' (X' étant le propriétaire de l'exécutable). Et ce processus aura tous les droits de X' et non plus les tiens. Ainsi, tu peux aller lister les attributs de la commande "/bin/passwd" et tu y verras un petit "s" à la place du "x". Ce "s" en première position indique un "suid". Et comme la commande appartient à "root", tout utilisateur qui lance cette commande génère un processus qui a les droits de "root".
Il existe aussi le même système pour le gid et il se nomme "setgid". S'il est positionné, le processus généré par l'exécutable aura un gid identique au gid de l'exécutable.

Donc si tu positionnais le setuid sur le programme "/bin/vi", n'importe qui pourrait aller lire et modifier n'importe quel fichier puisque quiconque qui exécutera ce programme l'exécutera en ayant les droits de "root".



Pour les connaisseurs (et les amoureux des expèrieces bizarres), ceci me rappelle un jour une expérience que j'ai tenté avec le setuid/setgid qui n'a jamais fonctionné (un peu comme l'expèrience de Michelson qui tentait de prouver que la vitesse de la lumière dépend du référentiel d'observation et qui n'a jamais fonctionné parce que la vitesse de la lumière est invariante quel que soit le référentiel...).
Voici le résumé de l'expèrience
- J'ai créé un fichier quelconque donc j'en étais le propriétaire.
- J'ai positionné les droits de ce fichier à "---rwxrwx" donc n'importe qui pouvait le lire sauf moi.
- J'ai créé un programme en C qui ne faisait que lire ledit fichier. Evidement, n'importe qui pouvait utiliser ce programme sauf moi puisque je ne pouvais pas lire le fichier.
- J'ai donné le programme à quelqu'un d'autre ce qui ne changeait rien à la situation.
- Enfin j'ai placé un "setuid" sur le programme. Mon raisonnement était que puisque le programme que je lançais avait les droits de quelqu'un d'autre, cela me permettrait de lire le fichier (puisque n'importe qui d'autre que moi avait les droits de lecture et que le processus lancé n'était plus le mien). C'était un bel exemple de cas où le setuid serait utilisé non pas pour donner des droits mais pour en enlever. Ben ça n'a jamais fonctionné et je n'ai jamais pu lire ledit fichier. Si qqun a une explication...


L'homme qui murmurait à l'oreille des pingouins
[fr.lang.free.fr]

Poste le Sunday 19 February 2006 21:52:21

Bonsoir,

Citation
Sve@r
.....

Pour les connaisseurs (et les amoureux des expèrieces bizarres), ceci me rappelle un jour une
expérience que j'ai tenté avec le setuid/setgid qui n'a jamais fonctionné (un peu comme
l'expèrience de Michelson qui tentait de prouver que la vitesse de la lumière dépend du référentiel d'observation et qui n'a jamais fonctionné parce que la vitesse de la lumière est invariante quel que soit le référentiel...).
Voici le résumé de l'expèrience
- J'ai créé un fichier quelconque donc j'en étais le propriétaire.
- J'ai positionné les droits de ce fichier à "---rwxrwx" donc n'importe qui pouvait le lire
sauf moi.
- J'ai créé un programme en C qui ne faisait que lire ledit fichier. Evidement, n'importe qui
pouvait utiliser ce programme sauf moi puisque je ne pouvais pas lire le fichier.
- J'ai donné le programme à quelqu'un d'autre ce qui ne changeait rien à la situation.
- Enfin j'ai placé un "setuid" sur le programme.

Mon raisonnement était que puisque le programme que je lançais avait les droits de quelqu'un
d'autre, cela me permettrait de lire le fichier (puisque n'importe qui d'autre que moi avait les
droits de lecture et que le processus lancé n'était plus le mien). C'était un bel exemple de
cas où le setuid serait utilisé non pas pour donner des droits mais pour en enlever. Ben ça n'a
jamais fonctionné et je n'ai jamais pu lire ledit fichier. Si qqun a une explication...

L'homme qui murmurait à l'oreille des pingouins

Quel est le source de ce programme C? En particulier, est-ce qu'il contenait l'appel système setuid ou seteuid ou setreuid. Voir les pages de man de la section 2!

Si on oublie l'un de ces appels, ça ne peut pas marcher.

C'est bien expliqué dans le livre de feu R.Stevens, Advanced Unix programming (mais vu l'heure tardive, j'ai oublié les détails).

Cordialement

----

Basile STARYNKEVITCH

Membre de l'APRIL « promouvoir et défendre le logiciel libre » - adhérez vous aussi à l'APRIL!

Projet logiciel libre: RefPerSys

Poste le Sunday 19 February 2006 23:20:29

Citation
Basile STARYNKEVITCH
Quel est le source de ce programme C? En
particulier, est-ce qu'il contenait l'appel
système setuid ou seteuid ou setreuid. Voir les
pages de man de la section 2!

Absolument pas. Les primitives "setuid" servent juste si on veut changer pour un uid non connu à l'avance. Exemple : je veux devenir uid X (X passé en paramètre), alors
1) j'écris un programme qui fait un simpliste "setuid(atoi(argv[1]))"
2) pour que ce setuid fonctionne, il faut que le programme ait d'abord les droits de root donc je le donne à root et je lui mets un setuid avec un "chmod 4111".

En revanche, si je veux faire un programme qui aura toujours les droits de uid=567 (par exemple), alors je n'ai pas besoin de la primitive setuid. Il me suffit de le donner à l'user 567 et lui mettre un bit setuid avec le chmod. Cela suffit.

Exemple: copie le programme "/bin/sh" chez-toi, donne la copie à l'user "toto", mets-lui un bit suid et exécute la copie. Cela te génèrera un nouveau shell et si, dans ce nouveau shell tu tapes la commande "id", tu auras "toto"

Pour répondre à ta question de base, le programme faisait juste un fopen(), while (fgetc()) et fclose(). Vraiment rien de sorcier. De plus, si je donne ce programme à "toto" et que je lui demandes de lire un fichier qui n'est lisible que pour toto, cela fonctionne. A l'inverse, je lui demande de lire un fichier qui est lisible par n'importe qui d'autre que moi (donc toto est sensé pouvoir le lire), ben ça ne fonctionne pas. Le setuid permet de donner des droits mais pas d'en enlever. En fait, je dirais que quand le setuid est positionné, le système commence quand-même par prendre en compte les droits de celui qui exécute le programme avant de rajouter les droits donnés par le setuid...

L'homme qui murmurait à l'oreille des pingouins
[fr.lang.free.fr]

Poste le Monday 20 February 2006 14:24:14

Ok, j'ai mal compris.

Désolé de mon erreur.

----

Basile STARYNKEVITCH

Membre de l'APRIL « promouvoir et défendre le logiciel libre » - adhérez vous aussi à l'APRIL!

Projet logiciel libre: RefPerSys

Poste le Monday 20 February 2006 16:09:02

Bonjour,

Personnellement, j'emploie deux techniques pour passer des commandes en root dans un même flux en utilisant l'argument -c de su :

1- Directement :

su -c "commande \
commande \
commande \
commande"

2- Par un système que j'appelle de "cloison japonaise" (je préfère, car ça me paraît plus clair).

D'abord tu envoies ce que tu veux passer en dans un fichier via cat

cat > fichier_root << FICHIER_FIN

commande
commande
commande
commande

FICHIER_FIN

Puis tu réintègres le contenu du fichier dans le flux en root via source :

su -c "source fichier_root"

Poste le Monday 27 February 2006 13:48:43

Citation
Mushroom
cat > fichier_root << FICHIER_FIN
...
FICHIER_FIN

C'est marrant que la majorité des personnes utilisent le terme "FICHIER" pour la double redirection entrante. Et les token associés font toujours référence à un fichier. C'est pour ça qu'on voit quasiment toujours des syntaxes style "commande << EOF" (End Of File) ; et ici, c'est écrit "commande << FICHIER_FIN".

Or, et c'est utile de le préciser, la double redirection entrante ne prend pas ses infos dans un fichier mais dans le texte situé après. Donc celui qui veut montrer aux autres qu'il comprend réellement ce qu'il écrit utilisera un token référençant un texte pour indiquer la fin de la redirection
=> "commande << EOT" est donc plus indiqué.

Personnellement (mais ça n'engage que moi), j'utilise toujours le token "_EOT_" en référence au préprocesseur C qui utilise les token "__FILE__" et "__LINE__".

Maintenant rien n'empêche personne d'écrire ce qu'il veut style "commande <<zorglub". Tout le monde est libre...

L'homme qui murmurait à l'oreille des pingouins
[fr.lang.free.fr]

Poste le Monday 27 February 2006 16:17:23

Citation
Sve@r
Donc celui qui veut montrer aux autres qu'il comprend réellement ce qu'il écrit utilisera un token référençant un texte

Question de point de vue, àmha... si tu te places du point de vue du résultat, la première formulation est bonne : le fichier généré aura pour contenu de la première ligne après l'appel de cat jusqu'à FICHIER_FIN. C'est donc comme si dans ton script tu avais un fichier complet embarqué (ou un patron de fichier si son corps contient des variables).

Maintenant, j'ai mis FICHIER parce que c'est ce qui est généré ici et parce que je ne sais pas à quoi va correspondre ce code... avec la commande patch, par ex., je mets quelque chose du genre PATCH_FIN.

Poste le Monday 27 February 2006 18:43:54

Citation
Mushroom
Question de point de vue, àmha... si tu te places du point de vue du résultat, la première
formulation est bonne : le fichier généré aura
pour contenu de la première ligne après l'appel de
cat jusqu'à FICHIER_FIN.

Hum... la double redirection entrante sert à donner un texte entrant pour tout type de commande sans présumer du but de la commande...

Citation
Mushroom
Maintenant, j'ai mis FICHIER parce que c'est ce qui est généré ici et parce que je ne sais pas à
quoi va correspondre ce code... avec la commande
patch, par ex., je mets quelque chose du genre
PATCH_FIN.

cat >fichier_root << CAT_FIN )


L'homme qui murmurait à l'oreille des pingouins
[fr.lang.free.fr]

Poste le Monday 27 February 2006 21:45:41

Citation
Sve@r
Hum... la double redirection entrante sert à donner un texte entrant pour tout type de commande sans présumer du but de la commande...

Certes, mais ça éclaircit tout de même le code, surtout dans ce cas là ou ce qui est redirigé est du code... c'est un peu comme les variables, tu peux écrire INT_1, INT_2,... INT_n, STRING_1, STRING_2, ..., STRING_n pour ne pas préjuger du rôle et te concentrer sur la description de la valeur, mais bonjour pour la lisibilité finale (surtout s'il y a réaffectations).

Citation
Sve@r
cat >fichier_root << CAT_FIN )

#%b;-)

Poste le Tuesday 28 February 2006 12:42:51