Et si tu mets (ou un gentil malware qui a les mêmes droits que toi) dans le fichier synaptic.desktop: $ cat ~/.local/share/applications/synaptic.desktop [Desktop Entry] Name=Synaptic Package Manager Name[fr]=Gestionnaire de paquets Synaptic GenericName=Package Manager Comment=Install, remove and upgrade software packages Comment[fr]=Installer, désinstaller et mettre à jour les paquets de logiciels Exec=gksudo xeyes Icon=synaptic Terminalúlse Type=Application Categories=PackageManager;GTK;System;Settings; NotShowIn=KDE; X-Ubuntu-Gettext-Domain=synaptic
Alors, lorsque tu vas sélectionner Synaptic dans le menu XFCE, tu vas lancer xeyes avec des droits root. Et paf l'élévation de privilèges. Je te laisse imaginer ce que tu peux faire une fois que tu as les droits root. Par exemple, lancer synaptic afin que l'utilisateur pense avoir réellement démarré synaptic.
-> Tout s'est fait en simple user -> L'utilisateur lambda n'a rien vu passer -> le malware est root
C'est pourquoi ton affirmation m'a rendu très curieux et si tu pouvais donner un ou deux exemples ce serait très intéressant!
Linux est une passoire comme les autres.
Oui, enfin pour ton exemple, encore faut-il que sudo ait été installé... Michel
Le 23/12/2014 13:21, Kevin Denis a écrit :
Et si tu mets (ou un gentil malware qui a les mêmes droits que toi) dans
le fichier synaptic.desktop:
$ cat ~/.local/share/applications/synaptic.desktop
[Desktop Entry]
Name=Synaptic Package Manager
Name[fr]=Gestionnaire de paquets Synaptic
GenericName=Package Manager
Comment=Install, remove and upgrade software packages
Comment[fr]=Installer, désinstaller et mettre à jour les paquets de logiciels
Exec=gksudo xeyes
Icon=synaptic
Terminalúlse
Type=Application
Categories=PackageManager;GTK;System;Settings;
NotShowIn=KDE;
X-Ubuntu-Gettext-Domain=synaptic
Alors, lorsque tu vas sélectionner Synaptic dans le menu XFCE, tu vas
lancer xeyes avec des droits root.
Et paf l'élévation de privilèges. Je te laisse imaginer ce que tu
peux faire une fois que tu as les droits root. Par exemple, lancer synaptic
afin que l'utilisateur pense avoir réellement démarré synaptic.
-> Tout s'est fait en simple user
-> L'utilisateur lambda n'a rien vu passer
-> le malware est root
C'est pourquoi ton affirmation m'a rendu très curieux et si tu pouvais
donner un ou deux exemples ce serait très intéressant!
Linux est une passoire comme les autres.
Oui, enfin pour ton exemple, encore faut-il que sudo ait été installé...
Michel
Et si tu mets (ou un gentil malware qui a les mêmes droits que toi) dans le fichier synaptic.desktop: $ cat ~/.local/share/applications/synaptic.desktop [Desktop Entry] Name=Synaptic Package Manager Name[fr]=Gestionnaire de paquets Synaptic GenericName=Package Manager Comment=Install, remove and upgrade software packages Comment[fr]=Installer, désinstaller et mettre à jour les paquets de logiciels Exec=gksudo xeyes Icon=synaptic Terminalúlse Type=Application Categories=PackageManager;GTK;System;Settings; NotShowIn=KDE; X-Ubuntu-Gettext-Domain=synaptic
Alors, lorsque tu vas sélectionner Synaptic dans le menu XFCE, tu vas lancer xeyes avec des droits root. Et paf l'élévation de privilèges. Je te laisse imaginer ce que tu peux faire une fois que tu as les droits root. Par exemple, lancer synaptic afin que l'utilisateur pense avoir réellement démarré synaptic.
-> Tout s'est fait en simple user -> L'utilisateur lambda n'a rien vu passer -> le malware est root
C'est pourquoi ton affirmation m'a rendu très curieux et si tu pouvais donner un ou deux exemples ce serait très intéressant!
Linux est une passoire comme les autres.
Oui, enfin pour ton exemple, encore faut-il que sudo ait été installé... Michel
Sergio
Le 23/12/2014 13:36, Michel a écrit :
Alors, lorsque tu vas sélectionner Synaptic dans le menu XFCE, tu vas lancer xeyes avec des droits root. Et paf l'élévation de privilèges. Je te laisse imaginer ce que tu peux faire une fois que tu as les droits root. Par exemple, lancer synaptic afin que l'utilisateur pense avoir réellement démarré synaptic.
-> Tout s'est fait en simple user -> L'utilisateur lambda n'a rien vu passer -> le malware est root
C'est pourquoi ton affirmation m'a rendu très curieux et si tu pouvais donner un ou deux exemples ce serait très intéressant!
Linux est une passoire comme les autres.
Oui, enfin pour ton exemple, encore faut-il que sudo ait été installé... Michel
On peut fort bien remplacer gksudo par gksu et rouler jeunesse...
-- Serge http://leserged.online.fr/ Mon blog: http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
Le 23/12/2014 13:36, Michel a écrit :
Alors, lorsque tu vas sélectionner Synaptic dans le menu XFCE, tu vas
lancer xeyes avec des droits root.
Et paf l'élévation de privilèges. Je te laisse imaginer ce que tu
peux faire une fois que tu as les droits root. Par exemple, lancer synaptic
afin que l'utilisateur pense avoir réellement démarré synaptic.
-> Tout s'est fait en simple user
-> L'utilisateur lambda n'a rien vu passer
-> le malware est root
C'est pourquoi ton affirmation m'a rendu très curieux et si tu pouvais
donner un ou deux exemples ce serait très intéressant!
Linux est une passoire comme les autres.
Oui, enfin pour ton exemple, encore faut-il que sudo ait été installé...
Michel
On peut fort bien remplacer gksudo par gksu et rouler jeunesse...
--
Serge http://leserged.online.fr/
Mon blog: http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org
Alors, lorsque tu vas sélectionner Synaptic dans le menu XFCE, tu vas lancer xeyes avec des droits root. Et paf l'élévation de privilèges. Je te laisse imaginer ce que tu peux faire une fois que tu as les droits root. Par exemple, lancer synaptic afin que l'utilisateur pense avoir réellement démarré synaptic.
-> Tout s'est fait en simple user -> L'utilisateur lambda n'a rien vu passer -> le malware est root
C'est pourquoi ton affirmation m'a rendu très curieux et si tu pouvais donner un ou deux exemples ce serait très intéressant!
Linux est une passoire comme les autres.
Oui, enfin pour ton exemple, encore faut-il que sudo ait été installé... Michel
On peut fort bien remplacer gksudo par gksu et rouler jeunesse...
-- Serge http://leserged.online.fr/ Mon blog: http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
Doug713705
Le 23-12-2014, Sergio nous expliquait dans fr.comp.os.linux.configuration (<54996683$0$2044$) :
Oui, enfin pour ton exemple, encore faut-il que sudo ait été installé...
+1
On peut fort bien remplacer gksudo par gksu et rouler jeunesse...
Sauf que pour su (j'imagine que c'est pareil avec gksu), c'est le mot de passe root qu'il faut donner.
Ceci dit, si l'utilisateur est seul à utiliser la machine et qu'il connait également le mot de passe root (cas typique d'un ordinateur personnel), le problème restera le même.
Moralité, ne pas utiliser de menus qui utilisent les *.desktop reste plus sûr.
-- Mais le passé n'a pas d'amis Quand il vient lécher les statues. -- H.F. Thiéfaine, La môme kaléïdoscope
Le 23-12-2014, Sergio nous expliquait dans
fr.comp.os.linux.configuration
(<54996683$0$2044$426a74cc@news.free.fr>) :
Oui, enfin pour ton exemple, encore faut-il que sudo ait été installé...
+1
On peut fort bien remplacer gksudo par gksu et rouler jeunesse...
Sauf que pour su (j'imagine que c'est pareil avec gksu), c'est le mot de
passe root qu'il faut donner.
Ceci dit, si l'utilisateur est seul à utiliser la machine et qu'il
connait également le mot de passe root (cas typique d'un ordinateur
personnel), le problème restera le même.
Moralité, ne pas utiliser de menus qui utilisent les *.desktop reste
plus sûr.
--
Mais le passé n'a pas d'amis
Quand il vient lécher les statues.
-- H.F. Thiéfaine, La môme kaléïdoscope
Le 23-12-2014, Sergio nous expliquait dans fr.comp.os.linux.configuration (<54996683$0$2044$) :
Oui, enfin pour ton exemple, encore faut-il que sudo ait été installé...
+1
On peut fort bien remplacer gksudo par gksu et rouler jeunesse...
Sauf que pour su (j'imagine que c'est pareil avec gksu), c'est le mot de passe root qu'il faut donner.
Ceci dit, si l'utilisateur est seul à utiliser la machine et qu'il connait également le mot de passe root (cas typique d'un ordinateur personnel), le problème restera le même.
Moralité, ne pas utiliser de menus qui utilisent les *.desktop reste plus sûr.
-- Mais le passé n'a pas d'amis Quand il vient lécher les statues. -- H.F. Thiéfaine, La môme kaléïdoscope
Nicolas George
Doug713705 , dans le message , a écrit :
+1
Coucou le moyen-âge, ici le XXIe siècle.
Moralité, ne pas utiliser de menus qui utilisent les *.desktop reste plus sûr.
Complètement faux. Si ton utilisateur est compromis, utiliser des commandes n'y fera rien. Il est compromis, point.
Doug713705 , dans le message <96bombxl8q.ln2@actarus.redatomik.org>, a
écrit :
+1
Coucou le moyen-âge, ici le XXIe siècle.
Moralité, ne pas utiliser de menus qui utilisent les *.desktop reste
plus sûr.
Complètement faux. Si ton utilisateur est compromis, utiliser des commandes
n'y fera rien. Il est compromis, point.
Moralité, ne pas utiliser de menus qui utilisent les *.desktop reste plus sûr.
Complètement faux. Si ton utilisateur est compromis, utiliser des commandes n'y fera rien. Il est compromis, point.
Kevin Denis
Le 23-12-2014, Doug713705 a écrit :
On peut fort bien remplacer gksudo par gksu et rouler jeunesse...
Sauf que pour su (j'imagine que c'est pareil avec gksu), c'est le mot de passe root qu'il faut donner.
Ceci dit, si l'utilisateur est seul à utiliser la machine et qu'il connait également le mot de passe root (cas typique d'un ordinateur personnel), le problème restera le même.
Moralité, ne pas utiliser de menus qui utilisent les *.desktop reste plus sûr.
Les alias sont lus avant les commandes dans le PATH. Donc en tant qu'user tu peux faire un: $ echo alias su='echo donne moi ton pass root, aie confiance' >> ~/.bashrc $ Et la prochaine fois que tu ouvres un shell ou un terminal, la commande su ne sera plus celle que tu crois :) -- Kevin
Le 23-12-2014, Doug713705 <doug.letough@free.fr> a écrit :
On peut fort bien remplacer gksudo par gksu et rouler jeunesse...
Sauf que pour su (j'imagine que c'est pareil avec gksu), c'est le mot de
passe root qu'il faut donner.
Ceci dit, si l'utilisateur est seul à utiliser la machine et qu'il
connait également le mot de passe root (cas typique d'un ordinateur
personnel), le problème restera le même.
Moralité, ne pas utiliser de menus qui utilisent les *.desktop reste
plus sûr.
Les alias sont lus avant les commandes dans le PATH. Donc en tant qu'user
tu peux faire un:
$ echo alias su='echo donne moi ton pass root, aie confiance' >> ~/.bashrc
$
Et la prochaine fois que tu ouvres un shell ou un terminal, la commande
su ne sera plus celle que tu crois :)
--
Kevin
On peut fort bien remplacer gksudo par gksu et rouler jeunesse...
Sauf que pour su (j'imagine que c'est pareil avec gksu), c'est le mot de passe root qu'il faut donner.
Ceci dit, si l'utilisateur est seul à utiliser la machine et qu'il connait également le mot de passe root (cas typique d'un ordinateur personnel), le problème restera le même.
Moralité, ne pas utiliser de menus qui utilisent les *.desktop reste plus sûr.
Les alias sont lus avant les commandes dans le PATH. Donc en tant qu'user tu peux faire un: $ echo alias su='echo donne moi ton pass root, aie confiance' >> ~/.bashrc $ Et la prochaine fois que tu ouvres un shell ou un terminal, la commande su ne sera plus celle que tu crois :) -- Kevin
mrr
Les alias sont lus avant les commandes dans le PATH. Donc en tant qu'user tu peux faire un: $ echo alias su='echo donne moi ton pass root, aie confiance' >> ~/.bashrc $ Et la prochaine fois que tu ouvres un shell ou un terminal, la commande su ne sera plus celle que tu crois :)
Pas mal,pas mal! Bon, moralité: ne pas se faire hacker son compte utilisateur! (On peut aussi faire un "ifdown eth0" ou couper le cable ethernet, sauter en l'air en soufflant partout pour perturber tout signal wifi etc.).
Je persiste à croire qu'un système Linux correctement configuré reste très difficile à hacker, mais cela n'engage que moi.
Aussi ne se servir qu'avec parcimonie de monsieur "root" et pour les paranos "double checker" la commande que l'on lance.
Et sinon, ne pas oublier de n'avoir rien à cacher ou si c'est malheureusement le cas de cacher cela sur une clef usb cryptée.
Ne pas oublier qu'un bon netfilter (iptables) bien configuré ça aide.
Etc etc.
-- mrr
Les alias sont lus avant les commandes dans le PATH. Donc en tant qu'user
tu peux faire un:
$ echo alias su='echo donne moi ton pass root, aie confiance' >> ~/.bashrc
$
Et la prochaine fois que tu ouvres un shell ou un terminal, la commande
su ne sera plus celle que tu crois :)
Pas mal,pas mal!
Bon, moralité: ne pas se faire hacker son compte utilisateur! (On peut
aussi faire un "ifdown eth0" ou couper le cable ethernet, sauter en
l'air en soufflant partout pour perturber tout signal wifi etc.).
Je persiste à croire qu'un système Linux correctement configuré reste
très difficile à hacker, mais cela n'engage que moi.
Aussi ne se servir qu'avec parcimonie de monsieur "root" et pour les
paranos "double checker" la commande que l'on lance.
Et sinon, ne pas oublier de n'avoir rien à cacher ou si c'est
malheureusement le cas de cacher cela sur une clef usb cryptée.
Ne pas oublier qu'un bon netfilter (iptables) bien configuré ça aide.
Les alias sont lus avant les commandes dans le PATH. Donc en tant qu'user tu peux faire un: $ echo alias su='echo donne moi ton pass root, aie confiance' >> ~/.bashrc $ Et la prochaine fois que tu ouvres un shell ou un terminal, la commande su ne sera plus celle que tu crois :)
Pas mal,pas mal! Bon, moralité: ne pas se faire hacker son compte utilisateur! (On peut aussi faire un "ifdown eth0" ou couper le cable ethernet, sauter en l'air en soufflant partout pour perturber tout signal wifi etc.).
Je persiste à croire qu'un système Linux correctement configuré reste très difficile à hacker, mais cela n'engage que moi.
Aussi ne se servir qu'avec parcimonie de monsieur "root" et pour les paranos "double checker" la commande que l'on lance.
Et sinon, ne pas oublier de n'avoir rien à cacher ou si c'est malheureusement le cas de cacher cela sur une clef usb cryptée.
Ne pas oublier qu'un bon netfilter (iptables) bien configuré ça aide.
Etc etc.
-- mrr
Kevin Denis
Le 23-12-2014, mrr a écrit :
Bon, moralité: ne pas se faire hacker son compte utilisateur!
Oui. Surtout qu'aujourd'hui les données les plus importantes sont celles de ton compte utilisateur. Et qu'un pirate n'a pas forcément besoin d'un accès root pour employer ta machine à des fins malicieuses (envoi de SPAM, minage de bitcoin, rebond pour pirater d'autres sites, etc..)
(On peut aussi faire un "ifdown eth0" ou couper le cable ethernet, sauter en l'air en soufflant partout pour perturber tout signal wifi etc.).
Et tu oublies qu'un malware communiquait par la carte son en utilisant des ultrasons :)
Je persiste à croire qu'un système Linux correctement configuré reste très difficile à hacker, mais cela n'engage que moi.
Tout système correctement configuré est difficile à hacker. (Ou pas).
Aussi ne se servir qu'avec parcimonie de monsieur "root" et pour les paranos "double checker" la commande que l'on lance.
Et sinon, ne pas oublier de n'avoir rien à cacher ou si c'est malheureusement le cas de cacher cela sur une clef usb cryptée.
Oh? Et d'après toi, n'y aurait il pas moyen de modifier le programme qui demande le mot de passe de ta clé chiffrée? -- Kevin
Le 23-12-2014, mrr <mireero@free.fr> a écrit :
Bon, moralité: ne pas se faire hacker son compte utilisateur!
Oui. Surtout qu'aujourd'hui les données les plus importantes sont celles de
ton compte utilisateur. Et qu'un pirate n'a pas forcément besoin d'un accès
root pour employer ta machine à des fins malicieuses (envoi de SPAM, minage
de bitcoin, rebond pour pirater d'autres sites, etc..)
(On peut
aussi faire un "ifdown eth0" ou couper le cable ethernet, sauter en
l'air en soufflant partout pour perturber tout signal wifi etc.).
Et tu oublies qu'un malware communiquait par la carte son en utilisant
des ultrasons :)
Je persiste à croire qu'un système Linux correctement configuré reste
très difficile à hacker, mais cela n'engage que moi.
Tout système correctement configuré est difficile à hacker. (Ou pas).
Aussi ne se servir qu'avec parcimonie de monsieur "root" et pour les
paranos "double checker" la commande que l'on lance.
Et sinon, ne pas oublier de n'avoir rien à cacher ou si c'est
malheureusement le cas de cacher cela sur une clef usb cryptée.
Oh? Et d'après toi, n'y aurait il pas moyen de modifier le programme
qui demande le mot de passe de ta clé chiffrée?
--
Kevin
Bon, moralité: ne pas se faire hacker son compte utilisateur!
Oui. Surtout qu'aujourd'hui les données les plus importantes sont celles de ton compte utilisateur. Et qu'un pirate n'a pas forcément besoin d'un accès root pour employer ta machine à des fins malicieuses (envoi de SPAM, minage de bitcoin, rebond pour pirater d'autres sites, etc..)
(On peut aussi faire un "ifdown eth0" ou couper le cable ethernet, sauter en l'air en soufflant partout pour perturber tout signal wifi etc.).
Et tu oublies qu'un malware communiquait par la carte son en utilisant des ultrasons :)
Je persiste à croire qu'un système Linux correctement configuré reste très difficile à hacker, mais cela n'engage que moi.
Tout système correctement configuré est difficile à hacker. (Ou pas).
Aussi ne se servir qu'avec parcimonie de monsieur "root" et pour les paranos "double checker" la commande que l'on lance.
Et sinon, ne pas oublier de n'avoir rien à cacher ou si c'est malheureusement le cas de cacher cela sur une clef usb cryptée.
Oh? Et d'après toi, n'y aurait il pas moyen de modifier le programme qui demande le mot de passe de ta clé chiffrée? -- Kevin
Doug713705
Le 23-12-2014, Nicolas George nous expliquait dans fr.comp.os.linux.configuration (<549986aa$0$2490$) :
Doug713705 , dans le message , a écrit :
+1
Coucou le moyen-âge, ici le XXIe siècle.
Coucou les systèmes vérolés, ici les systèmes sains :)
Moralité, ne pas utiliser de menus qui utilisent les *.desktop reste plus sûr.
Complètement faux. Si ton utilisateur est compromis, utiliser des commandes n'y fera rien. Il est compromis, point.
Compromis ou pas mon utilisateur n'a pas d'accès en écriture sur /usr tant qu'il ne connait pas le mot de passe _root_, ne peut pas non plus executer une commande critique sans ce même mot de passe.
Lui fournir des mécanismes lui permettant d'outrepasser des commandes (sudo + ~./local/*.desktop) qui ne s'y situent pas par hasard dans /usr/bin, /bin ou /sbin, sous prétexte de XXIème siècle c'est confondre progrès et nouveauté, vitesse et précipitation, utilité et facilité.
Le problème de Linux n'est pas tant sa popularisation supposée lui apporter son lot d'attaques supplémentaires mais bel et bien ce besoin qu'ont certains de remise en cause des principes de base. Tout ça ruine tous les efforts antérieurs.
On n'est pas obligé de s'inventer des problèmes pour être heureux ou "modernes".
XP+FU2 vers la trollosphère.
-- Alors je rêve d'être un fusil, Un bazooka, un bombardier Ou bien encore un champ de mines Où tu viendrais te faire sauter -- H.F. Thiéfaine, La queue
Le 23-12-2014, Nicolas George nous expliquait dans
fr.comp.os.linux.configuration
(<549986aa$0$2490$426a74cc@news.free.fr>) :
Doug713705 , dans le message <96bombxl8q.ln2@actarus.redatomik.org>, a
écrit :
+1
Coucou le moyen-âge, ici le XXIe siècle.
Coucou les systèmes vérolés, ici les systèmes sains :)
Moralité, ne pas utiliser de menus qui utilisent les *.desktop reste
plus sûr.
Complètement faux. Si ton utilisateur est compromis, utiliser des commandes
n'y fera rien. Il est compromis, point.
Compromis ou pas mon utilisateur n'a pas d'accès en écriture sur /usr
tant qu'il ne connait pas le mot de passe _root_, ne peut pas non plus
executer une commande critique sans ce même mot de passe.
Lui fournir des mécanismes lui permettant d'outrepasser des commandes
(sudo + ~./local/*.desktop) qui ne s'y situent pas par hasard dans
/usr/bin, /bin ou /sbin, sous prétexte de XXIème siècle c'est confondre
progrès et nouveauté, vitesse et précipitation, utilité et facilité.
Le problème de Linux n'est pas tant sa popularisation supposée lui
apporter son lot d'attaques supplémentaires mais bel et bien ce besoin
qu'ont certains de remise en cause des principes de base. Tout ça ruine
tous les efforts antérieurs.
On n'est pas obligé de s'inventer des problèmes pour être heureux ou
"modernes".
XP+FU2 vers la trollosphère.
--
Alors je rêve d'être un fusil, Un bazooka, un bombardier
Ou bien encore un champ de mines
Où tu viendrais te faire sauter
-- H.F. Thiéfaine, La queue
Le 23-12-2014, Nicolas George nous expliquait dans fr.comp.os.linux.configuration (<549986aa$0$2490$) :
Doug713705 , dans le message , a écrit :
+1
Coucou le moyen-âge, ici le XXIe siècle.
Coucou les systèmes vérolés, ici les systèmes sains :)
Moralité, ne pas utiliser de menus qui utilisent les *.desktop reste plus sûr.
Complètement faux. Si ton utilisateur est compromis, utiliser des commandes n'y fera rien. Il est compromis, point.
Compromis ou pas mon utilisateur n'a pas d'accès en écriture sur /usr tant qu'il ne connait pas le mot de passe _root_, ne peut pas non plus executer une commande critique sans ce même mot de passe.
Lui fournir des mécanismes lui permettant d'outrepasser des commandes (sudo + ~./local/*.desktop) qui ne s'y situent pas par hasard dans /usr/bin, /bin ou /sbin, sous prétexte de XXIème siècle c'est confondre progrès et nouveauté, vitesse et précipitation, utilité et facilité.
Le problème de Linux n'est pas tant sa popularisation supposée lui apporter son lot d'attaques supplémentaires mais bel et bien ce besoin qu'ont certains de remise en cause des principes de base. Tout ça ruine tous les efforts antérieurs.
On n'est pas obligé de s'inventer des problèmes pour être heureux ou "modernes".
XP+FU2 vers la trollosphère.
-- Alors je rêve d'être un fusil, Un bazooka, un bombardier Ou bien encore un champ de mines Où tu viendrais te faire sauter -- H.F. Thiéfaine, La queue
Doug713705
Le 23-12-2014, Kevin Denis nous expliquait dans fr.comp.os.linux.configuration () :
On peut fort bien remplacer gksudo par gksu et rouler jeunesse...
Sauf que pour su (j'imagine que c'est pareil avec gksu), c'est le mot de passe root qu'il faut donner.
Ceci dit, si l'utilisateur est seul à utiliser la machine et qu'il connait également le mot de passe root (cas typique d'un ordinateur personnel), le problème restera le même.
Moralité, ne pas utiliser de menus qui utilisent les *.desktop reste plus sûr.
Les alias sont lus avant les commandes dans le PATH. Donc en tant qu'user tu peux faire un: $ echo alias su='echo donne moi ton pass root, aie confiance' >> ~/.bashrc $ Et la prochaine fois que tu ouvres un shell ou un terminal, la commande su ne sera plus celle que tu crois :)
'Marche pas chez moi, je suis obligé de sourcer manuellement .bashrc pour que ça fonctionne.
Mais comme je ne suis pas tout à fait de mauvaise foi je vais avouer que ça fonctionne si on place l'alias dans ~/.bash_profile
-- Et tu me dis "Reviens je suis ton jour de fête. Reviens jouir mon amour dans ma bouche-agonie. -- H.F. Thiéfaine, Loreleï Sebasto Cha
Le 23-12-2014, Kevin Denis nous expliquait dans
fr.comp.os.linux.configuration
(<slrnm9jgac.2d9.kevin@slackwall.local.tux>) :
On peut fort bien remplacer gksudo par gksu et rouler jeunesse...
Sauf que pour su (j'imagine que c'est pareil avec gksu), c'est le mot de
passe root qu'il faut donner.
Ceci dit, si l'utilisateur est seul à utiliser la machine et qu'il
connait également le mot de passe root (cas typique d'un ordinateur
personnel), le problème restera le même.
Moralité, ne pas utiliser de menus qui utilisent les *.desktop reste
plus sûr.
Les alias sont lus avant les commandes dans le PATH. Donc en tant qu'user
tu peux faire un:
$ echo alias su='echo donne moi ton pass root, aie confiance' >> ~/.bashrc
$
Et la prochaine fois que tu ouvres un shell ou un terminal, la commande
su ne sera plus celle que tu crois :)
'Marche pas chez moi, je suis obligé de sourcer manuellement .bashrc
pour que ça fonctionne.
Mais comme je ne suis pas tout à fait de mauvaise foi je vais
avouer que ça fonctionne si on place l'alias dans ~/.bash_profile
--
Et tu me dis "Reviens je suis ton jour de fête.
Reviens jouir mon amour dans ma bouche-agonie.
-- H.F. Thiéfaine, Loreleï Sebasto Cha
Le 23-12-2014, Kevin Denis nous expliquait dans fr.comp.os.linux.configuration () :
On peut fort bien remplacer gksudo par gksu et rouler jeunesse...
Sauf que pour su (j'imagine que c'est pareil avec gksu), c'est le mot de passe root qu'il faut donner.
Ceci dit, si l'utilisateur est seul à utiliser la machine et qu'il connait également le mot de passe root (cas typique d'un ordinateur personnel), le problème restera le même.
Moralité, ne pas utiliser de menus qui utilisent les *.desktop reste plus sûr.
Les alias sont lus avant les commandes dans le PATH. Donc en tant qu'user tu peux faire un: $ echo alias su='echo donne moi ton pass root, aie confiance' >> ~/.bashrc $ Et la prochaine fois que tu ouvres un shell ou un terminal, la commande su ne sera plus celle que tu crois :)
'Marche pas chez moi, je suis obligé de sourcer manuellement .bashrc pour que ça fonctionne.
Mais comme je ne suis pas tout à fait de mauvaise foi je vais avouer que ça fonctionne si on place l'alias dans ~/.bash_profile
-- Et tu me dis "Reviens je suis ton jour de fête. Reviens jouir mon amour dans ma bouche-agonie. -- H.F. Thiéfaine, Loreleï Sebasto Cha
Nicolas George
Doug713705 , dans le message , a écrit :
Coucou les systèmes vérolés, ici les systèmes sains :)
Les systèmes anciens n'ont rien de moins vérolé que les systèmes actuels. Tous les mktemp(), les gets(), les strcat(), c'est sur les systèmes anciens qu'on les trouve.
Compromis ou pas mon utilisateur n'a pas d'accès en écriture sur /usr tant qu'il ne connait pas le mot de passe _root_, ne peut pas non plus executer une commande critique sans ce même mot de passe.
On s'en fout que ce soit le mot de passe « _root_ » ou « *root* » ou encore « !!!!!root!!!!! » ou bien se faire scanner la rétine. Ce qui compte, c'est que l'identité de l'utilisateur soit vérifiée plus soigneusement lors de l'exécution d'une commande critique.
Lui fournir des mécanismes lui permettant d'outrepasser des commandes (sudo + ~./local/*.desktop) qui ne s'y situent pas par hasard dans /usr/bin, /bin ou /sbin, sous prétexte de XXIème siècle c'est confondre progrès et nouveauté, vitesse et précipitation, utilité et facilité.
Tu n'as manifestement rien compris à la problématique dont il est question dans ce thread.
Ces histoires de sudo / ~/.local/*.desktop, alias et compagnie, c'est du flan, c'est des semi-débutants qui montrent qu'ils connaissent une feature et demie de plus que leur voisin.
Le fait de base est que si tu donnes ton mot de passe d'élévation de privilèges à un compte compromis, tu compromets les privilèges élevés. Que ce soit fait en changeant le PATH, en faisant un lanceur local, en bidouillant le shell ou en ptraçant l'ensemble de la session, c'est juste un détail d'implémentation. Un exploit sérieux utilisera toutes ces méthodes en combinaison de toutes façons.
Donc tout ce que tu gagnes à utiliser des technologies périmées depuis vingt-cinq ans, c'est qu'un exploit automatisé qui ne prévoit que les méthodes vieilles de moins de vingt ans se vautrera. Tu reconnaîtras que c'est assez dérisoire, comme gain.
La contrepartie, c'est que tu perds tous les avantages des technologies modernes. Pour sudo par rapport à su, on peut citer, en vrac : le logging des opérations privilégiées, la possibilité de configurer le niveau d'authentification requis (pouvoir lancer poweroff sans mot de passe, mais pas vim /etc/shadow), la possibilité d'avoir plusieurs administrateurs sans qu'ils soient obligés de partager le même mot de passe, éviter de faire les opérations intermédiaires (genre lire un man) avec les privilèges élevés, partager l'historique entre les commandes privilégiées et les commandes normales, ne pas laisser de cartouche chargée trop longtemps si on oublie de laisser tomber les privilèges, etc.
Doug713705 , dans le message <6uhombx24r.ln2@actarus.redatomik.org>, a
écrit :
Coucou les systèmes vérolés, ici les systèmes sains :)
Les systèmes anciens n'ont rien de moins vérolé que les systèmes actuels.
Tous les mktemp(), les gets(), les strcat(), c'est sur les systèmes anciens
qu'on les trouve.
Compromis ou pas mon utilisateur n'a pas d'accès en écriture sur /usr
tant qu'il ne connait pas le mot de passe _root_, ne peut pas non plus
executer une commande critique sans ce même mot de passe.
On s'en fout que ce soit le mot de passe « _root_ » ou « *root* » ou encore
« !!!!!root!!!!! » ou bien se faire scanner la rétine. Ce qui compte, c'est
que l'identité de l'utilisateur soit vérifiée plus soigneusement lors de
l'exécution d'une commande critique.
Lui fournir des mécanismes lui permettant d'outrepasser des commandes
(sudo + ~./local/*.desktop) qui ne s'y situent pas par hasard dans
/usr/bin, /bin ou /sbin, sous prétexte de XXIème siècle c'est confondre
progrès et nouveauté, vitesse et précipitation, utilité et facilité.
Tu n'as manifestement rien compris à la problématique dont il est question
dans ce thread.
Ces histoires de sudo / ~/.local/*.desktop, alias et compagnie, c'est du
flan, c'est des semi-débutants qui montrent qu'ils connaissent une feature
et demie de plus que leur voisin.
Le fait de base est que si tu donnes ton mot de passe d'élévation de
privilèges à un compte compromis, tu compromets les privilèges élevés. Que
ce soit fait en changeant le PATH, en faisant un lanceur local, en
bidouillant le shell ou en ptraçant l'ensemble de la session, c'est juste un
détail d'implémentation. Un exploit sérieux utilisera toutes ces méthodes en
combinaison de toutes façons.
Donc tout ce que tu gagnes à utiliser des technologies périmées depuis
vingt-cinq ans, c'est qu'un exploit automatisé qui ne prévoit que les
méthodes vieilles de moins de vingt ans se vautrera. Tu reconnaîtras que
c'est assez dérisoire, comme gain.
La contrepartie, c'est que tu perds tous les avantages des technologies
modernes. Pour sudo par rapport à su, on peut citer, en vrac : le logging
des opérations privilégiées, la possibilité de configurer le niveau
d'authentification requis (pouvoir lancer poweroff sans mot de passe, mais
pas vim /etc/shadow), la possibilité d'avoir plusieurs administrateurs sans
qu'ils soient obligés de partager le même mot de passe, éviter de faire les
opérations intermédiaires (genre lire un man) avec les privilèges élevés,
partager l'historique entre les commandes privilégiées et les commandes
normales, ne pas laisser de cartouche chargée trop longtemps si on oublie de
laisser tomber les privilèges, etc.
Coucou les systèmes vérolés, ici les systèmes sains :)
Les systèmes anciens n'ont rien de moins vérolé que les systèmes actuels. Tous les mktemp(), les gets(), les strcat(), c'est sur les systèmes anciens qu'on les trouve.
Compromis ou pas mon utilisateur n'a pas d'accès en écriture sur /usr tant qu'il ne connait pas le mot de passe _root_, ne peut pas non plus executer une commande critique sans ce même mot de passe.
On s'en fout que ce soit le mot de passe « _root_ » ou « *root* » ou encore « !!!!!root!!!!! » ou bien se faire scanner la rétine. Ce qui compte, c'est que l'identité de l'utilisateur soit vérifiée plus soigneusement lors de l'exécution d'une commande critique.
Lui fournir des mécanismes lui permettant d'outrepasser des commandes (sudo + ~./local/*.desktop) qui ne s'y situent pas par hasard dans /usr/bin, /bin ou /sbin, sous prétexte de XXIème siècle c'est confondre progrès et nouveauté, vitesse et précipitation, utilité et facilité.
Tu n'as manifestement rien compris à la problématique dont il est question dans ce thread.
Ces histoires de sudo / ~/.local/*.desktop, alias et compagnie, c'est du flan, c'est des semi-débutants qui montrent qu'ils connaissent une feature et demie de plus que leur voisin.
Le fait de base est que si tu donnes ton mot de passe d'élévation de privilèges à un compte compromis, tu compromets les privilèges élevés. Que ce soit fait en changeant le PATH, en faisant un lanceur local, en bidouillant le shell ou en ptraçant l'ensemble de la session, c'est juste un détail d'implémentation. Un exploit sérieux utilisera toutes ces méthodes en combinaison de toutes façons.
Donc tout ce que tu gagnes à utiliser des technologies périmées depuis vingt-cinq ans, c'est qu'un exploit automatisé qui ne prévoit que les méthodes vieilles de moins de vingt ans se vautrera. Tu reconnaîtras que c'est assez dérisoire, comme gain.
La contrepartie, c'est que tu perds tous les avantages des technologies modernes. Pour sudo par rapport à su, on peut citer, en vrac : le logging des opérations privilégiées, la possibilité de configurer le niveau d'authentification requis (pouvoir lancer poweroff sans mot de passe, mais pas vim /etc/shadow), la possibilité d'avoir plusieurs administrateurs sans qu'ils soient obligés de partager le même mot de passe, éviter de faire les opérations intermédiaires (genre lire un man) avec les privilèges élevés, partager l'historique entre les commandes privilégiées et les commandes normales, ne pas laisser de cartouche chargée trop longtemps si on oublie de laisser tomber les privilèges, etc.
