Le 19-12-2014, Bruno Ducrot nous expliquait dans fr.comp.os.linux.configuration () :
On 2014-12-18, Doug713705 wrote:
Display all 736 possibilities? (y or n)
Mais dis donc voir, ton user a le même path et les mêmes autorisations d'executuin que root ? Avec /sbin et tout ?
Ahh, c'est mieux.
Arf, j'en prends 581 de plus en tant que root !
Tu as encore tout installé comme un gros bourrin !
Comment ça *encore* ? :)
slack:/# There are 577 possibilities. Do you really wish to see them all? (y or n)
Pour info :
slack:/# uname -a Linux slack 0.99.12 #6 Sun Aug 8 16:02:35 CDT 1993 i586
Ces dans ces moments là que la fraicheur de mes écailles se fait sentir ;-)
-- Et leurs aéroports se transforment en bunkers A quatre heures du matin derrière un téléphone Quand leurs voix qui s'appellent se changent en revolvers Et s'invitent à calter en se gueulant come on -- H.F. Thiéfaine, Les dingues et le paumés
Le 19-12-2014, Bruno Ducrot nous expliquait dans
fr.comp.os.linux.configuration
(<slrnm999ev.24oq.ducrot@poup.poupinou.org>) :
On 2014-12-18, Doug713705 wrote:
Display all 736 possibilities? (y or n)
Mais dis donc voir, ton user a le même path et les mêmes
autorisations d'executuin que root ? Avec /sbin et tout ?
Ahh, c'est mieux.
Arf, j'en prends 581 de plus en tant que root !
Tu as encore tout installé comme un gros bourrin !
Comment ça *encore* ? :)
slack:/#
There are 577 possibilities. Do you really
wish to see them all? (y or n)
Pour info :
slack:/# uname -a
Linux slack 0.99.12 #6 Sun Aug 8 16:02:35 CDT 1993 i586
Ces dans ces moments là que la fraicheur de mes écailles se fait sentir
;-)
--
Et leurs aéroports se transforment en bunkers
A quatre heures du matin derrière un téléphone
Quand leurs voix qui s'appellent se changent en revolvers
Et s'invitent à calter en se gueulant come on
-- H.F. Thiéfaine, Les dingues et le paumés
Le 19-12-2014, Bruno Ducrot nous expliquait dans fr.comp.os.linux.configuration () :
On 2014-12-18, Doug713705 wrote:
Display all 736 possibilities? (y or n)
Mais dis donc voir, ton user a le même path et les mêmes autorisations d'executuin que root ? Avec /sbin et tout ?
Ahh, c'est mieux.
Arf, j'en prends 581 de plus en tant que root !
Tu as encore tout installé comme un gros bourrin !
Comment ça *encore* ? :)
slack:/# There are 577 possibilities. Do you really wish to see them all? (y or n)
Pour info :
slack:/# uname -a Linux slack 0.99.12 #6 Sun Aug 8 16:02:35 CDT 1993 i586
Ces dans ces moments là que la fraicheur de mes écailles se fait sentir ;-)
-- Et leurs aéroports se transforment en bunkers A quatre heures du matin derrière un téléphone Quand leurs voix qui s'appellent se changent en revolvers Et s'invitent à calter en se gueulant come on -- H.F. Thiéfaine, Les dingues et le paumés
mrr
On 12/19/2014 01:13 PM, Doug713705 wrote:
Le 19-12-2014, mrr nous expliquait dans fr.comp.os.linux.configuration (<54940ef6$0$2888$) :
PS: Moi aussi j'aimerais avoir un pas tout à fait Linux mais je sais pas comment faire, help!
cp c:system32ntoskrnl.exe /boot/vmlinuz
Il reste plus qu'à faire un:
export PS1="C:$( pwd | sed 's:/:\:g' )> "
et on est bon!!
PS: léger bug si on se place dans la racine. Y'a plus qu'à en informer cro$oft et ce devrait être corrigé avant l'été.
-- mrr
On 12/19/2014 01:13 PM, Doug713705 wrote:
Le 19-12-2014, mrr nous expliquait dans
fr.comp.os.linux.configuration
(<54940ef6$0$2888$426a74cc@news.free.fr>) :
PS: Moi aussi j'aimerais avoir un pas tout à fait Linux mais je sais pas
comment faire, help!
cp c:system32ntoskrnl.exe /boot/vmlinuz
Il reste plus qu'à faire un:
export PS1="C:$( pwd | sed 's:/:\\\:g' )\> "
et on est bon!!
PS: léger bug si on se place dans la racine. Y'a plus qu'à en informer
cro$oft et ce devrait être corrigé avant l'été.
Le 19-12-2014, mrr nous expliquait dans fr.comp.os.linux.configuration (<54940ef6$0$2888$) :
PS: Moi aussi j'aimerais avoir un pas tout à fait Linux mais je sais pas comment faire, help!
cp c:system32ntoskrnl.exe /boot/vmlinuz
Il reste plus qu'à faire un:
export PS1="C:$( pwd | sed 's:/:\:g' )> "
et on est bon!!
PS: léger bug si on se place dans la racine. Y'a plus qu'à en informer cro$oft et ce devrait être corrigé avant l'été.
-- mrr
yamo'
Salut,
Le 19/12/2014 11:41, Bruno Ducrot a écrit :
On 2014-12-19, Doug713705 wrote:
>Ma remarque visait simplement à marquer mon étonnement sur le fait que >Bruno en tant que simple utilisateur ou en tant que root ait le même >nombre de programmes disponibles. Ce qui_semble_[1] indiquer que son >utlisateur dispose des mêmes droits que root.
Ca veut dire simplement que le programme peut être executé en tant que simple utilisateur
C'est quoi l'intérêt au niveau de la sécurité de taper /sbin/ifconfig plutôt que ifconfig?
-- Stéphane
Salut,
Le 19/12/2014 11:41, Bruno Ducrot a écrit :
On 2014-12-19, Doug713705 wrote:
>Ma remarque visait simplement à marquer mon étonnement sur le fait que
>Bruno en tant que simple utilisateur ou en tant que root ait le même
>nombre de programmes disponibles. Ce qui_semble_[1] indiquer que son
>utlisateur dispose des mêmes droits que root.
Ca veut dire simplement que le programme peut être executé en tant que
simple utilisateur
C'est quoi l'intérêt au niveau de la sécurité de taper /sbin/ifconfig
plutôt que ifconfig?
>Ma remarque visait simplement à marquer mon étonnement sur le fait que >Bruno en tant que simple utilisateur ou en tant que root ait le même >nombre de programmes disponibles. Ce qui_semble_[1] indiquer que son >utlisateur dispose des mêmes droits que root.
Ca veut dire simplement que le programme peut être executé en tant que simple utilisateur
C'est quoi l'intérêt au niveau de la sécurité de taper /sbin/ifconfig plutôt que ifconfig?
-- Stéphane
Th.A.C
Le 22/12/2014 17:21, yamo' a écrit :
C'est quoi l'intérêt au niveau de la sécurité de taper /sbin/ifconfig plutôt que ifconfig?
éviter de lancer un autre exécutable qui aurait le même nom mais qui se trouverai ailleurs.
De la même facon, le shell ne lance pas un programme qui est dans le dossier ou tu te trouves si tu ne le spécifies pas avec '.' acollé (ou autre facon de spécifier le chemin): exemple: .monfichier.sh
Le 22/12/2014 17:21, yamo' a écrit :
C'est quoi l'intérêt au niveau de la sécurité de taper /sbin/ifconfig
plutôt que ifconfig?
éviter de lancer un autre exécutable qui aurait le même nom mais qui se
trouverai ailleurs.
De la même facon, le shell ne lance pas un programme qui est dans le
dossier ou tu te trouves si tu ne le spécifies pas avec '.' acollé (ou
autre facon de spécifier le chemin):
exemple: .monfichier.sh
C'est quoi l'intérêt au niveau de la sécurité de taper /sbin/ifconfig plutôt que ifconfig?
éviter de lancer un autre exécutable qui aurait le même nom mais qui se trouverai ailleurs.
De la même facon, le shell ne lance pas un programme qui est dans le dossier ou tu te trouves si tu ne le spécifies pas avec '.' acollé (ou autre facon de spécifier le chemin): exemple: .monfichier.sh
Th.A.C
Le 22/12/2014 17:40, Th.A.C a écrit :
Le 22/12/2014 17:21, yamo' a écrit :
C'est quoi l'intérêt au niveau de la sécurité de taper /sbin/ifconfig plutôt que ifconfig?
éviter de lancer un autre exécutable qui aurait le même nom mais qui se trouverai ailleurs.
De la même facon, le shell ne lance pas un programme qui est dans le dossier ou tu te trouves si tu ne le spécifies pas avec '.' acollé (ou autre facon de spécifier le chemin): exemple: .monfichier.sh
désolé, je voulais dire './' et non pas '.'
Le 22/12/2014 17:40, Th.A.C a écrit :
Le 22/12/2014 17:21, yamo' a écrit :
C'est quoi l'intérêt au niveau de la sécurité de taper /sbin/ifconfig
plutôt que ifconfig?
éviter de lancer un autre exécutable qui aurait le même nom mais qui se
trouverai ailleurs.
De la même facon, le shell ne lance pas un programme qui est dans le
dossier ou tu te trouves si tu ne le spécifies pas avec '.' acollé (ou
autre facon de spécifier le chemin):
exemple: .monfichier.sh
C'est quoi l'intérêt au niveau de la sécurité de taper /sbin/ifconfig plutôt que ifconfig?
éviter de lancer un autre exécutable qui aurait le même nom mais qui se trouverai ailleurs.
De la même facon, le shell ne lance pas un programme qui est dans le dossier ou tu te trouves si tu ne le spécifies pas avec '.' acollé (ou autre facon de spécifier le chemin): exemple: .monfichier.sh
désolé, je voulais dire './' et non pas '.'
mrr
désolé, je voulais dire './' et non pas '.'
lol. Attention on est sur un forum Linux :)
Sinon bon point, il suffirait qu'un attaquant qui aurait prit contrôle de l'ordinateur sous l'identité de l'utilisateur ordinaire insère son code dans un fichier exécutable "ifconfig" dans le répertoire courant (par exemple) pour que son code soit exécuté au lieu de /sbin/ifconfig. Pour peu que l'on mette un sudo devant et je vous laisse imaginer la suite.
-- mrr
désolé, je voulais dire './' et non pas '.'
lol.
Attention on est sur un forum Linux :)
Sinon bon point, il suffirait qu'un attaquant qui aurait prit contrôle
de l'ordinateur sous l'identité de l'utilisateur ordinaire insère son
code dans un fichier exécutable "ifconfig" dans le répertoire courant
(par exemple) pour que son code soit exécuté au lieu de /sbin/ifconfig.
Pour peu que l'on mette un sudo devant et je vous laisse imaginer la suite.
Sinon bon point, il suffirait qu'un attaquant qui aurait prit contrôle de l'ordinateur sous l'identité de l'utilisateur ordinaire insère son code dans un fichier exécutable "ifconfig" dans le répertoire courant (par exemple) pour que son code soit exécuté au lieu de /sbin/ifconfig. Pour peu que l'on mette un sudo devant et je vous laisse imaginer la suite.
-- mrr
Nicolas George
mrr , dans le message <5499361a$0$2896$, a écrit :
Sinon bon point, il suffirait qu'un attaquant qui aurait prit contrôle de l'ordinateur sous l'identité de l'utilisateur ordinaire insère son code dans un fichier exécutable "ifconfig" dans le répertoire courant (par exemple) pour que son code soit exécuté au lieu de /sbin/ifconfig.
Si l'attaquant a pris le contrôle du compte utilisateur normal, il a bien d'autres moyens d'étendre ses privilèges.
Pour peu que l'on mette un sudo devant et je vous laisse imaginer la suite.
sudo assainit l'environnement, c'est la moindre des choses. Mais si un attaquant a pris le contrôle, il peut aussi bien avoir détourné l'appel à sudo que l'appel à ifconfig.
mrr , dans le message <5499361a$0$2896$426a34cc@news.free.fr>, a écrit :
Sinon bon point, il suffirait qu'un attaquant qui aurait prit contrôle
de l'ordinateur sous l'identité de l'utilisateur ordinaire insère son
code dans un fichier exécutable "ifconfig" dans le répertoire courant
(par exemple) pour que son code soit exécuté au lieu de /sbin/ifconfig.
Si l'attaquant a pris le contrôle du compte utilisateur normal, il a bien
d'autres moyens d'étendre ses privilèges.
Pour peu que l'on mette un sudo devant et je vous laisse imaginer la suite.
sudo assainit l'environnement, c'est la moindre des choses. Mais si un
attaquant a pris le contrôle, il peut aussi bien avoir détourné l'appel à
sudo que l'appel à ifconfig.
mrr , dans le message <5499361a$0$2896$, a écrit :
Sinon bon point, il suffirait qu'un attaquant qui aurait prit contrôle de l'ordinateur sous l'identité de l'utilisateur ordinaire insère son code dans un fichier exécutable "ifconfig" dans le répertoire courant (par exemple) pour que son code soit exécuté au lieu de /sbin/ifconfig.
Si l'attaquant a pris le contrôle du compte utilisateur normal, il a bien d'autres moyens d'étendre ses privilèges.
Pour peu que l'on mette un sudo devant et je vous laisse imaginer la suite.
sudo assainit l'environnement, c'est la moindre des choses. Mais si un attaquant a pris le contrôle, il peut aussi bien avoir détourné l'appel à sudo que l'appel à ifconfig.
mrr
On 12/23/2014 10:55 AM, Nicolas George wrote:
mrr , dans le message <5499361a$0$2896$, a écrit :
Sinon bon point, il suffirait qu'un attaquant qui aurait prit contrôle de l'ordinateur sous l'identité de l'utilisateur ordinaire insère son code dans un fichier exécutable "ifconfig" dans le répertoire courant (par exemple) pour que son code soit exécuté au lieu de /sbin/ifconfig.
Si l'attaquant a pris le contrôle du compte utilisateur normal, il a bien d'autres moyens d'étendre ses privilèges.
Même moi, en tant qu'utilisateur de mon ordinateur, je ne vois pas comment je pourrais étendre mes droits sans connaître le mot de passe root. S'il y a comme tu dis "bien d'autres moyens d'étendre ses privilèges" cela constitue à mon sens autant de failles de sécurité qui nécessiteraient d'être corrigées! 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!
Pour peu que l'on mette un sudo devant et je vous laisse imaginer la suite.
sudo assainit l'environnement, c'est la moindre des choses. Mais si un
Ok, cela semble sain et logique, cela dit j'y avais pas pensé! Toutes mes excuses.
attaquant a pris le contrôle, il peut aussi bien avoir détourné l'appel à sudo que l'appel à ifconfig.
Oui, évidemment.
-- mrr
On 12/23/2014 10:55 AM, Nicolas George wrote:
mrr , dans le message <5499361a$0$2896$426a34cc@news.free.fr>, a écrit :
Sinon bon point, il suffirait qu'un attaquant qui aurait prit contrôle
de l'ordinateur sous l'identité de l'utilisateur ordinaire insère son
code dans un fichier exécutable "ifconfig" dans le répertoire courant
(par exemple) pour que son code soit exécuté au lieu de /sbin/ifconfig.
Si l'attaquant a pris le contrôle du compte utilisateur normal, il a bien
d'autres moyens d'étendre ses privilèges.
Même moi, en tant qu'utilisateur de mon ordinateur, je ne vois pas
comment je pourrais étendre mes droits sans connaître le mot de passe
root. S'il y a comme tu dis "bien d'autres moyens d'étendre ses
privilèges" cela constitue à mon sens autant de failles de sécurité qui
nécessiteraient d'être corrigées!
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!
Pour peu que l'on mette un sudo devant et je vous laisse imaginer la suite.
sudo assainit l'environnement, c'est la moindre des choses. Mais si un
Ok, cela semble sain et logique, cela dit j'y avais pas pensé! Toutes
mes excuses.
attaquant a pris le contrôle, il peut aussi bien avoir détourné l'appel à
sudo que l'appel à ifconfig.
mrr , dans le message <5499361a$0$2896$, a écrit :
Sinon bon point, il suffirait qu'un attaquant qui aurait prit contrôle de l'ordinateur sous l'identité de l'utilisateur ordinaire insère son code dans un fichier exécutable "ifconfig" dans le répertoire courant (par exemple) pour que son code soit exécuté au lieu de /sbin/ifconfig.
Si l'attaquant a pris le contrôle du compte utilisateur normal, il a bien d'autres moyens d'étendre ses privilèges.
Même moi, en tant qu'utilisateur de mon ordinateur, je ne vois pas comment je pourrais étendre mes droits sans connaître le mot de passe root. S'il y a comme tu dis "bien d'autres moyens d'étendre ses privilèges" cela constitue à mon sens autant de failles de sécurité qui nécessiteraient d'être corrigées! 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!
Pour peu que l'on mette un sudo devant et je vous laisse imaginer la suite.
sudo assainit l'environnement, c'est la moindre des choses. Mais si un
Ok, cela semble sain et logique, cela dit j'y avais pas pensé! Toutes mes excuses.
attaquant a pris le contrôle, il peut aussi bien avoir détourné l'appel à sudo que l'appel à ifconfig.
Oui, évidemment.
-- mrr
Nicolas George
mrr , dans le message <549955c2$0$2485$, a écrit :
Même moi, en tant qu'utilisateur de mon ordinateur, je ne vois pas comment je pourrais étendre mes droits sans connaître le mot de passe root.
C'est censé ne pas être possible, même si la profusion de trous locaux laisse penser que ça l'est presque toujours.
Ce que je disais, c'est qu'il n'est absolument pas nécessaire de dérouter un appel à une commande par root quand il est facile de dérouter l'appel en amont.
Dit de manière plus spécifique, si l'utilisateur tape son mot de passe après avoir tapé « sudo ifconfig », il est plus facile de faire en sorte que la commande effectivement exécutée soit « sudo /tmp/.mon_script_mechant » plutôt que dérouter l'appel à ifconfig ensuite.
mrr , dans le message <549955c2$0$2485$426a74cc@news.free.fr>, a écrit :
Même moi, en tant qu'utilisateur de mon ordinateur, je ne vois pas
comment je pourrais étendre mes droits sans connaître le mot de passe
root.
C'est censé ne pas être possible, même si la profusion de trous locaux
laisse penser que ça l'est presque toujours.
Ce que je disais, c'est qu'il n'est absolument pas nécessaire de dérouter un
appel à une commande par root quand il est facile de dérouter l'appel en
amont.
Dit de manière plus spécifique, si l'utilisateur tape son mot de passe après
avoir tapé « sudo ifconfig », il est plus facile de faire en sorte que la
commande effectivement exécutée soit « sudo /tmp/.mon_script_mechant »
plutôt que dérouter l'appel à ifconfig ensuite.
mrr , dans le message <549955c2$0$2485$, a écrit :
Même moi, en tant qu'utilisateur de mon ordinateur, je ne vois pas comment je pourrais étendre mes droits sans connaître le mot de passe root.
C'est censé ne pas être possible, même si la profusion de trous locaux laisse penser que ça l'est presque toujours.
Ce que je disais, c'est qu'il n'est absolument pas nécessaire de dérouter un appel à une commande par root quand il est facile de dérouter l'appel en amont.
Dit de manière plus spécifique, si l'utilisateur tape son mot de passe après avoir tapé « sudo ifconfig », il est plus facile de faire en sorte que la commande effectivement exécutée soit « sudo /tmp/.mon_script_mechant » plutôt que dérouter l'appel à ifconfig ensuite.
Kevin Denis
Le 23-12-2014, mrr a écrit :
Même moi, en tant qu'utilisateur de mon ordinateur, je ne vois pas comment je pourrais étendre mes droits sans connaître le mot de passe root.
Faille noyau par exemple.
Ensuite, sudo est généralement installé pour donner tous les droits à l'utilisateur. Il suffit quele malware te pousse à rentrer ton mot de passe dans une boite sudo/gksudo et hop.
S'il y a comme tu dis "bien d'autres moyens d'étendre ses privilèges" cela constitue à mon sens autant de failles de sécurité qui nécessiteraient d'être corrigées!
Un exemple très simple avec l'environnement de bureau XFCE. Les items du menu 'X' de XFCE sont choisies parmi les fichiers .desktop de /usr/share/applications/
Mais tu peux forcer tes applications à remplacer celles fournies par le systeme. Si tu fais par exemple: cp /usr/share/applications/synaptic.desktop ~/.local/share/applications/
alors le synaptic qui est affiché et lancé est celui de ~/.local/share/applications/synaptic.desktop
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. -- Kevin
Le 23-12-2014, mrr <mireero@free.fr> a écrit :
Même moi, en tant qu'utilisateur de mon ordinateur, je ne vois pas
comment je pourrais étendre mes droits sans connaître le mot de passe
root.
Faille noyau par exemple.
Ensuite, sudo est généralement installé pour donner tous les droits à
l'utilisateur. Il suffit quele malware te pousse à rentrer ton mot
de passe dans une boite sudo/gksudo et hop.
S'il y a comme tu dis "bien d'autres moyens d'étendre ses
privilèges" cela constitue à mon sens autant de failles de sécurité qui
nécessiteraient d'être corrigées!
Un exemple très simple avec l'environnement de bureau XFCE.
Les items du menu 'X' de XFCE sont choisies parmi les fichiers .desktop de
/usr/share/applications/
Mais tu peux forcer tes applications à remplacer celles fournies par
le systeme.
Si tu fais par exemple:
cp /usr/share/applications/synaptic.desktop ~/.local/share/applications/
alors le synaptic qui est affiché et lancé est celui de
~/.local/share/applications/synaptic.desktop
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!
Même moi, en tant qu'utilisateur de mon ordinateur, je ne vois pas comment je pourrais étendre mes droits sans connaître le mot de passe root.
Faille noyau par exemple.
Ensuite, sudo est généralement installé pour donner tous les droits à l'utilisateur. Il suffit quele malware te pousse à rentrer ton mot de passe dans une boite sudo/gksudo et hop.
S'il y a comme tu dis "bien d'autres moyens d'étendre ses privilèges" cela constitue à mon sens autant de failles de sécurité qui nécessiteraient d'être corrigées!
Un exemple très simple avec l'environnement de bureau XFCE. Les items du menu 'X' de XFCE sont choisies parmi les fichiers .desktop de /usr/share/applications/
Mais tu peux forcer tes applications à remplacer celles fournies par le systeme. Si tu fais par exemple: cp /usr/share/applications/synaptic.desktop ~/.local/share/applications/
alors le synaptic qui est affiché et lancé est celui de ~/.local/share/applications/synaptic.desktop
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!
