Reprise du message précédent :

Tu pourrais nous faire le plaisir de lire la discussion depuis le début, ou au moins de la comprendre, car je t'assure que tu te trompes sur mes intentions. (à force là ...)

c'est toujours moins emmerdant que de devoir rentrer son mot de passe à chaque fois comme sous debian par défaut. Même si on peut le changer, mais on s'en fou je parle de debian pour qu'un s'y retrouve dans les différent choix de configs possible de sudo

Si il demandait le mot de passe ça changerait quoi ?
La seule différence avec la config style debian c'est qu'il demande de cliquer sur oui ou non plutot que de rentrer un mot de passe.
Si t'as un trojan qui controle ta souris pour cliquer sur l'icone ou loguer ton mot de passe avec un key logueur je pense que sous linux ou windows c'est foutu
Oui ça serait un peu plus simple avec un click, mais c'est un choix différent dans la palette de possibilités.

C'est justement ce qu'il veut éviter, en assouplissant un peu le système (cad demander une fois le password, et simplement cliquer sur Oui par la suite)
Quant à Vista, c'est pareil, il demande à chaque fois le password... sauf si t'as des droits admin où il se contente d'un oui/non. Enfin, c'est ce qui m'est arrivé la dernière fois où j'ai utilisé cet OS (ça devait être avec CPUZ, qui utilise un driver en ring0 me semble-t-il).

j ai un probleme avec cette 7.10 (pas de prob avec la 7.04)
 
a l installation  
 
l etape demarrage de l outil de partitionnement reste bloqué a 53% examen des disques..
 
config pentium p4 cf mes configuration    install sur le western d ou maxtor idem  
 
pas de prob avec la 7.04  
 
je precise que l isntall de la 7.10 marche tres bien sur ma config core 2 duo  

Là encore tu comprends ce que je dis à l'envers, car tu te trompes sur mes intentions.

Ouep mais comme il l'a dit plus haut je vois pas comment tu peux coder quelque chose de sécurisé nécéssécitant uniquement une réponse oui non

Détaille, je vois pas. Tu me fais un procès d'intention?

Je comprends pas là, faut passer son temps à faire des manipulations au niveau système Dans ce cas, autant opter pour deux modes de sudo, l'un sans passwd et l'autre avec, pour les commandes plus rares...

La question ne concernait nullement la présence ou non de mot de passe, mais bien d'ergonomie. Tu voulais un système simili vista, tu vois bien qu'il n'est pas convenable non plus.

La différence, c'est qu'un programme quelconque peut prendre ta session et executer des commandes en temps qu'admin sous ton compte, dans l'autre, non (vu qu'il n'a pas le mot de passe...).

Mais c'est vrai que sous ouin ouin, les soucis d'authentification, on s'assied un peu dessus.

Oui, sauf que sous unix, la première fois, ni le simulateur de clic ni le key logger n'ont le mot de passe. Donc ton spyware, dans un cas, pour avoir les droits d'admin il peut se rassoir, dans l'autre, il lui suffit de simuler un clic ou une key press. C'est autrement plus simple que de connaitre le passwd non?

Même joueur, joue encore. Sudo redemande le mot de passe pour éviter justement cela, afin que quiconque ou n'importe quel process puisse usurper un compte root trop facilement.

Vous passez votre temps en commande système ou quoi

Et bien explique clairement tes "intentions"... Parce que pour l'instant d'après ce que j'ai compris tu veux un système qui te demande une fois ton password, et qu'apres tu actives/désactives tes droits root via unsystème oui/non.

A ma connaissance, je ne connais rien sous ubuntu, debian ou autre qui réponde a ca. regarde gksu mais je pense pas.

Je rejoins Gf4x3443 sur tout ce qu'il a dit, et je ne vois pas en quoi il est HS par rapport a ce que je viens de décrire. Alors si tu pouvais répéter clairement ce que tu veux et pourquoi...

