Lancer des applications KDE4 à partir d'une console root

Pause Café
#1

Digression du post viewtopic.php?f=8&t=26905

[quote=“syam”]@ggoodluck47 : merci pour ton sarcasme, mais la sécurité de ma machine se porte bien. Simplement, quand je suis déjà en train de bricoler en root je ne vois pas l’intérêt de devoir retaper le mot de passe alors que je peux lancer la commande directement.
[/quote]Ben c’est déjà là le gros problème ne pas bricoler en root.[quote=“syam”]
Je pense que tu es mieux placé que moi (tu es en sid si j’ai bonne mémoire) pour savoir que ça arrive assez régulièrement de devoir passer un bon moment en root pour configurer une machine…
J’aurais dû être un peu plus explicite à ce sujet dans mon post d’origine.
[/quote]Pas forcément lorsque je reconfigure ma machine je n’ai pas obligatoirement tous les droits root il est important de ne mettre que le nécessaire et non pas d’ouvrir tout[quote=“syam”]

Sinon, concernant kdesu : j’ai un comportement étrange ici, à savoir que le lanceur de commandes (Alt+F2) reconnaît kdesu, mais dès que je suis en console il n’y a plus rien à faire. Je n’ai pas cherché pour le moment, j’ai bien assez à faire à tout réinstaller.

Dernier point :

[quote]cela pouvant entraîner des répercutions négatives sur votre système[/quote]Mis à part les évidents soucis de sécurité si on fait n’importe quoi (oui, j’aurais dû mettre un disclaimer moi-même à ce sujet, mea culpa, mais ça me paraissait évident), à quelles autres répercussions peut-on s’attendre ? J’entends bien sûr par là des soucis dont l’origine ne se situe pas entre la chaise et le clavier : non pas que ça ne m’arrive jamais de faire des bêtises, mais mon utilisation en root d’applis graphiques se limite généralement à kate (et éventuellement quelques programmes comme systemsettings quand je n’ai pas le choix) ce qui en soi limite fortement les risques d’erreurs.[/quote]Et c’est bien là tout le problème d’utilisation de kate un éditeur en tant que root peut faire des dégats suite à une fausse manip ou encore à une mauvaise configuration de ton fichier. L’utilisation de ton exception dans ta question est inapproprié car le problème est toujours situé entre la chaise et le clavier.

Tu le dis toi-même cela limite fortement les risques mais on entend bien que le risque 0 n’existe pas et c’est seulement cela que l’on voulait souligner. Cependant je suis d’accord avec toi que si l’on sait ce que l’on fait et que l’on fait bien attention il y a encore moins de risque mais il faut aussi savoir que nous ne sommes pas tous ni tout le temps dans un jour où nous pouvons nous vanter d’être exhaustif dans notre vérification.

#2

Salut Ash,

Peut-être es-tu assez calé pour nous expliquer en quoi consiste ce trou de sécurité dans la relation client : serveur car enfin il s’agit bien d’une volonté des développeurs de ne pas faciliter la venue de root dans ces “graphiques” !

#3

On peut aussi se poser la simple question : pourquoi a-t-on enlevé cette possibilité ?
Quand on sait que Debian cherche en priorité la sécurité, on a la réponse.
Ne jamais oublier la confiance, parfois aveugle, que nous portent les néophytes.
Il est évident que ton “truc” peut avoir un intérêt pour quelqu’un qui maîtrise bien linux mais il ne faut jamais perdre de vue que nous sommes lus, aussi, par des débutants.
C’est pour cela, qu’une mise en garde est toujours la bienvenue.

#4

Re,

Nous avons, malgré tout, considéré ton astuce comme valable car sinon elle aurait atterri dans une autre section :slightly_smiling:

#5

[quote=“syam”]Je pense que tu es mieux placé que moi (tu es en sid si j’ai bonne mémoire) pour savoir que ça arrive assez régulièrement de devoir passer un bon moment en root pour configurer une machine…[/quote]Je suis aussi en Sid et ça ne m’arrive jamais de rester longtemps loggué en tant que root, en général juste le temps d’éditer un fichier.

En plus l’argument de la fréquence ou de la durée ne justifie pas plus l’utilisation de la session graphique pour des tâches potentiellement dangereuse.
C’est un peu comme si tu disais :
“Boire ou choisir, il faut conduire!”

#6

[quote=“Ashgenesis”]Ben c’est déjà là le gros problème ne pas bricoler en root.[/quote]Le terme “bricoler” était peut-être mal choisi, j’entendais par là configurer la machine. Quand 3 commandes sur 4 nécessitent les droits root le plus pratique (dans l’état actuel de mes connaissances) reste tout de même une bonne vieille session root.

