vulgarisation de Root et sécurité (résolu)

bruno · Le 16/12/2018, à 08:31

provaire a écrit :

Donc si je me trompe (et ça m’arrive) il faudrait que le mode Root graphique modifie un accès sans mon consentement sur un fichier système ?
Pouvez vous être m’expliquer svp ?

J'ai expliqué en #3 et d'autres l'ont également fait.

krodelabestiole · Le 16/12/2018, à 10:07

provaire a écrit :

Donc si je me trompe (et ça m’arrive) il faudrait que le mode Root graphique modifie un accès sans mon consentement sur un fichier système ?
Pouvez vous être m’expliquer svp ?

la plupart des applications graphiques que tu lances modifient des fichiers "sans ton consentement" (on dit plutôt en arrière-plan).

jette un oeil à ton ~/.config par ex.
La plupart des paramètres de chaque application, différentes fonctionnalités d'historique (- fichiers récents), et plein d'autres choses sont stockées dans des fichiers cachés de ton répertoire home.

Si tu lances une application avec sudo, il y a de grosses chances pour que ces fichiers changent de propriétaire pour l'utilisateur root... et la suite est parfaitement expliqué en #3 par bruno.

Pour répondre plus globalement à ta question je ne pense pas qu'il y ait de volonté particulière d'empêcher l'execution d'application graphique en super utilisateur.
Mais :
- l'utilisation courante d'une machine ne requiert pas (ou ne doit pas requérir) ces privileges
- les administrateurs système préfèrent généralement l'utilisation de lignes de commandes ou de scripts (plus rapide et facilement utilisable à distance)
- il y a (ou il y a eu jusque récemment) sur les environnements GNU/Linux une difficulté technique à permettre l'execution d'application en mode super utilisateur en conservant un haut niveau de sécurité.

De ce que j'ai compris par ex. avec Xorg rien n'empêche à une application lancée par l'utilisateur courant de venir espionner ce qui est affiché sur la fenêtre d'une application lancée par l'utilisateur root, alors que wayland serait plus strict à ce niveau.

Dernière modification par krodelabestiole (Le 16/12/2018, à 10:19)

maxire · Le 16/12/2018, à 11:59

Ce qui est fou c'est qu'il a fallu un lien vers Askubuntu.com pour que provaire admette qu'il existe un problème dans l'utilisation d'applications graphiques en mode super utilisateur.

En réalité 2 problèmes :

- Un problème gênant bien que mineur avec sudo sans l'option -H risquant de changer le propriétaire de fichiers de configuration de l'utilisateur avec un possible blocage de l'environnement graphique de l'utilisateur ( somme toute facile à régler )
- Un problème majeur lors de l'utilisation de Xorg avec le risque d'accéder à tout ce qui est entré via le clavier par le super utilisateur à partir d'une application tournant dans l'environnement de l'utilisateur ( cas tout de même improbable il faudrait que l'environnement utilisateur soit lui-même compromis )

Ces deux problèmes sont réglés pour le premier via l'utilisation de l'action Policykit org.gtk.vfs.file-operations :

[aspire7730z@asus-arch ~]$ pkaction --action-id org.gtk.vfs.file-operations --verbose
org.gtk.vfs.file-operations:
  description:       Perform file operations
  message:           Authentication is required to perform file operations
  vendor:            GVfs
  vendor_url:        http://git.gnome.org/browse/gvfs
  icon:              
  implicit any:      no
  implicit inactive: no
  implicit active:   auth_admin_keep

[aspire7730z@asus-arch ~]$

Cette action Policykit org.gtk.vfs.file-operations est appelée par les applications graphiques lorsqu'elles reçoivent une demande d'ouverture d'un répertoire ou fichier sous la forme admin:/// pour autant que cette possibilité y soit codée.
Lors de l'utilisation de Xorg elle n'empêche pas l'utilisation d'un key logger pour enregistrer la frappe clavier du super utilisateur.

Le deuxième problème sera définitivement réglé par le remplacement de Xorg par Wayland, d'après ce que j'ai compris.

provaire · Le 17/12/2018, à 22:55

Bruno a écrit :

provaire a écrit :
Donc si je me trompe (et ça m’arrive) il faudrait que le mode Root graphique modifie un accès sans mon consentement sur un fichier système ?
Pouvez vous être m’expliquer svp ?
J'ai expliqué en #3 et d'autres l'ont également fait.

