applications graphiques en mode administrateur (sudo …)

Arbiel · Le 05/02/2019, à 00:42

Bonsoir

Pour des raisons qui me sont propres et ne présentent ici aucun intérêt, je suis longtemps resté au niveau de la 14.04 que je n'ai quité que récemment pour la 18.04. À l'époque de la 14.04, exécuter en mode administrateur des applications graphiques telles que gedit, nautilus, gparted, synaptic, était monnaie courante et personne ne s'en offusquait, du moins ouvertement. Depuis cette époque, beaucoup de choses semblent avoir changé et vous êtes nombreux à être maintenant vent debout contre de telles pratiques.

La première raison, qui ressort de la lecture des conversations du forum, est le fait que certaines applications graphiques mettent à jour ou créent des fichiers qui leur sont propres. Lorsque ces applications sont exécutées en mode administrateur, ces fichiers deviennent la propriéte de "root" et ne sont plus accessibles en mode utilisateur, ce qui entraîne des dysfonctionnements que les utilisateurs non avertis ne savent pas résoudre par eux-mêmes. Cela les conduit à demander de l'aide sur le forum, ce qui est une perte de temps et d'énergie pour les intervenants aptes à y répondre. Autant donc déconseiller l'exécution des applications graphiques en mode administrateur pour ne pas gaspiller son temps à résoudre des problèmes que l'on peut très bien éviter avec un peu de discipline.

D'après ce que j'ai compris dans ces discussions, une manière de contourner le problème est de changer d'environnement d'exécution pour que ces fichiers ne se trouvent plus dans l'espace utilisateur. L'exécution des applications en mode utilisateur et en mode adminstrateur ne portant plus sur les mêmes fichiers, le fonctionnement en mode utilisateur ne serait alors plus perturbé. Mais certains conseils, comme utiliser l'option -H de sudo, ne me semblent pas atteindre cet objectif. Alors que cela semble le cas pour l'option -i, que je n'ai pas vue être recommandée

remi@remi-Vostro-3550:~$ function pwd { echo "${PWD}" ; }
remi@remi-Vostro-3550:~$ sudo -H pwd
/home/remi
remi@remi-Vostro-3550:~$ sudo -i pwd
/root

Pour ma part, lorsque je veux modifier un fichier propriété de "root", par exemple /etc/fstab, je le modifie en mode utilisateur, le sauvegarde dans /tmp, puis le recopie vers son répertoire d'origine par la commande

sudo cp -t /etc /tmp/fstab

Ce faisant je n'ai cependant pas de sauvegarde automatique du fichier original.

Une seconde raison pour ne pas exécuter les applications graphiques en mode administrateur serait que cette pratique présente une faille de sécurité. N'ayant pas vu d'arguments en faveur de cette affirmation, j'ai essayé de comprendre quelle pouvait être cette faille. Je n'ai abouti qu'à l'hypothèse de la présence du mot de passe de l'utilisateur en mémoire, et donc sa lecture potentielle par un pirate pendant toute la durée de l'exécution de l'application, durée qui peut être longue du fait du mode généralement interactif des applications graphiques.

Mais je n'ai pas tenu bien longtemps cette hypothèse comme vraisemblable puisque, d'une part, le passage en mode administrateur ne nécessite pas obligatoirement la saisie du mot de passe (option NOPASSWD dans /etc/sudoers ou dans un fichier du répertoire /etc/sudoers.d) et que d'autre part les commandes exécutées depuis un terminal peuvent également durer longtemps, voire être elles-mêmes interactives.

Merci d'avance à ceux d'entre vous qui voudront bien me faire part de leurs commentaires sur ces deux sujets.

Arbiel

Roschan · Le 05/02/2019, à 06:04

À l'époque de la 14.04, exécuter en mode administrateur des applications graphiques telles que gedit, nautilus, gparted, synaptic, était monnaie courante et personne ne s'en offusquait

"personne" sauf les développeurs d'Ubuntu qui l'ont retiré des ISO dès la 13.04 https://forum.ubuntu-fr.org/viewtopic.php?id=1584891 après avoir passé plusieurs années à concevoir, implémenter et utiliser polkit pour fournir une alternative.

La première raison, qui ressort de la lecture des conversations du forum, est le fait que certaines applications graphiques mettent à jour ou créent des fichiers qui leur sont propres. Lorsque ces applications sont exécutées en mode administrateur, ces fichiers deviennent la propriéte de "root" et ne sont plus accessibles en mode utilisateur, ce qui entraîne des dysfonctionnements que les utilisateurs non avertis ne savent pas résoudre par eux-mêmes. Cela les conduit à demander de l'aide sur le forum, ce qui est une perte de temps et d'énergie pour les intervenants aptes à y répondre. Autant donc déconseiller l'exécution des applications graphiques en mode administrateur pour ne pas gaspiller son temps à résoudre des problèmes que l'on peut très bien éviter avec un peu de discipline.