Cela dit…

[quote=“Ashgenesis”]Pas forcément lorsque je reconfigure ma machine je n’ai pas obligatoirement tous les droits root il est important de ne mettre que le nécessaire et non pas d’ouvrir tout[/quote][quote=“ggoodluck47”]Effectivement je passe en root lors de l’installation d’un système, le temps, et juste le temps de mettre à jour le /etc/sudoers.[/quote]J’avoue que je ne maîtrise pas du tout le concept de sudo. De ce que j’en ai vu il s’agit d’élever les droits du seul process appelé avec cette commande, mais mon expérience sous (k)ubuntu m’a posé des dilemmes par rapport à ça : j’ai du mal à comprendre comment un mécanisme qui “retient” le mot de passe (et à partir de là, permet de lancer n’importe quel programme sans plus d’authentification) peut être plus sécurisé qu’une simple session root. Au contraire ça me paraît, d’instinct, encore pire puisqu’une fois le mot de passe en cache n’importe quel process utilisateur peut lancer ce qu’il veut comme il veut avec les droits root.
Il y a clairement anguille sous roche là, sûrement quelque chose que je n’ai pas compris, mais j’avoue que du coup j’ai tendance à me rabattre sur les concepts que je maîtrise.

[quote=“Ashgenesis”]Et c’est bien là tout le problème d’utilisation de kate un éditeur en tant que root peut faire des dégats suite à une fausse manip ou encore à une mauvaise configuration de ton fichier. L’utilisation de ton exception dans ta question est inapproprié car le problème est toujours situé entre la chaise et le clavier.[/quote]Oui enfin à un moment il faut bien éditer les fichiers, que ce soit avec kate / emacs / vi(m) / nano, en root “pur” ou via sudo, ça revient strictement au même en ce qui concerne les éventuelles erreurs de manip provoquées par l’utilisateur, me semble-t-il. D’où le fait que je demande s’il y avait des risques autres, liés spécifiquement aux applications graphiques (et j’ai bien fait de demander, puisqu’il s’avère que c’est le cas).

[quote=“Ashgenesis”]Tu le dis toi-même cela limite fortement les risques mais on entend bien que le risque 0 n’existe pas et c’est seulement cela que l’on voulait souligner. Cependant je suis d’accord avec toi que si l’on sait ce que l’on fait et que l’on fait bien attention il y a encore moins de risque mais il faut aussi savoir que nous ne sommes pas tous ni tout le temps dans un jour où nous pouvons nous vanter d’être exhaustif dans notre vérification.[/quote]On est bien d’accord.

[quote=“ricardo”]Ne jamais oublier la confiance, parfois aveugle, que nous portent les néophytes.
Il est évident que ton “truc” peut avoir un intérêt pour quelqu’un qui maîtrise bien linux mais il ne faut jamais perdre de vue que nous sommes lus, aussi, par des débutants.
C’est pour cela, qu’une mise en garde est toujours la bienvenue.[/quote]Entièrement d’accord avec ça. Comme je l’ai dit dans l’autre fil, je n’ai pas pensé à mettre un avertissement car ça me semblait évident. C’était une erreur de ma part, accentuée par le fait que, même si je me débrouille suffisamment pour pouvoir gérer ma machine et administrer quelques serveurs, j’ai souvent moi-même l’impression d’être un néophyte complet quand je vois la plupart des discussions sur ce forum. :mrgreen:

[quote=“eol”]En plus l’argument de la fréquence ou de la durée ne justifie pas plus l’utilisation de la session graphique pour des tâches potentiellement dangereuse.[/quote]Encore une fois, deux choses à distinguer :

  • l’utilisation proprement dite, comme plusieurs y compris moi-même l’ont fait remarquer on n’est jamais à l’abri d’une erreur mais à ce niveau là ça n’arrangera rien de faire la même manip sous – par exemple – nano ; je pense qu’on est tous d’accord là dessus
  • les problèmes de sécurité inhérents aux applis graphiques, dont je n’avais clairement pas conscience jusqu’ici

Bref, ça aura au moins eu l’avantage de lancer une discussion intéressante. Je suis curieux de savoir comment vous faites, précisément, pour vous passer de session root quand il faut éditer des fichiers / relancer le(s) service(s) correspondant(s) / tester la nouvelle config (dans une session utilisateur si c’est possible, mais parfois non) / corriger les fichiers et ainsi de suite jusqu’à obtenir le résultat désiré.