-Effectivement j’ai bien lu les problèmes pouvant être rencontrés mais étant un vieux testar j’ai tendance a chercher a comprendre plutôt que de rester sur quelque chose qui m’échappe.

krodelabestiole a écrit :

la plupart des applications graphiques que tu lances modifient des fichiers "sans ton consentement" (on dit plutôt en arrière-plan).
jette un oeil à ton ~/.config par ex.
La plupart des paramètres de chaque application, différentes fonctionnalités d'historique (- fichiers récents), et plein d'autres choses sont stockées dans des fichiers cachés de ton répertoire home.
Si tu lances une application avec sudo, il y a de grosses chances pour que ces fichiers changent de propriétaire pour l'utilisateur root... et la suite est parfaitement expliqué en #3 par bruno.

- s’est bien l’image de /. config que je surveille quant je bidouille, merci.

krodelabestiole a écrit :

Pour répondre plus globalement à ta question je ne pense pas qu'il y ait de volonté particulière d'empêcher l'execution d'application graphique en super utilisateur.
Mais :
- l'utilisation courante d'une machine ne requiert pas (ou ne doit pas requérir) ces privilèges
- les administrateurs système préfèrent généralement l'utilisation de lignes de commandes ou de scripts (plus rapide et facilement utilisable à distance)
- il y a (ou il y a eu jusque récemment) sur les environnements GNU/Linux une difficulté technique à permettre l’exécution d'application en mode super utilisateur en conservant un haut niveau de sécurité.
Ce qui est fou c'est qu'il a fallu un lien vers Askubuntu.com pour que provaire admette qu'il existe un problème dans l'utilisation d'applications graphiques en mode super utilisateur.
Cette action Policykit org.gtk.vfs.file-operations est appelée par les applications graphiques lorsqu'elles reçoivent une demande d'ouverture d'un répertoire ou fichier sous la forme admin:/// pour autant que cette possibilité y soit codée.
Lors de l'utilisation de Xorg elle n'empêche pas l'utilisation d'un key logger pour enregistrer la frappe clavier du super utilisateur.

je n’ai pas tendance a recourir au super admin en permanence. Je ne fais qu’administré le système quant c’est nécessaire et a ce jour je n’ai pas remarqué de modif autre que celle souhaitées. Si j’avais voulu rester en Root tout le temps j’aurai certainement créer une session spéciale (perso ça n’a aucun intérêt)

- Je n’ai pas attendu de voir le lien pour réaliser que quelque chose m’échappait. Je n’aurai certainement pas créer le sujet (si j’avais des certitudes).
Pour Policykit il me semble qu’il a évolué en PolicyKit-1 et sauf erreur ça doit correspondre a
polkit (je suis plus tout jeune mais quant même)

Pour le KEY LOGGER il faudrait qu’il soit absent de glances (qui a ma préférence) en cas de doute atop et ne laisser aucune trace sur ps -ef (celle la elle loin je peux me tromper) .

En tout cas merci pour toutes ces réponses instructives.

rogn... · Le 18/12/2018, à 09:27

Salut,

Je ne sais pas si ça a été abordé, mais en graphique, je ne connais pas toutes les commandes qu'un logiciel invoque, or en root, je veux justement contrôler cela. Il y a bien sûr les scripts, que je fais moi même car je sais qu'ils seront adaptés à ce que je veux faire.

provaire a écrit :

Des deux façons d’accéder au Root : (quant s'est nécessaire)

Justement, l'accès en root n'est pas forcément nécessaire quand on pense qu'il l'est. Je pense en particulier si sur un système de deux utilisateurs, un utilisateur A voudra utiliser Firefox et un utilisateur B voudra utiliser Chromium. On peut récupérer le tarball de Firefox et l'installer que pour soi, donc pas besoin de Root, Chromium, c'est plus complexe, il faut se le compiler donc par feignantise, on va dans ce cas spécifique l'installer pour tout le système, donc besoin de root.

nam1962 · Le 18/12/2018, à 13:19

rogn... a écrit :

(...)
Je ne sais pas si ça a été abordé, mais en graphique, je ne connais pas toutes les commandes qu'un logiciel invoque, or en root, je veux justement contrôler cela. (...)

Excellent argument ! Merci, je le retiens !

rj45 · Le 18/12/2018, à 14:09

Ça invoque rien c’est pas un marabout ! Il fait appel à des lib ...

rogn... · Le 18/12/2018, à 14:12

rj45 a écrit :

Ça invoque rien c’est pas un marabout ! Il fait appel à des lib ...

Nooon ? !

rj45 · Le 18/12/2018, à 14:20

rj45 · Le 18/12/2018, à 15:57

Je suis bien d’accord avec ce que tu dis rogn... ! Mais je ne veux pas avoir de problème avec la politique des penseurs de canonial....... ci tu vois ce que je veux dire ! Purée moi je ne comprends pas une chose ! Monter vous une Arch sur un DD . C’est chiant est hard une vraie Arch au départ ! Mais ça permet de mettre en évidence beaucoup de choses ! Ah vous de voir ! Amicalement à tous j’espère de je vais pas encore me prendre des coups de pieds aux culs en disant ça de certaines personnes ! Qui on tendance à me molesté :- ) je c’est mon orthographe français est pas parfait !

