Obsidian a écrit 5299 commentaires

Cet exemple n'est pas probant. Je ne trouve pas inconcevable que le fait d'ouvrir un outil qui requiert les droits "root" et donc, te demande une première fois ton mot de passe via gksudo, permette ensuite, dans le délai imparti par sudo, d'en ouvrir une autre qui les requiert également, sans te demander à nouveau le mot de passe. La session X11 est vue comme un seul et même tty. Dans une console, ce comportement est strictement le même. Le délai de grâce de sudo permet justement de taper systématiquement le mot de passe quand on tape plusieurs commandes.

Justement, cette facilité se justifie en ligne de commande car l'utilisateur précise explicitement sudo à chaque fois mais surtout parce que l'administration en ligne de commande consiste généralement en une floppée de commandes successives, toutes éphémères.

S'il fallait que je saisisse mon mot de passe à chaque fois que j'utilise un outil graphique lié à l'administration dans un délai inférieur à 5 minutes, ce serait très lourd et on tomberait dans le second cas que tu décries comme "Mauvais".

C'est là que nos opinions diffèrent. Toutes ces applications sont persistantes, elles effectuent en général toutes les opérations demandées en une fois à la validation, et peuvent être beaucoup facilement lancées en parallèle par l'utilisateur de base. Étant donné qu'en outre, cela ne concerne qu'au plus une quinzaine d'applications, un délai de grâce ne se justifie absolument pas dans ce genre d'environnement.

D'autre part - et c'est son intérêt principal - un clicodrôme propose des options à l'utilisateur à l'inverse d'une ligne de commande à laquelle on doit les passer explicitement (et sans se tromper dans l'orthographe). Si l'on tient compte en plus de fait que bon nombre de foyers (auxquels Ubuntu se destine) utilisent un compte familial, il devient très simple de lancer une application censée être privilégiée comme n'importe quelle autre application du menu.

Il faut donc que :
- le processus ne soit pas rattaché à une console ;

C'est automatiquement le cas de toutes les applications lancées à partir du bureau graphique et non d'une ligne de commande. Et sans cela, il suffit à un processus de faire un setsid() ou un ioctl() avec TIOCNOTTY pour se détacher de sa console.

- l'uid du processus fasse partie du groupe admin ;

C'est forcément le cas aussi puisque tous les programmes sont lancés sous ton identité.

- que le mot de passe d'un utilisateur du groupe ait été tapé il y a moins de 5 minutes auparavant.
Cela fait quand même pas mal de conditions à retenir.

Non, il suffit de se mettre en attente et de surveiller l'exécution de gksudo, puis de voir si le même PID sous la même identité (root) correspond à un autre exécutable (suite d'un execve) pour savoir qu'un sudo a réussi et donc que le timestamp est valide pour 5 minutes. Si tu balances la commande à ce moment-là, elle sera toujours associée dans le log avec la précédente. Si tant est, bien sûr, que l'utilisateur lamdba lise le log.

En créant plaçant un sgid sur l'ensemble du système de fichier ?

Encore une drôle d'idée ...

sur l'exécutable d'aptitude ? Mais dans ce cas, si le compte de l'utilisateur est compromis, plus besoin de se farcir les failles locales pour escalader les privilèges...

Non, car au moins, seule cette commande pourra être exécutée ! Ça fait quand même toute la différence !

Un sudo même sans délai de grâce permet par défaut de lancer n'importe quelle commande !

Réduire le champ d'action obligatoire de root ne fera pas disparaître la menace d'intégrité du système pour autant.

Encore une fois, il ne faut pas confondre l'utilisation de sudo et le passage vers root. Dans le cas du serveur FTP, tout l'administration peut être faite sous l'identité d'un pseudo-user, et c'est l'identité de celui-ci qu'il faut prendre, pas celle de root.

Il est important de remarquer que, d'une part, le fichier /etc/sudoers permet de spécifier une liste de commande explicitement autorisées, et également de choisir une identité autre que root.

Il est de fait qu'Ubuntu n'exploite pas du tout ces possibilités, pas plus que la plupart des distributions. Le premier utilisateur fraîchement déclaré a donc la possibilité de passer root et de faire n'importe quoi, même lorsqu'il débute sur le système. Et c'est pour moi une grave faille de sécurité.