#7

(dans une session utilisateur si c’est possible, mais parfois non)[/quote]J’ai cherché mais je n’arrive pas à voir dans quel cas il n’est pas possible de tester une config en tant qu’utilisateur?
Tu parles de modifications effectuées sur des applis qui nécessitent les droits root pour être éxecutées?

#8

[quote=“eol”]J’ai cherché mais je n’arrive pas à voir dans quel cas il n’est pas possible de tester une config en tant qu’utilisateur?
Tu parles de modifications effectuées sur des applis qui nécessitent les droits root pour être éxecutées?[/quote]
J’avais en tête une appli bien précise, qui a effectivement besoin des droits root pour tourner. J’admets que c’est un cas très spécifique, d’autant plus que c’est moi qui l’ai développée et je sais qu’elle a des lacunes, mais on fait ce qu’on peut avec ce qu’on a. :wink: J’ai bien prévu d’améliorer son fonctionnement (setuid le plus tôt possible et même chroot) mais tu sais ce que c’est, y’a toujours plus urgent à faire que de modifier un truc qui fonctionne…
Bref, tout ça pour dire que ça peut arriver de devoir tester un truc en root.

Par contre, le chroot transparent de fran.b m’intéresse énormément de ce côté là, non seulement pour faire tourner du 32 bits sur mon amd64, mais également pour l’isolation que ça fournit. Enfin, j’en suis pas encore là pour le moment, j’ai encore plein de trucs à réinstaller avant.

Je regarderai le sujet à propos de sudo demain, il commence à se faire tard et je vais plutôt aller dormir dans l’immédiat.

#9

Sudo, bien géré, ce n’est pas mal du tout. :slightly_smiling:

#10

Il y a des applications graphiques qui doivent être lancées en root, par exemple ethereal devenu wireshark.

Pour autoriser root à lancer une application graphique, il y a plusieurs moyens

  1. sux, ksu et autre kdsu (je ne connais pas)
  2. un simple ssh -X root@localhost (tordu)
  3. Faire après un su

cd /root ; ln -s /home/votrelogin/.Xauthority

puis commande (en su donc).
On peut aussi jouer avec xauth si on arrive à comprendre le bazar.

CE QUI SUIT POSE DES PBMS

  1. Autoriser la connexion au serveur X via xhost, et faire un export DISPLAY
    (cela fragilise le controle d’accès au serveur X)
  2. Autoriser la connexion de root sous X (cf gdm et kdm)

Quels sont les pbms des applications graphiques en root:

  • Les applications graphiques simplifient la vie mais rendent une catastrophe possible en un clic de souris. Une ligne de commande nécessite de se poser la question de toutes les options et est beaucoup plus précises. Rq: pour cette raison, je n’utilise pas non plus mc sous root.
  • X est un logiciel client serveur, potentiellement toutes les commandes peuvent être interceptées. C’est pour cette raison que le nolisten tcp est activé par défaut, seul les douilles Unix (comprendre locales) sont actives dans ce cas et il n’y a pas lieu de craindre un intervenant extérieur. Sinon, les commandes root peuvent être éventuellement interceptées.
    Sur une machine non connectée, ce point n’existe pas
  • Lancer un serveur X sous root lance une floppée de programmes qui sont autant de problèmes potentiels: il faut penser à l’économiseur d’écran, etc. La sécurité d’Unix repose sur le fait qu’il est -contrairement à Windows- il est à la base prévu multiutilisateurs et donc l’utilisateur de base n’a aucun droit. Lancer une session X root enlève toute barrière de ce coté, tous les codes, scripts, etc sont éxécutés en root ce qui est la promesse à terme d’une catastrophe. Un rm -Rf / en root n’a pas les mêmes conséquences que la même commande sous un utilisateur standard. Le principe des virus sous Windows consiste à supposer que l’utilisateur a tous les droits ce qui est fréquemment le cas. Un sudo permanent sans mot de passe revient quasi au même.
    À noter que cette erreur est la même que celle consistant à faire tourner un serveur CS sous root, etc.

Maintenant il ne faut pas diaboliser non plus, la machine n’explose pas si on fait une session root, simplement c’est comme la vitesse au volant, c’est le jour où il y a un grave pbm qu’on s’aperçoit la gravité de son erreur.

#11

Merci beaucoup pour ces explications très claires, fran.b.
Juste quelques petites précisions (certaines que j’apporte, d’autres pour voir si j’ai bien compris)…