rogn... · Le 18/12/2018, à 16:05

rj45 a écrit :

Je suis bien d’accord avec ce que tu dis rogn... ! Mais je ne veux pas avoir de problème avec la politique des penseurs de canonial....... ci tu vois ce que je veux dire ! Purée moi je ne comprends pas une chose ! Monter vous une Arch sur un DD . C’est chiant est hard une vraie Arch au départ ! Mais ça permet de mettre en évidence beaucoup de choses ! Ah vous de voir ! Amicalement à tous j’espère de je vais pas encore me prendre des coups de pieds aux culs en disant ça de certaines personnes ! Qui on tendance à me molesté :- ) je c’est mon orthographe français est pas parfait !

Ben là oui, tu risque de te faire molester via coups de pied au Q. Tu parles de Arch(linux ?) donc tu es carrément HS, toute orthographe correcte avec laquelle tu peux écrire.
Fais attention tout de même .

rogn... · Le 18/12/2018, à 16:06

rj45 a écrit :

Ça invoque rien c’est pas un marabout ! Il fait appel à des lib

Plus sérieusement, oui, ça fait soit appel à des lib qui font l'équivalent des commandes système, ou directement appel à une commande système.
Le problème est que lorsque l'on exécute un programme en root, il s'exécute avec le contexte root donc modifiera des choses qu'un utilisateur simple ne saura pas faire si il n'a pas les accès. Là, je dis danger si ça ne fait pas ce que l'on souhaite.
Par exemple, quand on met à jour son PC, est-ce que sur Ubuntu en particulier le Ubuntu-Software-Manager fait juste un apt update && apt dist-upgradre ? apt update && apt full-upgradre ? L'un et l'autre étant suivis de autoremove --purge ? Je ne sais pas.
En cas de doute je préfère les vieilles et bonnes méthodes.

rj45 · Le 18/12/2018, à 16:19

rogn... a écrit :

rj45 a écrit :
Ça invoque rien c’est pas un marabout ! Il fait appel à des lib
Plus sérieusement, oui, ça fait soit appel à des lib qui font l'équivalent des commandes système, ou directement appel à une commande système.
Le problème est que lorsque l'on exécute un programme en root, il s'exécute avec le contexte root donc modifiera des choses qu'un utilisateur simple ne saura pas faire si il n'a pas les accès. Là, je dis danger si ça ne fait pas ce que l'on souhaite.
Par exemple, quand on met à jour son PC, est-ce que sur Ubuntu en particulier le Ubuntu-Software-Manager fait juste un apt update && apt dist-upgradre ? apt update && apt full-upgradre ? L'un et l'autre étant suivis de autoremove --purge ? Je ne sais pas.
En cas de doute je préfère les vieilles et bonnes méthodes.

Pourquoi tu te répète là je piges pas ! Est pour les coups de pieds aux cul avec mon petit mètre 93 pas le département je précise bien ! Est mes pti 80 kilos ben je veux bien la voire la personne. ! Bon pour info le cretin qui te répond c’est ah dire moi ! Je boulotte quand même dans un data center... mais bon ... à force... j’arrive à passer pour un con tout seul !

Dernière modification par rj45 (Le 18/12/2018, à 16:29)

provaire · Le 18/12/2018, à 16:43

nam1962 a écrit :

Je ne sais pas si ça a été abordé, mais en graphique, je ne connais pas toutes les commandes qu'un logiciel invoque, or en root, je veux justement contrôler cela. Il y a bien sûr les scripts, que je fais moi même car je sais qu'ils seront adaptés à ce que je veux faire.

