Contenu | Rechercher | Menus

Annonce

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

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

bruno

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

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.

En ligne

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

krodelabestiole

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

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)

Hors ligne

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

maxire

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

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.


Maxire
Archlinux/Mate + Ubuntu 22.04 + Archlinux/Gnome sur poste de travail

Hors ligne

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

provaire

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

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) big_smile

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) wink .


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


Totas las personas naisson liuras e egalas en dignitat e en drech.

Hors ligne

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

rogn...

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

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.

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

nam1962

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

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 !


[ Modéré ]

Hors ligne

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

rj45

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

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

Hors ligne

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

rogn...

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

rj45 a écrit :

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

Nooon ? yikes !

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

rj45

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

wink

Hors ligne

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

rj45

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

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 !

Hors ligne

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

rogn...

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

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 roll .

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

rogn...

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

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.

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

rj45

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

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)

Hors ligne

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

provaire

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

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 big_smile Elles ont toutes les deux leurs avantages et leurs inconvénient.


Totas las personas naisson liuras e egalas en dignitat e en drech.

Hors ligne

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

erresse

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

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.


Plus de 50 ans d'informatique, ça en fait des lignes de commandes en console, mais on n'avait pas le choix...
Excellente raison pour, aujourd'hui qu'on le peut, utiliser au maximum les INTERFACES GRAPHIQUES !
Important : Une fois résolu, pensez à clore votre sujet en ajoutant [Résolu] devant le titre du 1er message, et un bref récapitulatif de la solution à la fin de celui-ci. Merci.

Hors ligne

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

rogn...

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

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 big_smile 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)

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

Aldian

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

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 wink
https://doc.ubuntu-fr.org/utilisateurs/ … sudo_gedit

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

Hors ligne

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

nam1962

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

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


[ Modéré ]

Hors ligne

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

maxire

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

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)


Maxire
Archlinux/Mate + Ubuntu 22.04 + Archlinux/Gnome sur poste de travail

Hors ligne

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

uboops

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

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 wink
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

“Au lieu de faire que ce qui fût juste fût fort, on a fait que ce qui fût fort fût juste.” (Blaise Pascal).

Hors ligne