[quote=“fran.b”]Pour autoriser root à lancer une application graphique, il y a plusieurs moyens

  1. sux, ksu et autre kdsu (je ne connais pas)
  2. un simple ssh -X root@localhost (tordu)
  3. Faire après un su

cd /root ; ln -s /home/votrelogin/.Xauthority

puis commande (en su donc).
On peut aussi jouer avec xauth si on arrive à comprendre le bazar.[/quote]Concernant sux et le forwarding X d’une session utilisateur à une session root : un petit tour dans le manuel de sux a été très instructif, il y est expliqué (grosso modo) que la technique de faire un lien vers le .Xauthority de l’utilisateur peut poser de gros problèmes : selon les actions qu’effectue root par la suite, le fichier peut être chowné/chmodé par root et l’utilisateur se retrouve sans accès à ce fichier, et donc au serveur X. C’est l’option « --use-xauthority » de sux, à utiliser avec précautions donc.
Au contraire, l’option par défaut « --copy-cookies » utilise xauth pour faire une copie en bonne et due forme du .Xauthority, ce qui évite ce type de problèmes.
Ma conclusion sur ce point étant qu’il vaut donc mieux faire confiance à des outils comme sux / gksu / kdesu plutôt que d’essayer de trafiquer une solution qui risque fort de poser souci (il n’y a qu’à voir la relative complexité de sux pour s’en convaincre).

[quote=“fran.b”]* X est un logiciel client serveur, potentiellement toutes les commandes peuvent être interceptées. C’est pour cette raison que le nolisten tcp est activé par défaut, seul les douilles Unix (comprendre locales) sont actives dans ce cas et il n’y a pas lieu de craindre un intervenant extérieur. Sinon, les commandes root peuvent être éventuellement interceptées.
Sur une machine non connectée, ce point n’existe pas[/quote]Ceci éclaircit pour moi la précédente remarque de ggoodluck47. Si je ne me trompe pas : une socket locale, une fois connectée, ne peut pas être interceptée par qui que ce soit (extérieur ou local), à part peut-être root lui-même (mais dans ce cas on aurait des soucis plus importants que la sécurisation de X) ?

[quote=“fran.b”]* Lancer un serveur X sous root lance une floppée de programmes qui sont autant de problèmes potentiels: il faut penser à l’économiseur d’écran, etc. La sécurité d’Unix repose sur le fait qu’il est -contrairement à Windows- il est à la base prévu multiutilisateurs et donc l’utilisateur de base n’a aucun droit. Lancer une session X root enlève toute barrière de ce coté, tous les codes, scripts, etc sont éxécutés en root ce qui est la promesse à terme d’une catastrophe. Un rm -Rf / en root n’a pas les mêmes conséquences que la même commande sous un utilisateur standard. Le principe des virus sous Windows consiste à supposer que l’utilisateur a tous les droits ce qui est fréquemment le cas. Un sudo permanent sans mot de passe revient quasi au même.
À noter que cette erreur est la même que celle consistant à faire tourner un serveur CS sous root, etc.[/quote]On est bien d’accord que là tu parles d’une session graphique complète lancée par root, et non plus d’un seul programme ayant les droits root ?

En conclusion (dites moi si je me trompe) :

  1. on est tous d’accord qu’une application “graphique” (que ce soit sous X ou sous ncurses) permet de faire des erreurs d’inattention beaucoup plus facilement qu’une ligne de commande.

Digression : que pensez-vous d’aptitude en interactif ? Ça aurait tendance à être classé comme “application graphique” (donc à éviter), mais franchement je me sens beaucoup plus à l’aise avec ça qu’avec la ligne de commande, ça m’a permis jusqu’à présent d’éviter de très nombreux problèmes face à des soucis de dépendances.

  1. dans une configuration desktop de base, les conséquences d’une unique application X lancée en root ne vont généralement pas plus loin que (1), dans la mesure où l’application en question effectue des tâches relativement simples et n’est pas critique en soi (exemples typiques : éditeur de texte, configuration réseau, …). À contrario, éviter à tout prix de lancer en root des usines à gaz de type navigateur web ! (ça me paraît être du bon sens, mais j’imagine qu’il y en a qui ne s’en privent pas…)

Dernier petit point : j’ai remarqué un souci dans mon T&A : un nouveau dbus-daemon est lancé à chaque connexion de root, et ne s’arrête jamais de lui-même. Je vais voir dans quelle mesure on peut l’arrêter à la fin de la session root (chaque session root serait alors isolée des autres au niveau du DBus), ou bien si ce n’est pas possible, comment réutiliser un dbus-daemon pré-existant pour root (toutes les sessions root partageraient alors le même DBus, mais resteraient isolées des DBus des utilisateurs).

