# visudo -c
/etc/sudoers: parsed OK
/etc/sudoers.d/README: parsed OK
/etc/sudoers.d/defaults: parsed OK
Le fichier ‘defaults’ renfermant les spécificités de la recommandation 58 ANSSI 
Bonjour,
Peut-être que tout vient de ce fichier de configuration du paquet policykit-1
$ cat /etc/polkit-1/localauthority.conf.d/51-debian-sudo.conf
[Configuration]
AdminIdentities=unix-group:sudo
Si le nom du groupe n’est plus sudo, que se passe-t-il ?
Serait-il possible d’avoir le contenu de ce fichier /etc/sudoers.d/defaults ?
Et un lien vers la recommandation 58 ANSSI ?
Si ce n’est pas trop vous demander
Cordialement,
Regards,
Mit freundlichen Grüßen,
مع تحياتي الخالصة
F. Petitjean
« L’amour, c’est comme les spaghettis, quand c’est mou, c’est cuit. »
Proverbe belge
Bonsoir, @littlejohn75 :
Le contenu du fichier /etc/sudoers.d/defaults est le contenu de la recommandation 58 ANSSI 
(c’est moi qui l’ai créé, selon les recommandations liées à ‘sudoers’, et l’est nommé ainsi)
Tu trouveras les recommandations dans le lien que donne grandtoubab, plus haut dans ce topic
Bonjour,
dans un terminal sur une machine Ubuntuïsée:
ls -al /usr/bin/sudo
-rwsr-xr-x 1 root root 159852 août 17 17:19 /usr/bin/sudo
/usr/bin/sudo est ROUGE
De même que ------>/bin/su …à partir de:
ls -al /bin/su
-rwsr-xr-x 1 root root 38900 mars 29 2016 /bin/su
Si je tape:
ls -alrt /usr/bin/gksu
-rwxr-xr-x 1 root root 22680 déc. 25 2014 /usr/bin/gksu
/usr/bin/gksu est VERT
Alors que:
ls -alrt /usr/bin/gksudo
lrwxrwxrwx 1 root root 4 déc. 25 2014 /usr/bin/gksudo -> gksu
gksu reste VERT avec /usr/bin/gksudo en VERT LAGON.
Les différents niveaux de commande sont bien mis en évidence.
Reste à en trouver la plus judicieuse utilisation.
Si j’aurais SU…
Beh, déjà, concernant ‘su’, et ‘sudo’, tu peux leur signifier des droits en 4750, parce que le reste du monde n’a pas à avoir des droits dessus … et, tu peux même faire de même pour ‘gksu’ …
Et, si tu veux que les droits soient permanents, tu utilises la commande ‘dpkg-statoverride’ - ce qui fait que même lors de màj de ses commandes les droits dessus auront été “figées” …
Tu peux aller plus loin en signifier l’appartenance root:sudo …
Lien symbolique => Cyan
Exécutable => Vert
Exécutable setuid => Gris sur fond Rouge
La différence de couleur est fonction des attributs des fichiers listés.
Voir :
dircolors --print-database
echo $LS_COLORS
1 J'aime
Pas forcément… Pour un usage basique de sudo qui se limite à permettre à un ou plusieurs admins de lancer n’importe quelle commande en root, oui. Dans d’autre cas, on peut vouloir dire que tel user peut lancer telle commande en temps que tel autre user (éventuellement sans mot de passe), et là, c’est plus si évident.
Effectivement, tu m’as fait découvrir cette commande, mais c’est la bonne façon de définir des permissions personnalisées sur su et sudo (dans la même idée, il y a dpkg-divert pour déplacer un fichier installé via dpkg / apt).
Pour le problème initial, dpkg-statoverride --update --add root sudo 4750 /usr/bin/sudo marche bien sur ma debian jessie (sans aucune autre modif de la conf de sudo qui pourrait interférer). Je ne vois pas de raison pour laquelle utiliser un autre groupe y changerait quoi que ce soit, à part que ça me semble moins clair.
En ajoutant les recommendations de l’ANSSI, dans /etc/sudoers.d/anssi :
Defaults noexec,requiretty,use_pty,umask=0027
Defaults ignore_dot,env_reset,passwd_timeout=1
J’ai :
$ sudo ls
fichier1 (donc tout va bien)
$ sudo apt-get update
Failed to exec method /usr/lib/apt/methods/http
E: Method http has died unexpectedly!
E: Le sous-processus http a renvoyé un code d'erreur (100)
E: La méthode /usr/lib/apt/methods/http n'a pas démarré correctement
(en vrai, j’ai plus de messages, mais peu importe…)
Je pense que le problème vient de noexec dans la conf de l’ANSSI. Et après un petit test, je confirme que apt-get update marche si on l’enlève 
Pour synaptic, et autres trucs graphiques, je ne sais pas, j’administre ma machine en console et ce que je dis suit des tests de 5 minutes donc je te laisse retester, d’abord en terminal (ls puis apt), puis en graphique pour voir ce qui marche…
Ahhh, mais, perso, c’est clair -
‘sudo’ en mode console, il ne veut pas de mon mot-de-passe utilisateur … mais je peux exécuter ‘su’ depuis mon user principale …
et, en mode graphique, quand est demandé le mot-de-passe admin, il me prend celui de mon user, mais pas root !
Et, mon user principal est bien dans le groupe ‘sudo’ …
La seule diff est que j’ai appliqué les droits du groupe ‘sudo’ sur les commandes ‘su’, et ‘sudo’, de manière décrite plus haut
Je retiens quand même l’idée de la présence de l’option ‘noexec’ ou son absence dans le fichiers ‘sudoers’ … cela est pertinent !
Après, ce mode opératoire ne me dérange aucunément … c’est juste que c’est légèrement différent de celui attendu
Que tout soit sûr, tu t’es bien reloggué depuis que tu as ajouté ton user dans sudo ?
id renvoie bien qu’il est dans le groupe sudo ?
Tu as bien -rwsr-x--- 1 root sudo 157760 janv. 11 2016 /usr/bin/sudo
et %sudo ALL=(ALL:ALL) ALL dans /etc/sudoers ou /etc/sudoers.d/* ?
Si tout est bien comme ça, ça semble anormal que tu ne puisses pas faire sudo ls / (sauf si ton mdp n’est pas bon, mais j’ose imaginer que c’est pas le pb…)
Dans ca cas, poste le message que tu as avec sudo ls /.
PS : Désolé si tu as déjà répondu à certaines questions, mais je veux être sûr que tu n’aies rien modifié depuis et il y a un peu de spam dans le fil donc j’ai du mal à tout retrouver…
$ id
uid=1000(xyz) gid=1000(xyz) groupes=1000(xyz),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),108(netdev),110(lpadmin),113(scanner),118(bluetooth)
‘xyz’ n’étant pas mon réel id
$ sudo ls /
We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:
#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility.
[sudo] password for xyz:
Sorry, try again.
[sudo] password for xyz:
Sorry, try again.
[sudo] password for xyz:
Sorry, try again.
sudo: 3 incorrect password attempts
$ mail
Mail version 8.1.2 01/15/2001. Type ? for help.
"/var/mail/xyz": 1 message 1 new
>N 1 xyz@ptb-xyz Sun Oct 16 13:37 18/695 *** SECURITY information for ptb-xyz ***
Message 1:
From xyz@ptb-xyz Sun Oct 16 13:37:08 2016
Envelope-to: root@ptb-xyz
Delivery-date: Sun, 16 Oct 2016 13:37:08 +0200
To: root@ptb-xyz
Auto-Submitted: auto-generated
Subject: *** SECURITY information for ptb-dm1330 ***
From: xyz <zou@ptb-xyz>
Date: Sun, 16 Oct 2016 13:37:08 +0200
ptb-xyz : Oct 16 13:37:08 : zou : 3 incorrect password attempts ; TTY=pts/1 ; PWD=/home/xyz/Documents/ ; USER=root ; COMMAND=/bin/ls /
Et sans soucis :
$ su
Mot de passe :
root@ptb-xyz:/home/xyz/Documents/#
Tous les soirs, au moment du couché, le poste est éteint, et rallumé au petit matin - ceci dépendant des jours différents …
La réponse de sudo est que le mot de passe est faux, pas que tu n’as pas les droits…
Tu mets bien le mot de passe de ton compte avec sudo, pas celui de root ?
STP !!!
Je sais ce que je fais … quand même
Le mot de passe est considéré comme faux …
tu peux très bien ne pas me croire, mais je sais pertinemment qu’il est juste !
Même en l’injectant par copier coller depuis Keepass, il n’en veut pas !
alors, qu’en appel, en mode graphique, tel que l’usage de synaptic, il l’accepte !!!
Je ne sais pas, mais vu les symptômes, ça colle parfaitement avec quelqu’un qui tape le mdp de root quand il lance sudo au lieu de taper le mdp de l’user actuel…
Vu que tu confirmes que c’est pas ça, j’avoue que j’ai du mal à voir ce qui peut se passer…
Tu n’as pas mis d’autres trucs pour durcir ta debian (style SElinux, apparmor, Grsec) ?
[quote=“David_5.1, post:34, topic:71282”]Je ne sais pas, mais vu les symptômes, ça colle parfaitement avec
quelqu’un qui tape le mdp de root quand il lance sudo au lieu de taper
le mdp de l’user actuel…[/quote]
Je sais … mais, NON !
Clairement, non !
Mais étant donné que je viens de “réaliser” que j’ai deux ou trois autres laptops sous Debian, Jessie aussi … je vais tester la même “config”