Durcir Linux : su, sudo

grandtoubab · Octobre 11, 2016, 12:50pm

toto@debian:~$ cat /etc/sudoers
cat: /etc/sudoers: Permission non accordée
toto@debian:~$ ls -alrt /etc/sudoers
-r--r----- 1 root root 669 janv. 11  2016 /etc/sudoers
toto@debian:~$ sudo cat /etc/sudoers
[sudo] password for toto: 
#
# This file MUST be edited with the 'visudo' command as root.
#
# Please consider adding local content in /etc/sudoers.d/ instead of
# directly modifying this file.
#
# See the man page for details on how to write a sudoers file.
#
Defaults	env_reset
Defaults	mail_badpass
Defaults	secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

# Host alias specification

# User alias specification

# Cmnd alias specification

# User privilege specification
root	ALL=(ALL:ALL) ALL

# Allow members of group sudo to execute any command
%sudo	ALL=(ALL:ALL) ALL

# See sudoers(5) for more information on "#include" directives:

#includedir /etc/sudoers.d

voila ce qui se passe cher moi, j’ai jamais bricolé sudoers

grandtoubab · Octobre 11, 2016, 12:55pm

la différence vient surement de là

@debian:~$ ls -alrt /usr/bin/sudo
-rwsr-x--- 1 root sudo 140944 juil.  5 16:01 /usr/bin/sudo
@debian:~$ ls -alrt /usr/bin/gksudo
lrwxrwxrwx 1 root root 4 déc.   5  2014 /usr/bin/gksudo -> gksu
@debian:~$ ls -alrt /usr/bin/gksu
-rwxr-xr-x 1 root root 28080 déc.   5  2014 /usr/bin/gksu

grandtoubab · Octobre 11, 2016, 1:06pm

grandtoubab:

la différence vient surement de là

@debian:~$ ls -alrt /usr/bin/sudo
-rwsr-x--- 1 root sudo 140944 juil.  5 16:01 /usr/bin/sudo
@debian:~$ ls -alrt /usr/bin/gksudo
lrwxrwxrwx 1 root root 4 déc.   5  2014 /usr/bin/gksudo -> gksu
@debian:~$ ls -alrt /usr/bin/gksu
-rwxr-xr-x 1 root root 28080 déc.   5  2014 /usr/bin/gksu

mais pour synaptic c’es pkexec qui est utilisé

tu le vois dans

/usr/share/applications/synaptic.desktop

il y a plusieurs commandes comme ça

@debian:~$ locate pkexec
/usr/bin/gparted-pkexec
/usr/bin/gufw-pkexec
/usr/bin/lightdm-gtk-greeter-settings-pkexec
/usr/bin/pkexec
/usr/bin/synaptic-pkexec
/usr/bin/tuxboot-pkexec




debian:~$ ls -alrt /usr/bin/synaptic-pkexec
-rwxr-xr-x 1 root root 43 janv. 11  2016 /usr/bin/synaptic-pkexec

faut surement changer et leur mettre le groupe sudo

PengouinPdt · Octobre 11, 2016, 1:11pm

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 …

PengouinPdt · Octobre 11, 2016, 1:35pm

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 - 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 - infirmer, affirmer, conclure …

grandtoubab · Octobre 11, 2016, 1:53pm

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

PengouinPdt · Octobre 11, 2016, 1:57pm

je ne confond pas

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

grandtoubab · Octobre 11, 2016, 2:21pm

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

PengouinPdt · Octobre 11, 2016, 2:30pm

Là, tu as faux … relis la recommandation 58 de l’ANSSI … on dirait que tu t’es arrêté à la 57
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) …

grandtoubab · Octobre 11, 2016, 3:56pm

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

PengouinPdt · Octobre 11, 2016, 4:12pm

# 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

jcsm33 · Octobre 12, 2016, 2:31pm

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 ?

littlejohn75 · Octobre 12, 2016, 4:29pm

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

PengouinPdt · Octobre 12, 2016, 4:30pm

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

MdgRUN · Octobre 15, 2016, 11:31am

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…

PengouinPdt · Octobre 15, 2016, 11:52am

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 …

MicP · Octobre 23, 2016, 3:50pm

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

David_5.1 · Octobre 16, 2016, 8:52am

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…

PengouinPdt · Octobre 16, 2016, 10:34am

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

David_5.1 · Octobre 16, 2016, 11:34am

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…

Durcir Linux : su, sudo

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

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