Durcir Linux : su, sudo

Support Debian
#14

Intéressant, sauf que :

# ls -al /usr/bin/ | egrep "su"
-rwxr-xr-x  1 root   root      31240 mars  14  2015 cksum
-rwxr-xr-x  1 root   root       2327 juil. 24 21:21 dh_md5sums
-rwxr-xr-x  1 root   root      12232 juin  30  2012 dh_pysupport
-rwxr-xr-x  1 root   root       3442 juil. 24 21:21 dh_suidregister
-rwxr-xr-x  1 root   root      35288 nov.  30  2014 envsubst
-rwxr-xr-x  1 root   root     105344 juin  10  2013 lsusb
-rwxr-xr-x  1 root   root      39496 mars  14  2015 md5sum
lrwxrwxrwx  1 root   root          6 mars  14  2015 md5sum.textutils -> md5sum
-rwxr-xr-x  1 root   root      63376 sept. 27 20:01 nsupdate
-rwxr-xr-x  1 root   root      14792 oct.  12  2014 pasuspender
-rwxr-xr-x  1 root   root      43592 mars  14  2015 sha1sum
-rwxr-xr-x  1 root   root      51784 mars  14  2015 sha224sum
-rwxr-xr-x  1 root   root      51784 mars  14  2015 sha256sum
-rwxr-xr-x  1 root   root      55880 mars  14  2015 sha384sum
-rwxr-xr-x  1 root   root      55880 mars  14  2015 sha512sum
-rwxr-xr-x  1 root   root       9065 juil. 22 17:59 shasum
-rwsr-x---  1 root   sudo     157760 janv. 11  2016 sudo
lrwxrwxrwx  1 root   root          4 janv. 11  2016 sudoedit -> sudo
-rwxr-xr-x  1 root   root      76800 janv. 11  2016 sudoreplay
-rwxr-xr-x  1 root   root      39504 mars  14  2015 sum
-rwxr-xr-x  1 root   root        446 nov.  20  2014 sushi
-rwxr-xr-x  1 root   root       3120 juin  14  2014 su-to-root
-rwxr-xr-x  1 root   root       5164 juil. 22 17:59 xsubpp

Pas de ‘gksudo’, ni de ‘gksu’ …
mais du ‘sushi’ … (‘à table :p’) - laisse tomber, c’est du délire …

#15

Oui, cela peut en effet être intéressant dans la même optique de durcissement, mais étant donné que le lancement de synaptic me demande le pass user et non pas root, cela fonctionne normalement !

Juste pour tester, je vais tester à mettre le binaire ‘synaptic-kexec’ appartenant au groupe ‘sudo’ … voir s’il réagit pareil :wink: - la réponse est : oui !

La question, intéressante, qui suit, est : si je me mets à obliger mon système à ce que seuls les utilisateurs du groupe ‘sudo’, soient les seuls, hormis root, à utiliser les commandes ‘su’, ‘sudo’, ‘synaptic’ … pourquoi ne pas le faire pour toutes les commandes 'apt’, 'dpkg’ … ?!**

Quoiqu’il en soit mon problème étant qu’en mode terminal, je ne peux pas utiliser la commande ‘sudo’ dans l’état de l’art … mais la commande ‘su’ fonctionne …
Ce qui reviendrait à avoir “le meilleur des deux mondes”, à savoir :

  • en mode terminal, cela passe par ‘su’ …
  • en mode fenêtrée, c’est ‘sudo’ qui prend la main …

Ahhh, si quelques uns voulaient bien tester et faire le même cheminement :stuck_out_tongue: - infirmer, affirmer, conclure …

#16

faut pas confondre su et sudo, ce sont 2 exécutables différents

debian:/usr/bin$ ls -alrt /bin/su*
-rwsr-xr-x 1 root root 40168 sept. 18 16:42 /bin/su


@debian:/usr/bin$ ls -alrt /usr/bin/sudo*
-rwxr-xr-x 1 root root  51808 juil.  5 16:01 /usr/bin/sudoreplay
lrwxrwxrwx 1 root root      4 juil.  5 16:01 /usr/bin/sudoedit -> sudo
-rwsr-x--- 1 root sudo 140944 juil.  5 16:01 /usr/bin/sudo
#17

je ne confond pas :wink:

tel que configurée, ‘su’ n’est utilisable que par root et le groupe ‘sudo’ … et, idem pour la commande ‘sudo’ .

J’ai le sentiment que tu n’arrives pas à saisir les nuances de ce que j’ai écris, non ?!

#18

c’est bien toi qui indique que le comportement des deux commandes est différents,
il faut tout mettre d’ aplomb en termes de groupe et droits avant de comparer et ne rien bricoler dans sudoers

#19

Là, tu as faux … relis la recommandation 58 de l’ANSSI … on dirait que tu t’es arrêté à la 57 :stuck_out_tongue:
je l’ai simplement intégré dans un fichier /etc/sudoers.d/defaults
Le fichier /etc/sudoers étant identique à l’original !

Quant à l’usage de ‘dpkg-statoverride’, cela fait partie des recommandations de durcissement que tu trouveras en cherchant sur le web sur les mots “dpkg_statoverride /bin/su harden” (donnée principalement pour ubuntu, appliquée aussi à debian) …