Je ne crois pas que quelqu'un soit capable de dire toutes les commandes invoquées par un logiciel a moins d'un logiciel indépendant de tout systèmes d'exploitations.

Ce qui est sur pour moi c'est que quelque soit la méthode employée pour être en super admin, il y a des modifications non souhaitées possible .
L'une ne parait pas plus risquée que l'autre quant on contrôle ce que l'on modifie.
Pensé que le risque est limité en ligne de commande s'est comme prétendre que la méthode graphique ne risque rien Elles ont toutes les deux leurs avantages et leurs inconvénient.

erresse · Le 18/12/2018, à 16:46

rogn... a écrit :

Par exemple, quand on met à jour son PC, est-ce que sur Ubuntu en particulier le Ubuntu-Software-Manager fait juste un apt update && apt dist-upgradre ? apt update && apt full-upgradre ? L'un et l'autre étant suivis de autoremove --purge ? Je ne sais pas.

AMHA, il ferait plus simplement "apt update && apt upgrade"... et c'est tout !
Si tu veux du "full-upgrade" et du "autoremove", tu le spécifie toi-même en ligne de commande dans un terminal.

rogn... · Le 18/12/2018, à 17:24

provaire a écrit :

nam1962 a écrit :
Je ne sais pas si ça a été abordé, mais en graphique, je ne connais pas toutes les commandes qu'un logiciel invoque, or en root, je veux justement contrôler cela. Il y a bien sûr les scripts, que je fais moi même car je sais qu'ils seront adaptés à ce que je veux faire.
Je ne crois pas que quelqu'un soit capable de dire toutes les commandes invoquées par un logiciel a moins d'un logiciel indépendant de tout systèmes d'exploitations.
Ce qui est sur pour moi c'est que quelque soit la méthode employée pour être en super admin, il y a des modifications non souhaitées possible .
L'une ne parait pas plus risquée que l'autre quant on contrôle ce que l'on modifie.
Pensé que le risque est limité en ligne de commande s'est comme prétendre que la méthode graphique ne risque rien Elles ont toutes les deux leurs avantages et leurs inconvénient.

Il n'empêche, entre deux clics entrecoupés d'une entrée de mot de passe superuser et dans un terminal un sudo commande + mot de passe, je préfère avoir par écrit la commande qui sera exécutée , qui sera ensuite facilement retrouvée dans l'historique via Flèche Haut ou history . Une commande passée par un logiciel au trois quarts du temps codé avec les pieds ne sera pas retrouvée aussi rapidement.

@erresse, je ne cherche pas de réponse précise, mais juste aimerai savoir quel impact dans le système provoque par exemple une mise à jour via GUI ou une mise à jour via un script méthodique. Sans réponse, je sais que mon script mettra à jour les paquets, leurs dépendances, mais aussi fera du nettoyage. Je reste donc avec le script en ligne de commande.

Dernière modification par rogn... (Le 18/12/2018, à 17:27)

Aldian · Le 08/01/2019, à 11:09

Salut, j'ai rédigé un brouillon pour récapituler les différents aspects du problème dans le cas spécifique de l'édition des fichiers de configuration système. Merci à ceux qui maitrisent le sujet de relire et me faire part des précisions à apporter, et à ceux qui ne le maitrisent pas, de me faire part de leurs incompréhensions
https://doc.ubuntu-fr.org/utilisateurs/ … sudo_gedit

Dernière modification par Aldian (Le 08/01/2019, à 11:10)

nam1962 · Le 08/01/2019, à 11:29

Très beau boulot !
Sur le sudo -H, j'ai eu des echos moins négatifs, cela dit.
cf liens post #6 et post #21

maxire · Le 08/01/2019, à 12:13

Effectivement, c'est un beau travail, préciser le cas de Wayland où à l'heure actuelle seul admin:///.... est utilisable pour passer en mode super utilisateur.
Pour l'utilisation de pkexec ce n'est plus aussi simple dépendamment des environnement, sous Mate/Archlinux, Dbus casse la baraque :

[aspire7730z@asus-arch ~]$ pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY caja 

(caja:7830): GLib-GIO-CRITICAL **: 12:56:49.005: g_dbus_proxy_new_sync: assertion 'G_IS_DBUS_CONNECTION (connection)' failed