Toujours est il que :
 pour des taches de maintenances/administration on s'ouvre un shell en root on fait ce qu'on a faire, et on le ferme (enfin moi je fais ca). Sudo peut régler le probleme tu rentre une fois ton mot de passe, tu préfixes tes commandes via sudo quand tu le souhaites et basta. Ceci pendant un temps donné.

Apres avec sudo tu peux créer des groupes de commandes avec password ou non. sudo est quand meme pas mal configurable...

Je ne vois pas l'utilité d'un système qui fait oui/non (deja d'un point de vue utilisation ca reste identique a yes/no, ton passowrd il fait 50 caractères ?). Tu n'utilises pas sudo toutes les 20 minutes. Si c'est ca ben penses à revoir tes usages par rapports à ca.

Donne nous exactement les cas d'usage que tu veux et apres on pourra peut etre t'aider.

T'aurais peur qu'un "malware" clic tout seul sur le bouton Oui ?
Et puis on est pas tous à rechercher la sécurité à l'extreme. Demander une 1ère fois le password et ensuite simplement une confirmation, ça n'a rien d'incroyablement peu sécurisé. En tout cas, c'est bien mieux que de laisser une "liberté totale" pendant 15min
A chacun de choisir le compromis sécurité&contraintes en fonction de l'utilisateur et du niveau de sécurité recherché
M'étonnerait pas que certains se connectent en root ou choisissent un password d'un seul caractère à cause de ça :

Ou alors tu fais su ==> tu passes en root et tu n'as plus qu'a faire toute tes commandes en ayant tapé qu'une seule fois le password.
C'est ce que je fais.
Mais comme ils l'ont tous répété, un système oui non n'est pas sécurisé

Simulé un clic oui c'est réalisable, comment tu crois que sont les fait les logiciels de test en programmation? Ils simulent un clic sur tel bouton, tel champ rempli avec tel truc etc. Et perso moi OpenSuse me le demande à chaque action le password, ça ne me dérange vraiment pas vu la vitesse de frappe
Et comme dit précédemment si j'ai beaucoup de commande, un coup de su et op ça roule.

 
C'est que je te reproche de me faire justement !!!!
 

 
Avec juste un choix oui/non ça suffira
 

 
Pouvoir faire oui/non c'est juste une possibilité en plus, et à la limite là façon de l'intégrer dépend de son intégration avec les autres options.
Ca peut même rendre les choses plus sures par exemple lors du laps de temps de 15 minutes de sudo ou aucun mot de passe n'est nécéssaire, on peut justement sortir ce choix oui/non, c'est toujours plus sur que sudo sans mot de passe, et moins chiant que de devoir rentrer un mot de passe à chaque fois.
 
L'idée de la popup oui non n'est pas plus ou moins sécurisée, ça dépend juste de ce que t'en fait.
 

 
oui, mais ça reste moins simple qu'un script lancé avec sudo sous unix pendant la période ou le password n'est pas nécéssaire.

Le processus "bloqué" serait capable de simuler le clic sur 'Oui' ?
Toute façon, si t'as un malware sur ta machine vaut p'tet mieux éviter de taper ton password. Toute façon les malwares sous Linux, ça n'existe pas

Moi aussi ça me gave de saisir souvent mon password. Vivement que Gutsy se stabilise afin que je passe moins de temps en "commande systèmes"

De toute façon que ça soit password ou clic yes no, c'est pareil, suffit juste qu'un virus ouvre une action system avec la fenêtre system pour enregistrer le mot de pass et paf, (genre la fenêtre qui s'ouvre avec une action courrante genre demander le mot de pass du trousseau de clef) . Donc c'est vrais qu'au final... Mais je n'ai jamais vu faire ça. Mais le processus ne sera pas bloqué forcément, suffit qu'il tourne en parallèle et il pourra simuler un oui. Je vois pas en quoi il est bloqué.
En gros la différence, c'est qu'avec le password la toute première fois il ne peut rien faire, si c'est oui non, il peut simuler un clic du oui.

L'option noexec est ton amie alors. Ton souci n'est ni plus ni moins que le problème des shell scripts setuid root d'il y a 15 ans.

Bloqué par quoi? Si le programme fork ou crée un thread avant, lui balancer un signal ne va pas pas pour autant affecter l'autre processus, seulement celui qui réclame des droits (vu qu'il est en attente de les obtenir). L'autre (le fils forké ou le thread fils) en attendant fait ce qu'il veut, y compris de l'injection si ca lui chante...

Bon il y aurait peut etre  une solution potentielle, c'est expliqué dans le man mais je trouve ca vraiment nul niveau sécu.

1.     sudo  machin (vous demandes un mot de passe et vous exécute machin)
2.     sudo -k   (cf. le man: désactive sudo mais on va pouvoir le rappeler. pour le désactiver totalement, oublier le mot de passe c'set sudo -K)
3.     sudo -v   (pour réactiver sudo : cf le man; normalement il demande un mot de passe mais pas si on mets une option verifpw=never

edit: ah non... il redemande apres au sudo suivant. Ouf

En fait, je préfère largement avoir retapé un mot de passe que de laisser un process avec autant de privilege. Si j'en ai plus besoin dans les 5 minutes (sur ma debian je l'ai mis a 5 minutes) je fais sudo -K et basta

Une solution "évidente" serait de permettre aux applis demandant du sudo de ne permettre l'héritage des tokens qu'au travers de l'héritage parent => fils.

Comme ca, uniquement les shells scripts/executables qui seraient lancés comme descendant du processus ayant les droits acquis après avoir rentré le mdp par sudo pourraient passer outre la demande de mot de passe.

Problème, c'est que ca gênerait sudo dans le cas d'execution ou les process fils se détachent de leurs parents. Mais ca reste une possibilité.

OS X qui fait ça avec le cadenas qui en fait s'ouvre avec un mot de passe, et se ferme que si tu lui dit de se fermer. (donc équivalent avec sudo -k), et les sudo n'ont pas besoin de mot de passe tant que tu l'as pas fermé.

Je dis pas qu'il est HS, techniquement c'est tout à fait interessant et dans le propos, je dis juste qu'il se méprend sur mes intentions, et que donc il tourne ses phrases de façon à ce que j'ai l'impression de ressentir un procès d'intention genre limite si je voudrais pas me loguer sous Gnome en root

Mon mot de passe fait pas 50 caracteres, ce nombre restera confidentiel d'ailleurs

Mes intentions c'est rentrer le mot de passe root une fois au premier sudo, et ensuite lorsque la session sudo expire, avoir le style façon Vista avec oui ou cancel si une appli veut faire sudo.
Ensuite une fois que je clique sur oui, on repart par exemple pour une session sans mot de passe de 15 minutes. Enfin peu importe.
L'idée est d'assouplir le truc parceque je le veux c'est tout. Sudo permet pas de le faire ça c'est certain maintenant après avoir fouillé.

Pourquoi pas par exemple rajouter une session d'expiration ou on redemanderait le mot de passe pour retomber dans le mode oui/cancel mais au bout de 1 3 ou 6 heures par exemple.

bref plus de souplesse, avec forcément une baisse de la sécu, mais c'est le prix à payer et ça resterait un choix, quand laisse sudo actif sans aucun mot de passe pendant 15 minutes on est plus à ça près, là j'ai pas le choix de le faire, donc cette idée m'est venue et on en discute de manière assez interessante ma foix

Je pense que ça doit être facilement réalisable: une application par laquelle tu passes, qui sauvegarde ton mot de passe, tu la lances, tu le tappes une fois, il retient ton mot de passe et tu lances toutes tes commandes nécéssitant un sudo par cette application, et à chaque commande il rajoute sudo et ton mot de passe.
ça serait une solution facile et envisageable, sans forcément risquer quelque chose puisque c'est codé perso et que personne ne peut connaitre ton application.
Déffaut: obligation d'utiliser ce logiciel pour lancer tes commandes sudo.

 
le nombre de commande est pas vraiment un probleme, et sinon à la question ça te fait chier de rentrer ton mot de passe 4 fois au max par heures, bah oui je me suis rendu compte que ça me dérangerait pas de pouvoir me passer de rentrer ste mot de passe

Ben dans ce cas comme dit plus haut, un log ou tu lances tes commandes qui demandent un accés root. t'as juste à rentrer une fois par jours ton mot de pass et ça roule.
En plus tu ne perds pas en sécuritée puisque le logiciel est inconnu du monde...

 
Encore une fois tu comprends à l'envers.  
 
Je ne veux pas plus de sécurité.  
 
J'utilise simplement cet argument pour dire qu'on fait déjà largement plus grave en terme de faille de sécurité, donc on peut metre un truc optionnel en plus, tout de même moins dangereux qu'un sudo sans aucune interogation, que ce soit par mot de passe ou confirmation.

 
je comprends pas bien le point 2 que je met en gras, je comprends sudo -K mais sudo -k je vois pas bien

Je pense que ça désactive la demande de mot de passe tant que tu n'as pas fait sudo -v pour le réactiver.
 
En gros c'est l'histoire du cadenat.

Ouai comme les aglo de crypto ou la sécu repose sur la non-divulgation de l'algo...
Mauvaise approche, changer approche...

Ce que tu veux ca s'appelle un agent (comme ssh-agent/gpg-agent...) ca demande un minimun de sécurité ces choses la...

non pour un usage courrant je vois pas en quoi ça gène puisque le code serait stocké en mémoire (J'entend qu'il sera bien sur crypté avec une clef de cryptage triple DES ou autre cryptage) et ressortit quand le besoin se fait!
 Le truc c'est que je vois mal un programmeur de virus creer un programme pour une personne sans savoir quel sont ses variables, quels partie de la mémoire sera utilisée et le nom du programme

le sudo -K supprime le timestamp entièrement. Le sudo -k le met à une date 0 (epoch). Le sudo -v permet de 'rafraichir' le timestamp (rajouter 5 minutes par exemple) au temps existant sans exécuter de commande. Cf ce que j'ai dit au dessus et le manpage ( )

 
comme ton mot de passe est en clair en ram je trouve ça moyen
tu peux le crypter certe, et ok ça serait de la haute voltige de hacker le truc mais bon je pense qu'il vaudrait mieux coder le machin dans sudo directement    

Oué enfin casser du cryptage triple des, ou RSA ou autre heu, c'est déjà pas à la portée de tout le monde, sans compter que ça ne te consernerait que toi...
Aprés c'est toi qui voit Si y a moyen de le faire avec sudo alors oui là ça serait plus facile.

désolé de paraitre lourd mais je comprends pas la différence entre les deux (-k et -K)
j'ai lu le man et essayé la commande pourtant  
je sais pas ce que c'est le epoch

Hmm, ca va être à la base d'agent alors. Il n'y en a pas pour sudo, ca n'est pas vraiment son role. C'est un bête utilitaire d'accès root à base de mdp, il n'a pas été concu pour gérer de la mise en cache de token d'identification

Sauf qu'un agent, ca requiert quelques précautions d'utilisation. C'est très pratique, mais ca peut devenir un vrai trou de sécu, bien pire que le "sudo par défaut qui reste actif pendant 15 min". A mon avis, ca poindra avec l'usage de dbus pour les applis desktop. Mais pour la ligne de commande, aucune chance.

C'est useless ton truc, car qui dit cryptage dit nécessairement décryptage, donc une clé pour le faire. Il suffit donc de la récupérer (elle est bien forcément quelque part sur l'ordinateur si l'utilisateur ne la rentre pas), donc tu remplaces la problèmatique du mot de passe à taper par... un autre mot de passe à taper.

Ca dépend de ce que tu attends du "virus"... Bien souvent, on s'intéresse à tracer les adresses utilisées par certaines libs, c'est ca qui est vraiment intéressant.

Oui mais bon dans un usage personnel et réduit à une seule personne c'est particulier quand même. Puis faut savoir ou ce logiciel est installé etc.
Enfin aprés c'est lui qui voit.

question eiphany :
j'aime bien quand les videos sont telechargés puis ouvertes dans un lecteur externe
pour epiphany, le seul moyen que j'ai trouvé, c'est de virer un paquet de plugin de otem, le probleme, c'est que ca vire aussi aussi le metapaquet gnome-ubuntu, et ca pose des soucis...

il y a pas une solution plus propre?

bon, c'est bon :
sudo rm *totem* dans /usr/lib/firefox/plugins et /usr/lib/mozilla/plugins

 
benh je vois pas ce que ça changerai et pourquoi ça devrait se faire par dbus
 
c'est vrai que pour la ligne de commande l'interet d'entrer un mot de passe ou de confirmer par oui non est moins évident mais bon techniquement je vois pas trop ce qui l'empecherait

Canaux de communication centralisés. Si tu veux de l'accounting avec de l'authentification, soit tu passes par des fichiers/fifos et compagnie (super niveau maintenabilité), soit tu passes par des IPC comme dbus. Bien plus simple. L'agent étant déjà implémenté, il ne reste plus grand chose.

Ca apporterait quoi de bouffer du oui à répétition? Autant utiliser sudo -k... Les avantages, et les contraintes en moins.

 
parceque c'est moins pire que de saisir son mot de passe à chaque fois.
 
pourquoi tu parles d'agents, je comprends pas

 
Tu le saisis une fois et tu dévalides ensuite avec sudo -k. En ligne de commande j'entends.
 

 
Seule possibilité pour stocker des éléments en mémoire et en garantir les accès pour des utillisateurs normaux, comme des token d'identification, et leur expiration. Sinon, obligation de passer par des binaires setuid root, ce qui a toujours représenté un danger non négligeable en sécurité.
 
C'est du clean design, comme on essaierait de faire aujourd'hui.

y aurait rien de besoin de plus que comme ça marche maintenant, je compends pas

 
Ben manifestement, tu n'es pas satisfait de l'actuel. C'est donc qu'il a bien quelque chose à changer.
 
Si tu veux faire remonter des patch au userland GNU, notamment sudo, qui ne sont pas des patchs de sécu, vas y, te gêne pas. Bon courage.

Je veux dire changer au point de devoir utiliser dbus, mais en effet si tu partais du principe qu'un patch sur sudo remonterait jamais je comprends mieux cet égarement

quand à développer un patch ouais je pourrais le faire techniquement mais mentalement pouet je sais que je m'y collerais jamais  

je peux toujours faire une demande

 
C'est pas vraiment un égarement. Ca pourrait servir pour autre chose comme centraliser des certificats de PKI, des tickets Kerberos...
 
J'en sais quelque chose, rajouter le support Kerberos sous networkmanager, c'est peine perdue. Trop compliqué, et l'appli n'est pas fait pour.

 
là j'y connais que dalle    
 

http://en.wikipedia.org/wiki/Compa [...] n_features
 
c'est donc la raison, j'ai toujours trouvé ça super moche et zarb, surtout que si un film tourne en tache de fond ça bloque l'image il me semble
 
et en ce qui concerne l'histoire du spoof de click UAC le truc d'authentification de windows semble posséder un système de protection
 

.
 

 
donc en fait si je comprends bien le plus vulnérable serait la saisie de mot de passe depuis un shell sous X, là ou gksudo protege plus.
donc sous X en fait il faudrait à chaque fois faire gksudo plutot que sudo tout court alors

Bonjours, je n'arrive pas du tout à installer les pilotes ati en ligne de commande, je ne connais pas du tout linux, j'ai trouver çà : http://doc.ubuntu-fr.org/materiel/ati_proprietaire
Mais il y a certaine chose qui je ne sais pas faire comme :  
vérifier que vous avez les dépot universe et multiverse...