Là où j'attends un peu plus que des « on-devrait-faire-comme-ça », c'est par rapport à X.org, sujet technique que je maîtrise mal en profondeur. Démonstration de ce que tu avances (c'est sans doute vrai)

Si tu parles du délai de grâce, c'est facile à vérifier. sudo flanque ses timestamps dans /var/run/sudo/loginduuser (problablement avec un touch ou assimilé). Il y crée une entrée qui porte le nom du tty depuis lequel la commande a été lancée, pour que ce délai n'affecte que la console de travail de l'utilisateur et pas une autre. Si tu lances l'affaire depuis X-Window (mais pas depuis un Xterm, rattaché, lui, à un /dev/pts/*), il n'y a pas de console et le timestamp s'applique sur unknown. Moralité : tous les processus qui ne sont pas ou plus rattachés à une console peuvent en profiter.

Si tu veux faire le test, colle l'applet de lancement d'applis en ligne de commande dans ton tableau de bord Gnome, ouvre une des applications du menu Administration d'Ubuntu avec ton mot de passe habituel, puis lance gksudo depuis l'applet avec la commande de ton choix.

et que préconises-tu pour y pallier ?

Configurer gksudo via le fichier /etc/sudoers pour qu'il n'accorde pas de délai de grâce aux processus sans tty. Autant ça se justifie parfaitement en ligne de commande quand on fait de l'administration, autant le recours aux applis du menu d'administration est occasionnel et ne justifie pas une telle facilité, surtout si c'est à l'insu de l'utilisateur.

Ce que je préconise surtout, c'est une vraie réflexion sur le sujet, et c'est ce que l'on a commencé à faire dans les discussions indiquées :

- Ouvrir une session root pour tout faire = Mauvais;
- Taper son mot de passe à tout bout de champ = Mauvais.

Je pense qu'il faut donc recourir le moins souvent à root et faire en sorte que la plupart des opérations soient réversibles.

Je ne pense pas que tu aies réellement pris le soin de lire ce qu'il a derrière les liens que j'ai posté mais bon. Cela n'a pas beaucoup d'importance. Je crois surtout que la majorité des applications n'ont pas forcément besoin d'être lancées sous root plutôt que sous un pseudo-utilisateur lambda. Le meilleur exemple, même en setuid, est celui de la commande passwd : Elle est historiquement setuidée root et ce depuis l'aube de l'histoire d'UNIX, alors qu'elle se contente de modifier un fichier texte (/etc/password). Même avec l'apparition de PAM, un setgid suffirait, avec un groupe dédié qui n'a pas besoin d'être celui de root.

Pour obtenir un outil équivalent à synaptic en console, il faut lancer aptitude avec son interface ncurses, donc tant que tu n'as pas fini, l'application aura les privilèges de root. Donc, tu n'aimes pas simplement gksudo (plutôt que sudo) mais carrément l'idée qu'on puisse offrir des outils d'administration via des clients X11. Que proposes-tu à la place ?

Une application X ne devrait jamais avoir besoin d'être exécutée sous le compte root ! Pas plus qu'aptitude d'ailleurs. La promotion au compte n°0 ne devrait avoir lieu qu'au moment d'appliquer les modifications réclamées. Apache, par exemple, fait cela proprement en gardant un seul processus root initial et en gardant ses threads sous sa propre identité.

Mieux : dans le cas de proftpd cité en exemple, le gars voulait carrément virer le mot de passe du superchef, comme il dit, alors qu'en creusant un peu, on s'aperçoit qu'aucun composant (depuis le serveur jusqu'à l'interface de configuration) n'a réellement besoin d'être root ou de lui appartenir.

Ubuntu n'est certainement pas encore parfaite mais, par rapport aux autres distributions, c'est la seule qui propose l'usage de sudo (et gksudo) par défaut ce qui permet d'utiliser des interfaces graphiques sans nécessiter de taper un mot de passe root que les débutants auraient tôt fait d'y mettre la même chose que pour leur utilisateur. On touche là finalement un problème humain plutôt que technique. La réponse ne peut donc être simplement technique.

Soit, grosso-modo, ce que j'expliquais dans mon précédent post.


L'une des choses qui me dérangent le plus actuellement, c'est la conservation du délai de grâce par gksudo. Sudo gère déjà cela mais au moins, l'utilisateur doit taper explicitement la commande, ce qui implique à priori qu'il sait de quoi il s'agit, mais surtout, cette période est accordée uniquement à la console de travail. Depuis X, le lock est créé en tant que unknown, ce qui signifie que gksudo peut ensuite être lancé de façon transparente et silencieuse non seulement depuis l'environnement X, mais également depuis n'importe quel processus qui aurait daemonisé et se serait détaché de sa console.

Tu préfères que l'utilisateur se connecte tout le temps en root ou dispose d'un terminal root en permanence ?

Honnêtement, c'est quand même une drôle d'idée ...

Ce qui est inquiétant, c'est que le fait même que tu considères cette option comme seule solution de substitution, ça laisse quand même songeur. Il n'y pas que root sous Unix ... C'est de cette manière que l'on arrive à des horreurs de ce style :

https://linuxfr.org/forums/15/22562.html

Concernant sudo, on a déjà eu l'occasion d'en discuter ici :

https://linuxfr.org/comments/801182.html#801182
https://linuxfr.org/comments/839682.html#839682

En l'occurence, que Ubuntu s'appuie sur sudo plutôt que sur un truc à eux pour gagner des privilèges, c'est plutôt une bonne chose. Par contre, avoir à switcher systématiquement vers root chaque fois que l'on ouvre quelque chose dans le menu d'administration sous X-Window, ça me pose problème pour trois raisons :

1) L'utilisateur prend l'habitude de saisir son mot de passe pour un oui ou pour un non, et ça devient dangereux.
2) Il suffit de mettre un client graphique à l'écoute des événements pour intercepter ce mot de passe !
3) Au contraire de la majorité des outils en ligne de commande qui effectuent immédiatement l'opération demandée et ressortent, une application X (et GNOME à plus forte raison encore), est persistante dans l'environnement, et accapare et influe sur de nombreuses ressources connexes.

... et ses sudo graphiques à tout bout de champ ! :-) (je suis pourtant et malgré cela un utilisateur d'Ubuntu ...).

J'imagine qu'à partir du moment où le fichier est contigü sur le disque et de taille fixe, le filesystem sous-jacent, on s'en tape un peu ...

T'inquiète, pour la majorité des forums, tu écris encore trop bien. Pour la plupart des gens, ce niveau de français est devenu la norme (et de là à ce qu'elle soit avalidée par l'ISO en fast-track, il n'y a qu'un pas, à mon avis ...).

cat /dev/random | telnet 192.168.0.1 135

... ça devrait déjà suffire à mettre le souk, je crois.

Si c'est en sortie, tu peux faire :



#include <stdio.h>
#include <string.h>

int main (void)
{
char buffer[256];

const char * valeur1 = "Bonjour";
const char * valeur2 = "tout";
const char * valeur3 = "le monde";
const char * valeur4 = "!";

memset (buffer,' ',256);
strcpy (buffer+ 50,valeur1);
strcpy (buffer+100,valeur2);
strcpy (buffer+150,valeur3);
strcpy (buffer+200,valeur4);

buffer [strlen(valeur4)+200] = '\0';

puts (buffer);

return 0;
}

Verboten de verrouiller les ports réseau pour créer des locks !

D'abord, ce sont des ressources qui n'ont rien à voir et qui sont beaucoup plus limitées qu'un fichier dans /var/lock. Ensuite, c'est faire l'hypothèse que l'application tourne dans un environnement mono-utilisateur et tout le monde sait bien que ce n'est pas le cas d'UNIX.

Au boulot, on utilise des serveurs centralisés accessibles avec des Thin Clients. Aussi bien sous Windows que sous Linux, d'ailleurs, malgré les sessions utilisateur multiples et distinctes, seul le premier venu peut lancer certaines applis propriétaires parce que le coder a travaillé comme un cochon, et comme l'application se contente généralement d'examiner le port indépendamment de l'adresse à laquelle il est associé, on se retrouve généralement avec une machine qui a un port ouvert sur le réseau en permanence, pour rien.

La manière normale de le faire, c'est effectivement la création d'un fichier dans /var/lock avec l'identifiant unique de l'application et son PID, de façon à pouvoir la contacter pour voir si elle existe toujours. Dans le même esprit, un socket UNIX, et pas IP, pour lui causer directement.

Et dans tout les cas, un ramasse-miette pour faire le ménage derrière.

N'empêche que tout doucement, ça se perd, les gens qui ont codé sur Atari ST ... l'autre jour, j'ai eu un gamin très sympathique de 14 ans, au collège, en troisième, qui est venu visiter notre entreprise. Eh bien il ne savait pas ce qu'était un Minitel.

Le temps passe ...

Depuis que FireFox intègre un correcteur d'orthographe mes messages s'améliores [1] mais intègres quelques perles savoureuses comme celle-ci.

Effectivement ! :-)

Y a Laura du Web ...

Atteindre 10 est sans intérêts. Le but du système de vote est de cacher les commentaires inutiles et de mettre en valeurs les commentaires digne d'intérêts. Pour le moment cela ne se fait que sur la différence entre les votes positifs, le karma et les votes negatifs.

C'est justement parce que le système de vote - en lui même - fonctionne très bien. On l'utilise depuis 219 ans dans notre pays et il a largement fait ses preuves. Ici, tout le monde donne son avis sur un commentaire et c'est très bien comme çà. Lorsque quinze personnes qui le trouvent nul, c'est en général parce qu'il l'est.

Par conséquent, et après bientôt six ans (1) d'utilisation du système, j'affirme que le distingo pertinent-inutle est un faux problème. La vérité est qu'il n'y a tout simplement pas de commentaire réellement inutile sur DLFP : je n'y ai jamais vu de spam, ni même de commentaire hors-sujet, et il n'y a pratiquement plus " d'épicommentaires", si j'ose dire, tels que "oui", "c'est bien vrai", etc. précisement parce que les gens plussoient ou moinssoient à la place ! Pratiquement personne ne change le seuil d'affichage par défaut et pour cause : les seules choses qui soient réellement noyées sous la barre du zéro sont celles qui méritent de l'être : les trolls, en majorité, et les informations manifestement fausses au point d'être dangereuses (commandes shell).

Je constate également que les utilisateurs plussoient bel et bien un commentaire qui apporte quelque chose à la discussion même lorsqu'ils ne sont pas d'accord, pourvu que celui-ci soit rédigé correctement, et ce bien avant que l'on ait remplacé [+/-] par pertinent/inutile. Même pasBill pasGates se prend des 10 lorsqu'il se fait l'avocat du diable mais que ses arguments sont imparables.

En revanche, le comportement des gens a changé du jour au lendemain avec le système de vote. Le système de carottes et bâtons ainsi mis en place a poussé les gens à écrire des posts susceptibles d'être populaires. Et même si ça polémique toujours, cela n'a plus rien à voir avec ce que l'on peut trouver sur slashdot.

Bref. Ce système de vote est très bien comme il est, il ne faut pas y toucher.

Par contre, quelque chose qui manque réellement désormais (et qui a été retiré délibérément), c'est le nombre de vote par commentaire. C'est une info extrêmement importante : un commentaire qui fait 1/#3 est un commentaire qui vient d'être posté, qui manque de visibilité ou qui n'intéresse personne. Un commentaire qui fait 1/#100 est un commentaire qui divise l'opinion. Et ça, pour le coup, c'est vraiment idiot de l'avoir masqué.

1) http://linuxfr.org/2001/09/02/4752.html

Jetez quand même un oeil à

$ man 2 flock

et aux Mandatory Locks Linux en particulier dans

locks.txt and mandatory.txt in /usr/src/linux/Documentation.

Il est plussé, et il arrive à +10. Plus personne ne le plusse, il est déja à +10, donc ça sert à rien. Ensuite arrive un mec qui trouve ça pas pertinent et le moinsse. Il arrive à +9.

Ce qui donne donc l'occasion à tes fans, ceux qui sont arrivés trop tard la première fois, de te plusser enfin. \o/

Tu peux commencer avec Lea-Linux :

http://lea-linux.org/cached/index/Accueil.html

... mais il est vrai qu'il n'y a pas vraiment de point de départ ni d'itinéraire fléché.

Par contre, il est fondamental de retenir dès le départ que ce n'est pas du tout le même système. Tu peux considérer dans un premier temps que tu passes du PC au Mac. Autrement, tu risques de t'appuyer sur tes habitudes Windows pour retrouver tes repères. C'est une très mauvaise idée parce qu'avec le temps, on a fini par développer des environnements de bureau qui y ressemblent pour ne pas dépayser l'utilisateur, mais ils ne sont pas faits pour être efficaces dans ce cas d'utilisation. Au final, tu auras l'impression d'avoir un Windows light et tu seras passé à coté de toute la puissance du système.

Tu rencontreras probablement quelques difficultés au démarrage (tel pilote qui ne vient pas tout seul, etc.). C'est un peu comme si tu avais toujours vécu à l'hôtel et que l'on te livre une maison neuve : tu pourras y passer les 30 prochaines années mais il y a toujours un peu de finitions à faire en emménageant. :-) Le tout, c'est donc de ne pas abandonner à la première difficulté.

Force-toi si tu peux à faire de la ligne de commande. La vraie force du système y réside.

Bon courage.

Déjà, ton problème n'est pas clair du tout, je considère donc que tu cherches à monter un volume sur un point de montage dont le nom contient un espace.

La forme octale n'est qu'une façon alternative de représenter un même caractère, en général quand celui-ci n'est pas affichable. Cela n'a rien à voir avec l'éditeur de texte lui-même, ni avec les caractères de substitution comme le nbsp; du HTML et qui est représenté par une valeur différente. si tu tapes dans un bash les commandes echo -e "\040" et echo -e " ", tu obtiendras exactement le même caractère. Mais c'est echo qui gère ce format, pas le shell.

Donc, de la même façon, il faut que mount interprète le fichier fstab de la même façon. Et il le fait :

/dev/hda15 mon\040point\040de\040montage auto defaults 0 0

Tu écris tout simplement ton caractère sous forme octale échapée habituelle : en commençant par un slash.

C'est simple.

Ca devrait être simple, tu veux dire ! Et dans ce cas de figure, ils vont reprendre la machine en entier.

De toutes façons, on ne devrait pas avoir besoin de refuser un CLUF pour se faire rembourser, parce que Microsoft a prévu une clause stipulant qu'on doit se faire rembourser intégralement en cas de désaccord. C'est quand même le droit le plus fondamental d'un consommateur de ne pas souhaiter acheter !

Je comprend mieux les insinuations

Exprimées en radians, j'espère ... /o\

(Je sors).

C'est pourtant vrai et j'ai passé la soirée devant sans même le remarquer ! Merci pour la remarque.

Alors, je considère que tu accèdes à Internet par le réseau (ADSL ou réseau local) et qu'il n'y a qu'une seule carte réseau dans ta machine.

Il existe visiblement deux pilotes pour les cartes Realtek, que Linux reconnaît parfaitement depuis des lustres : 8139cp et 8139too.

Essaie d'ouvrir un terminal et d'entrer les commandes suivantes :

$ sudo rmmod 8139too (suivi de ton mot de passe)
$ sudo rmmod 8139cp
$ ifconfig eth0

Ensuite, essaie en permutant les deux premières lignes. Soit tu obtiens le détail de ton interface, soit tu auras un "device not found".

Elle doit le faire parce que l'exécutable renvoit un code d'erreur au système, mais ce ne doit pas l'empêcher de compiler. D'ailleurs, cela ne l'empêche pas. C'est le linker qui se plaint, linker qu'il va chercher dans /usr/local/bin pour une raison inconnue. Si dubis ne l'a pas compilé exprès, ou s'il ne se souvient pas avoir téléchargé un package particulier, je pencherais pour un rootkit ...

C'est vraiment bizarre, ce truc.

/usr/local/bin/ld

Est-ce que tu utilises une version locale perso de ld ? Que donnent les commandes suivantes ?

$ which gcc
$ which ld
$ /usr/local/bin/ld -v

Quelle distribution utilises-tu ?

Je plussoie. Maintenant que tu as ouvert un fil dans la bonne catégorie (programmation), pas la peine d'initier un autre fil.

Pose directement ta question et dis-nous ce qui te bloque.