(caja:7830): GLib-GIO-CRITICAL **: 12:56:49.005: g_dbus_connection_get_unique_name: assertion 'G_IS_DBUS_CONNECTION (connection)' failed
Erreur de segmentation (core dumped)
[aspire7730z@asus-arch ~]$ man dbus-launch
[aspire7730z@asus-arch ~]$ pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY dbus-launch caja 
Initializing caja-xattr-tags extension
Initializing caja-open-terminal extension
Initializing caja-image-converter extension
Caja-Share-Message: 12:57:36.515: Called "net usershare info" but it failed: 'net usershare' a renvoyé une erreur 255: net usershare: usershares are currently disabled

^C
[aspire7730z@asus-arch ~]$ pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY dbus-launch caja /etc
Initializing caja-xattr-tags extension
Initializing caja-open-terminal extension
Initializing caja-image-converter extension
Caja-Share-Message: 12:58:02.806: Called "net usershare info" but it failed: 'net usershare' a renvoyé une erreur 255: net usershare: usershares are currently disabled

Donc pkexec devrait être utilisé comme ceci :

pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY dbus-launch ...

Je donne cet exemple sous Archlinux/Mate car il est très possible que cela soit la même chose sous Ubuntu/Mate, je ne le sais pas je n'utilise pas de Ubuntu/Mate mais des Ubuntu/GNome et Lubuntu 18.04.

Dernière modification par maxire (Le 08/01/2019, à 13:03)

uboops · Le 08/01/2019, à 13:08

Aldian a écrit :

Salut, j'ai rédigé un brouillon pour récapituler les différents aspects du problème dans le cas spécifique de l'édition des fichiers de configuration système. Merci à ceux qui maitrisent le sujet de relire et me faire part des précisions à apporter, et à ceux qui ne le maitrisent pas, de me faire part de leurs incompréhensions
https://doc.ubuntu-fr.org/utilisateurs/ … sudo_gedit

3.2 via une application graphique

Se reporter au tutoriel Comment modifier un fichier. Un exemple:
gedit admin:///chemin/absolu/vers/fichier

... Il y a aussi dans les possibles:

su-to-root -X -c synaptic
# si pkexec possible pour l'application-
synaptic-pkexec
pkexec synaptic

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#26 Le 16/12/2018, à 08:31

Re : vulgarisation de Root et sécurité (résolu)

#27 Le 16/12/2018, à 10:07

Re : vulgarisation de Root et sécurité (résolu)

#28 Le 16/12/2018, à 11:59

Re : vulgarisation de Root et sécurité (résolu)

#29 Le 17/12/2018, à 22:55

Re : vulgarisation de Root et sécurité (résolu)

#30 Le 18/12/2018, à 09:27

Re : vulgarisation de Root et sécurité (résolu)

#31 Le 18/12/2018, à 13:19

Re : vulgarisation de Root et sécurité (résolu)

#32 Le 18/12/2018, à 14:09

Re : vulgarisation de Root et sécurité (résolu)

#33 Le 18/12/2018, à 14:12

Re : vulgarisation de Root et sécurité (résolu)

#34 Le 18/12/2018, à 14:20

Re : vulgarisation de Root et sécurité (résolu)

#35 Le 18/12/2018, à 15:57

Re : vulgarisation de Root et sécurité (résolu)

#36 Le 18/12/2018, à 16:05

Re : vulgarisation de Root et sécurité (résolu)

#37 Le 18/12/2018, à 16:06

Re : vulgarisation de Root et sécurité (résolu)

#38 Le 18/12/2018, à 16:19

Re : vulgarisation de Root et sécurité (résolu)

#39 Le 18/12/2018, à 16:43

Re : vulgarisation de Root et sécurité (résolu)

#40 Le 18/12/2018, à 16:46

Re : vulgarisation de Root et sécurité (résolu)

#41 Le 18/12/2018, à 17:24

Re : vulgarisation de Root et sécurité (résolu)

#42 Le 08/01/2019, à 11:09

Re : vulgarisation de Root et sécurité (résolu)

#43 Le 08/01/2019, à 11:29

Re : vulgarisation de Root et sécurité (résolu)

#44 Le 08/01/2019, à 12:13

Re : vulgarisation de Root et sécurité (résolu)

#45 Le 08/01/2019, à 13:08

Re : vulgarisation de Root et sécurité (résolu)

Pied de page des forums