C'est davantage un problème pour les utilisateurs, c'est eux qui se retrouvent avec des bizarreries, des corruptions de droits, des bugs et des problèmes de sécurité après.

N'ayant pas vu d'arguments en faveur de cette affirmation, j'ai essayé de comprendre quelle pouvait être cette faille. Je n'ai abouti qu'à l'hypothèse de la présence du mot de passe de l'utilisateur en mémoire, et donc sa lecture potentielle par un pirate pendant toute la durée de l'exécution de l'application, durée qui peut être longue du fait du mode généralement interactif des applications graphiques.

T'as pas du chercher bien loin, dès qu'on cherche en anglais on a 10 pages qui listent les failles des clients graphiques avec le protocole X11 : tout client X11 peut théoriquement communiquer avec les autres, que ce soit en lecture (captures d'écran, ...) et même me semble-t-il en écriture (envoi de frappes au clavier ou de clics) : n'importe quel petit script lancé par un utilisateur non-privilégié peut récupérer tout ce qu'il veut sur les autres fenêtres et y envoyer les entrées qu'il veut... et pendant longtemps, c'était le cas même si la fenêtre était un programme lancé comme admin. À cause de cela, énormément d'efforts ont été fait pour limiter la casse, et ce dès les années 90, mais c'est encore d'actualité, et on ne parle pas de 8 péquenauds sur un forum mais bien de la NSA https://www.nsa.gov/Portals/70/images/r … report.pdf

Normalement ces problèmes sont supposés être "mitigés" comme on dit (quoique... https://it.slashdot.org/story/18/10/26/ … d-systems) mais le cœur du problème c'est que personne n'a jamais fait d'audit de sécurité sur nautilus ou gedit, qui sont à ce titre potentiellement sensible aux virus (ce sont des applications qui ont des plugins d'ailleurs, donc véroler nautilus n'est pas vraiment compliqué). Et lancer un virus en tant qu'administrateur, c'est tuer sa machine.

D'après ce que j'ai compris dans ces discussions, une manière de contourner le problème est de changer d'environnement d'exécution

Ou alors d'utiliser polkit, ce qui se fait nativement avec chacune des applications citées pour limiter la surface d'attaque. Synaptic ? ça demande le mot de passe sans aucune configuration de la part de l'utilisateur. GParted ? pareil. Gedit ? ça demande le mot de passe quand l'utilisateur ouvre une URI commençant par "admin://". Nautilus ? pareil. À zéro moment on n'a besoin de changer quoi que ce soit dans le cas d'une utilisation "normale", mais pour certains cas un peu particulier libre à toi d'utiliser ce genre de technique. Quitte à être en ligne de commande, tu peux sinon utiliser nano : faire

sudo -H nano /machin/truc.txt

dans un terminal lancé en tant qu'utilisateur normal ne présente pas les problèmes cités

Dernière modification par Roschan (Le 05/02/2019, à 06:12)

bruno · Le 05/02/2019, à 10:10

Abriel, tu as parfaitement résumé la situation.

J'ai déjà conseillé dans je ne sais plus quel fil d'utiliser sudo -i pour obtenir un shell root systématiquement pour exécuter des tâches administratives. Et j'ai toujours dit qu'il ne fallait pas lancer une application graphique en tant que root.

Pour la sécurité, Roschan donne des indications très pertinentes. À cela il faut ajouter le risque de mauvaise manipulations accidentelles avec un gestionnaire de fichiers lancé en root. Quoiqu’en disent certains ce risque est beaucoup plus élevé en mode graphique qu'en ligne de commande.

Voyez la réponse d'un développeur GNOME dans ce signalement de bogue qui reprend exactement les points évoqués : https://bugzilla.gnome.org//show_bug.cgi?id=772875#c5

Emmanuele Bassi a écrit :

Speaking as the developer of a GUI toolkit, and as an application developer, no: there are no *real*, substantiated, technological reasons why anybody should run a GUI application as root. By running GUI applications as an admin user you're literally running millions of lines of code that have not been audited properly to run under elevated privileges; you're also running code that will touch files inside your $HOME and may change their ownership on the file system; connect, via IPC, to even more running code, etc.

Traduction :

En tant que développeur d’applications graphiques, non : il n'y a pas de raisons réelles, justifiées, techniques pour que quelqu'un exécute une application graphique en tant que root. En lançant des applications graphiques en tant qu'administrateur, vous exécutez des millions de lignes de code qui n'ont pas été audités correctement pour une exécution avec des privilèges élevés; et encore plus de code via une connexion distante, etc.. Vous exécutez également du code qui va toucher des fichiers de votre dossier personnel et pourrait changer leur propriétaire.

Et comme il le dit plus loin, ce n'est pas tant un problème de sécurité qu'un problème de compréhension du système, des privilèges et de leur séparation. Il n'est absolument pas nécessaire d'exécuter une application graphique en tant que root.
Quand une application graphique a besoin des privilèges administratifs, elle ne doit les acquérir qu'au moment où cela est nécessaire. Ce qui est le cas par exemple d'une application de gestion des paquets, des gestion des partitions, etc.

Arbiel · Le 06/02/2019, à 13:03

Bonjour

Merci pour vos commentaires.

Un petit détail

Roschan a écrit :

"personne" sauf les développeurs d'Ubuntu qui l'ont retiré des ISO dès la 13.04 https://forum.ubuntu-fr.org/viewtopic.php?id=1584891 après avoir passé plusieurs années à concevoir, implémenter et utiliser polkit pour fournir une alternative.
…
T'as pas du chercher bien loin, dès qu'on cherche en anglais on a 10 pages qui listent les failles des clients graphiques avec le protocole X11

Je pratique essentiellement le présent forum et n'ai guère le temps, et les capacités, de naviguer sur les fora en langue étrangère ou d'analyser par le détail l'évolution des distributions. J'imagine qu'un grand nombre des utilisateurs du forum sont dans mon cas et ne maîtrisent pas l'anglais aussi bien que bruno.

Je conçois parfaitement que l'exécution d'applications graphiques en mode administrateur ne soit pas recommandable. Sur ce point, et dans mon cas particulier, il s'agit essentiellement de modifier des fichiers textuels avec gedit, pratique nettement plus confortable qu'avec sed ou tout autre éditeur de texte en ligne de commande.

Mais je reconnais aussi n'avoir, jusqu'à aujourd'hui, pas suffisamment réfléchi à la gestion des droits. Après avoir modifié en "écriture pour tous" les propriétés de /etc/fstab, j'ai pu le modifier sans passer en mode administrateur. Cette manière de procéder n'est, ce me semble, réaliste que dans le contexte d'un système mono-utilisateur, en l'occurrence le contexte dans lequel je me trouve.

J'ai compris que les failles de sécurité de X11 ne comportent apparemment de risques que dans un contexte multi-utilisateur. Qu'il faille les supprimer, un des objectifs de Wayland ?, est tout à fait louable, mais dans un contexte mono-utilisateur, ces failles me paraissent ne présenter aucun risque.

J'ai également tester

sudo -i gedit /etc/fstab

pour constater que l'espace personnel dans lequel j'ai enregistré le fichier est bien /root.

Merci encore

bruno · Le 06/02/2019, à 13:21

Abriel a écrit :

il s'agit essentiellement de modifier des fichiers textuels avec gedit, pratique nettement plus confortable qu'avec sed ou tout autre éditeur de texte en ligne de commande.

C'est plus confortable pour toi parce que tu ne maîtrise pas l'éditeur en mode textuel. L'éditeur par défaut nano est tout de même extrêmement simple et permet toutes opérations courantes sur un fichier texte.

Abriel a écrit :

Après avoir modifié en "écriture pour tous" les propriétés de /etc/fstab, j'ai pu le modifier sans passer en mode administrateur. Cette manière de procéder n'est, ce me semble, réaliste que dans le contexte d'un système mono-utilisateur, en l'occurrence le contexte dans lequel je me trouve.

Cela me semble typique de ce que je disais plus haut. L'utilisateur ne comprend pas pourquoi il ne peut pas modifier un fichier : il change les droits, par flemme, par ignorance, par habitude d'autres OS où il agit en permanence comme super utilisateur, etc.
Cette manière de faire et mauvaise quelque soient les circonstances.

Les procédures pour lancer gedit en tant que root on été décrites par ailleurs (avec pkexec, avec admin:///, …).
<troll inside> Si tu utilisais un bon environnement de bureau, ton éditeur de texte serait capable de demander une élévation de privilège (demande de mot de passe) au moment où il en besoin, c'est à dire à l’enregistrement du fichier.</troll inside>

Roschan · Le 06/02/2019, à 14:22

Cette manière de procéder n'est, ce me semble, réaliste que dans le contexte d'un système mono-utilisateur, en l'occurrence le contexte dans lequel je me trouve.
J'ai compris que les failles de sécurité de X11 ne comportent apparemment de risques que dans un contexte multi-utilisateur. Qu'il faille les supprimer, un des objectifs de Wayland ?, est tout à fait louable, mais dans un contexte mono-utilisateur, ces failles me paraissent ne présenter aucun risque.

Mais tout OS GNU-Linux est par essence multi-utilisateur...

- root
- toi

Selon si tu as les logiciels correspondants (c'est normalement le cas sur Ubuntu) :

- gdm
- avahi
- systemd-*
- rtkit

Un malware qui infecte l'ordinateur se fiche bien de savoir combien d'utilisateurs (humains ou non) il y a, quand il voit qu'il peut modifier le fstab sans aucune restriction il ne s'en prive pas.

Arbiel · Le 06/02/2019, à 20:08

Bonsoir

Bien. Je prends bonne note de vos remarques.

Je conçois parfaitement que, compte tenu de la présence dans mon système d'autres utilisateurs que j'ai un peu trop rapidement ignorée, donner à tout le monde le droit de modifier les fichiers systèmes est une très mauvaise idée. J'ai momentanément imaginé de rendre le groupe sudo, dont je suis le seul membre, propriétaire des fichiers systèmes que je suis amené à modifier de temps à autre, mais je suppose que je biaiserais par là la politique de sécurité de mon système.

J'ai bien compris que je pouvais utiliser pkexec ou admin:/// pour exécuter gedit en mode administrateur en toute sécurité. Ma réticence à ce faire provient de ma paresse qui me pousse à éviter de saisir mon mot de passe pour les commandes qui nécessitent le passage en mode administrateur, telles que blkid, lvdisplay, … L'utilsation de sudo me le permet, à contrario de pkexec ou de admin:///.

Apprendre à utiliser un nouvel éditeur de texte est à ma portée, mais je préfère finalement m'en tenir à la méthode que j'utilise depuis quelque temps : exécuter gedit en mode utilisateur, enregistrer le fichier modifié dans /tmp, puis le recopier en mode administrateur vers le répertoire approprié. Un petit script me permet de le faire sans saisie volumineuse.

Je vais voir comment m'interdire d'exécuter gedit, et nautilus à mes yeux beaucoup plus dangereux, en mode administrateur avec sudo.

Merci encore pour vos conseils.

Arbiel

Dernière modification par Arbiel (Le 16/02/2019, à 00:49)

Arbiel · Le 07/02/2019, à 18:47

Apparemment modifier le groupe d'appartenance de certains fichiers système ne semble pas si farfelu que cela

remi@remi-Vostro-3550:~$ ls -l /etc | g -vE "root root"
total 1176
drwxr-s---  2 root dip     4096 janv. 22 22:01 chatscripts
drwxr-xr-x  5 root lp      4096 févr.  7 17:27 cups
-rw-r-----  1 root shadow   776 janv. 23 19:48 gshadow
-rw-r-----  1 root shadow   762 janv. 11 13:31 gshadow-
drwxr-xr-x  8 root dip     4096 janv. 22 22:01 ppp
-rw-r-----  1 root shadow  1270 janv. 11 13:31 shadow
-rw-r-----  1 root shadow  1173 janv. 11 13:31 shadow-
remi@remi-Vostro-3550:~$ g -E "(dip|lp|shadow)" /etc/group
lp:x:7:
dip:x:30:remi
shadow:x:42:
lpadmin:x:116:remi
remi@remi-Vostro-3550:~$

Je vais dont le faire pour les fichiers que je suis amené à modifier de temps à autre, ce qui me permettra de continuer à utiliser gedit sans avoir à passer en mode administrateur.

bruno · Le 07/02/2019, à 21:59

Tu fais comme tu veux, mais on ne devrait jamais changer les propriétaires et groupe des fichiers systèmes, ni leur droits d'accès. C'est le plus sûr moyen de diminuer la sécurité du système et d'avoir des problèmes allant jusqu'au blocage complet…

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 05/02/2019, à 00:42

applications graphiques en mode administrateur (sudo …)

#2 Le 05/02/2019, à 06:04

Re : applications graphiques en mode administrateur (sudo …)

#3 Le 05/02/2019, à 10:10

Re : applications graphiques en mode administrateur (sudo …)

#4 Le 06/02/2019, à 13:03

Re : applications graphiques en mode administrateur (sudo …)

#5 Le 06/02/2019, à 13:21

Re : applications graphiques en mode administrateur (sudo …)

#6 Le 06/02/2019, à 14:22

Re : applications graphiques en mode administrateur (sudo …)

#7 Le 06/02/2019, à 20:08

Re : applications graphiques en mode administrateur (sudo …)

#8 Le 07/02/2019, à 18:47

Re : applications graphiques en mode administrateur (sudo …)

#9 Le 07/02/2019, à 21:59

Re : applications graphiques en mode administrateur (sudo …)

Pied de page des forums