#20

je ne pensais pas à la recommandation mais à des lignes que tu aurais ajouté dans sudoers avec un éditeur foireux

Mon user est dans les groupes adm et sudo ( les autres groupes me paraissent etre hors du coup)

la commande apt est ainsi

debian:~$ ls -alrt /usr/bin/apt
-rwxr-xr-x 1 root root 14424 oct.   4 19:43 /usr/bin/apt

si je lance apt update ça m"insulte

debian:~$ apt update
W: chmod 0700 of directory /var/lib/apt/lists/partial failed - SetupAPTPartialDirectory (1: Opération non permise)
E: Impossible d'ouvrir le fichier verrou /var/lib/apt/lists/lock - open (13: Permission non accordée)
E: Impossible de verrouiller le répertoire /var/lib/apt/lists/
W: Problème de suppression du lien /var/cache/apt/pkgcache.bin - RemoveCaches (13: Permission non accordée)
W: Problème de suppression du lien /var/cache/apt/srcpkgcache.bin - RemoveCaches (13: Permission non accordée)
E: Impossible d'ouvrir le fichier verrou /var/lib/dpkg/lock - open (13: Permission non accordée)
E: Impossible de verrouiller le répertoire d'administration (/var/lib/dpkg/). Avez-vous les privilèges du superutilisateur ?

avec sudo ça passe

debian:~$ sudo apt update
[sudo] password for xxx:
Ign:1 http://dl.google.com/linux/chrome/deb stable InRelease
Atteint:2 http://security.debian.org/debian-security jessie/updates InRelease
Atteint:3 http://ftp2.de.debian.org/debian stretch InRelease
Atteint:4 http://archive.canonical.com xenial InRelease
Atteint:5 http://dl.google.com/linux/chrome/deb stable Release
Atteint:6 http://ppa.launchpad.net/tsbarnes/indicator-keylock/ubuntu xenial InRelease
Atteint:7 http://repos.fds-team.de/stable/debian stretch InRelease
Atteint:8 http://security.debian.org/debian-security stretch/updates InRelease
Atteint:9 http://ftp2.de.debian.org/debian stretch-updates InRelease
Ign:10 http://ftp2.de.debian.org/debian jessie InRelease
Atteint:11 http://ftp2.de.debian.org/debian jessie-updates InRelease
Atteint:12 http://ftp2.de.debian.org/debian jessie Release
Atteint:14 https://deb.opera.com/opera-stable stable InRelease
Lecture des listes de paquets… Fait
Construction de l’arbre des dépendances
Lecture des informations d’état… Fait
1 package can be upgraded. Run ‘apt list --upgradable’ to see it.

et donc

    @debian:~$ ls -alrt /usr/bin/sudo
    -rwsr-x--- 1 root sudo 140944 juil.  5 16:01 /usr/bin/sudo

Si tu es dans les mêmes conditions , je ne vois pas où est ton filtre

avec root directement

root@debian:/# apt update
Atteint:1 http://security.debian.org/debian-security jessie/updates InRelease
Atteint:2 http://archive.canonical.com xenial InRelease                        
Atteint:3 http://ppa.launchpad.net/tsbarnes/indicator-keylock/ubuntu xenial InRelease
Atteint:4 http://security.debian.org/debian-security stretch/updates InRelease 
Atteint:5 http://ftp2.de.debian.org/debian stretch InRelease                   
Ign:6 http://dl.google.com/linux/chrome/deb stable InRelease                   
Atteint:7 http://dl.google.com/linux/chrome/deb stable Release                 
Atteint:8 http://ftp2.de.debian.org/debian stretch-updates InRelease           
Atteint:9 http://repos.fds-team.de/stable/debian stretch InRelease             
Ign:10 http://ftp2.de.debian.org/debian jessie InRelease                       
Atteint:11 http://ftp2.de.debian.org/debian jessie-updates InRelease
Atteint:12 http://ftp2.de.debian.org/debian jessie Release     
Atteint:13 https://deb.opera.com/opera-stable stable InRelease
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances        
Lecture des informations d'état... Fait
1 package can be upgraded. Run 'apt list --upgradable' to see it.
root@debian:/#

il reste à verifier sudoers

root@debian:/# visudo -c
/etc/sudoers: parsed OK
/etc/sudoers.d/README: parsed OK
#21 
# 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 :wink:

#22

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 ?

#23

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

Cordialement,
Regards,
Mit freundlichen Grüßen,
مع تحياتي الخالصة

F. Petitjean

« L’amour, c’est comme les spaghettis, quand c’est mou, c’est cuit. »
Proverbe belge

#24

Bonsoir, @littlejohn75 :

Le contenu du fichier /etc/sudoers.d/defaults est le contenu de la recommandation 58 ANSSI :stuck_out_tongue:
(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 :wink:

#25

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…:confused:

#26

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 …

#27

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
#28

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 :slight_smile:

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…

#29

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 :stuck_out_tongue:

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

#30

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…

#31 
$ 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 :wink:

$ 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 …

#32

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 ?

#33

STP !!!
Je sais ce que je fais … quand même :wink:

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