#12

Re,

Je ne parle pas des fausses manœuvres mais des millions de micro-secondes où tu restes en root entre deux commandes et pendant lesquelles un malveillant peut exploiter cette brèche !

Et si tu es un adepte de aptitude parce qu’il t’évite des problèmes de dépendances il t’éviterait les mêmes en ligne de commande :slightly_smiling: Mais dans un cas tu restes à contempler ton écran root et moi je suis redevenu user avec sudo :slightly_smiling:

Comme il n’y a pas plus sourd que celui qui ne veut pas entendre j’arrète là ma participation au débat :slightly_smiling:

#13

[quote=“syam”]Digression : que pensez-vous d’aptitude en interactif ? Ça aurait tendance à être classé comme “application graphique” (donc à éviter), mais franchement je me sens beaucoup plus à l’aise avec ça qu’avec la ligne de commande, ça m’a permis jusqu’à présent d’éviter de très nombreux problèmes face à des soucis de dépendances.[/quote]Aptitude te demande confirmation par défaut avant d’éxecuter quoi que ce soit, les risques me semblent limités.

#14

[quote=“ggoodluck47”]Comme il n’y a pas plus sourd que celui qui ne veut pas entendre j’arrète là ma participation au débat :slightly_smiling:[/quote]Au contraire, continue ! Tes interventions m’ont appris des choses (et sûrement aussi à d’autres lecteurs qui n’ont pas forcément participé à la discussion), ça serait dommage d’arrêter là. :smt006

Le problème n’est pas que « je ne veuille pas entendre », mais tient à mon caractère : tant que je ne comprends pas quelque chose correctement, je préfère continuer à utiliser des concepts que je maîtrise (ou crois maîtriser, dans ce cas).
Ce qui ne m’empêche pas de chercher à comprendre tous les tenants et aboutissants (ce que je suis en train de faire) en vue de sauter le pas.
Et comme on dit : je comprends vite mais faut m’expliquer longtemps… :blush:

Je pense que tu seras d’accord avec moi que si je change radicalement de manière de procéder avant d’avoir compris de quoi il retournait, je m’expose à plus de problèmes que ça n’en résoudrait.
Un exemple serait la sécurisation de sudo : je n’ai pour le moment aucune idée de comment faire, et n’ai pas encore eu le temps de lire le sujet en question. Sudo, tel qu’implémenté par (k)ubuntu, est une des (nombreuses) raisons pour lesquelles à l’époque j’ai migré vers Debian : je ne me sentais pas du tout en confiance avec ce système qui retenait mon mot de passe, et qui au final m’apparaissait plus comme un trou de sécurité qu’une réelle protection.

Bref, je me vois mal changer de pratiques sans savoir auparavant où je mets les pieds, le remède serait probablement pire que le mal.
Autrement dit, c’est plus de la prudence que de la mauvaise volonté. :wink:

Edit : je viens de lire le sujet original où les faiblesses de sudo sont expliquées (–with-tty-tickets et timestamp_timeout), ça m’a permis de comprendre les raisons de ce comportement aberrant. Prochaine étape : lire l’autre sujet.

#15

Ben la meilleures sécurisation de sudo que je connaisse, c’est le “temps d’ouverture zéro”.

#16

Je suppose que tu as parcouru ce fil :
http://forum.debian-fr.org/viewtopic.php?p=257944#p257944

#17

[quote=“ricardo”]Je suppose que tu as parcouru ce fil :
http://forum.debian-fr.org/viewtopic.php?p=257944#p257944[/quote]
Tout à fait. Je ne connaissais pas l’astuce du TMOUT (ni, au passage, la commande readonly), pour le reste je savais déjà mais ça ne peut pas faire de mal de le rappeler. :slightly_smiling:

Sinon, pour info, j’ai modifié mon T&A avec une solution qui est correcte, ce coup-ci (et les explications qui vont avec).

#18

J’y vais de ce pas :smt003

#19

Juste en lisant ce fil je me suis rappellé d’une « astuce » interessante. Elle consiste simplement à ajouter dans ~/.bash_logout du compte root :

Bien sur il faut le mettre dans ~/.zlogout. Ça sert si vous utilisez les TTY.

#20

Pour infos reset est aussi une commande pouvant être utilisée pour réinitialiser son terminal lorsque l’on ne veux vraiment plus rien clear ne fait que décaler les informations