Durcir Linux : su, sudo

PengouinPdt · Octobre 10, 2016, 7:45pm

Dans ma phase d’apprentissage personnelle, de mes différentes recherches pour durcir Linux de différents moyens, je m’attaque à la surface lié à l’usage des commandes ‘su’, et ‘sudo’ …

Premier fait intéressant que j’ai appris récemment est le fait suivant :

Lors de l’installation d’une Debian, si tu ne précises pas l’identification root, celui-ci n’est pas créé, et le système bascule automatiquement en mode sudo, avec pour la gestion administrative, le premier compte créé.
Et, oui, Debian fonctionne, soit en mode ‘su’, soit en mode ‘sudo’ et ce nativement …

Bien, dans les faits d’un durcissement de ces deux binaires, il est intéressant donc d’utiliser la commande ‘dpkg-statoverride’.

Dans le premier cas, où il y a eu gestion du compte root, puis création d’un compte utilisateur :

dpkg-statoverride --update --add root sudo 4750 /bin/su

Ce qui a pour propos de refuser l’accès au binaire ‘su’ pour tout le monde, sauf ceux qui font partie du groupe ‘sudo’.
Et de fait, on se retrouve bien avec un refus ferme et catégorique d’accès au binaire.
Hors dans ce contexte, personne ne fait partie du groupe ‘sudo’ … donc, même le premier compte ne pourra plus utiliser ‘su’ - très bien !

Au lieu d’ajouter le premier compte au groupe sudo, on va créer un groupe système, tel que ‘gsu’ pour l’exemple … puis ajouter son user au groupe.

addgroup -r gsu
adduser user_id gsu

(où ‘user_id’ est à modifier par votre propre identifiant…)

Ensuite, il faut annuler la gestion de dpkg-statoverride pour préciser le bon groupe :

dpkg-statoverride --remove /bin/su
dpkg-statoverride --update --add root gsu 4750 /bin/su

On se déco, se reco !

Normalement, votre utilisateur, et seul votre utilisateur a le droit d’utiliser la commande ‘su’ …

Ensuite, on installe le binaire ‘sudo’ … sauf à n’avoir pas géré le compte root, lors de l’installation …
Mais, là, on va durcir les choses aussi !

En effet, on ne vas pas utiliser le groupe ‘sudo’, mais le groupe ‘gsu’ créé précédemment …

Pour cela, il faut avec les droits admins modifier le fichier sudoers principal …
pour remplacer la ligne qui déclare le groupe ‘sudo’ ayant tous les droits :

#%sudo  ALL=(ALL:ALL) ALL
%gsu ALL=(ALL:ALL) ALL

On vérifie bien que votre id fait bien partie du groupe ‘gsu’ …

# getent group gsu
gsu:x:999:votre_user

On applique la politique ‘dpkg-statoverride’ sur /usr/bin/sudo afin que seuls les utilisateurs du groupe est le droit d’accéder au binaire, et pas le reste du monde !

dpkg-statoverride --update --add root gsu 4750 /usr/bin/sudo

On se déco à nouveau, et se reco !

Et, c’est là, un truc que je n’ai pas du comprendre …
Parce que mon compte utilisateur a beau faire partie du groupe admin en question, ici nommé ‘gsu’ … il peut gérer ‘su’ mais ‘sudo’, est en échec, refus de reconnaître le pass du compte utilisateur …

Alors que n’aies-je pas compris, dans l’usage de sudo ?

grandtoubab · Octobre 10, 2016, 6:50pm

bien compliqué
je me contente de cette recommandation

7.2.2.1 Droits d’accès
sudo est généralement installé par défaut avec des droits ouverts et permet à n’importe quel
utilisateur de l’utiliser (droit d’exécution pour tout le monde). sudo étant un exécutable privilégié et
complexe de par sa configuration, il est préférable de restreindre ses droits d’exécution à un groupe
utilisateur dédié. Cela réduit la surface d’attaque, notamment quand le système et le binaire lui-même
sont victimes de vulnérabilités exploitables par n’importe quel utilisateur (CVE-2012-0809, CVE-2012-
0864).
R57 - I R E Groupe dédié à l’usage de sudo
Un groupe dédié à l’usage de sudo doit être créé. Seuls les utilisateurs membres de ce
groupe doivent avoir le droit d’exécuter sudo.
Un cas envisageable est de créer un groupe dédié (ici : sudogrp), et de lui attribuer les
droits pour exécuter sudo. Seuls les membres de ce groupe pourront ainsi y faire appel :
# ls -al /usr/bin/ sudo
- rwsr -x - - -. 2 root sudogrp [ … ] / usr / bin / sudo
Cette modification doit être vérifiée et éventuellement appliquée après chaque mise à jour, ces
changements pouvant être écrasés par les scripts d’installation.

PengouinPdt · Octobre 11, 2016, 1:43pm

Ehehhh, pourquoi tu crois que je crée un groupe utilisateur qui lui seul aura le droit d’exécuter …

Ce dont, je parle dans mon post ci-dessus, est simplement l’application, avec juste l’ajout de la gestion des droits sur les binaires, en utilisant ‘dpkg-statoverride’ pour cette dernière.

Relis le post, à l’éclairage de cette recommandation

Le manpage de ‘dpkg-statoverride’ :

DESCRIPTION
Les « dérogations au statut » sont une façon de demander à dpkg(1) de changer le propriétaire ou le mode d’un chemin lors de l’installation d’un
paquet (cela s’applique à tout objet de système de fichiers que dpkg gère, notamment les répertoires, les périphériques, etc.) On peut s’en servir
pour forcer l’installation de programmes qui sont normalement « setuid » sans ce drapeau « setuid », ou pour les rendre exécutables seulement par
un groupe donné.

   dpkg-statoverride est un utilitaire pour gérer la liste des dérogations. Il possède trois fonctions élémentaires : l'ajout, la suppression  et  le
   listage des dérogations.

En fait, la commande ‘dpkg-statoverride’ force le système à définir tels droits sur tels binaires, même lors de leur installation … il rend permanent de tels droits … même lors des màj systèmes … qui auraient tendance à rétablir des droits “minimum”.

grandtoubab · Octobre 11, 2016, 9:01am

le groupe dédié existe déjà c’est le groupe sudo

grep sudo /etc/group

On y mets les utilisateurs qu’on veut autoriser, exemple si ton utilisateur s’appelle toto

sudo:x:27:toto

On restreint les droits d’exécution

ls -alrt /usr/bin/sudo
-rwsr-x— 1 root sudo 140944 juil. 5 16:01 /usr/bin/sudo

PengouinPdt · Octobre 11, 2016, 9:11am

Utilises plutôt :
getent group sudo

Je sais que, sous Debian, le groupe ‘sudo’ est créé lors de l’installation du paquet idoine …

PengouinPdt · Octobre 11, 2016, 10:39am

Bon, quoiqu’il en soit, même en ayant mis mon user principal dans le groupe ‘sudo’ … je me fais jeter quand je cherche à utiliser la commande ‘sudo’ … alors que l’usage de ‘su’ m’est permis !

$ getent group sudo
sudo:x:27:hucste

Mon réel id n’est pas ‘hucste’

Mon fichier sudoers est le suivant :

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

J’ai un fichier /etc/sudoers.d/defaults où j’ai notifié la recommandation ANSSI n°58 :

Defaults noexec,requiretty,use_pty,umask=0027
Defaults ignore_dot,env_reset,passwd_timeout=1

Je ne vois pas, en quoi, cela peut empêcher mon user qui fait bel et bien partie de mon groupe ‘sudo’ à utiliser la commande correspondante ?

Et, que le groupe ‘sudo’ a bel et bien le droit d’exécuter les deux commandes :

# ls -al /bin/su
-rwsr-x--- 1 root sudo 40168 nov.  18  2015 /bin/su
# ls -al /usr/bin/sudo
-rwsr-x--- 1 root sudo 157760 janv. 11  2016 /usr/bin/sudo

alors, quid ?!

littlejohn75 · Octobre 11, 2016, 12:22pm

Sur une machine jessie non modifiée, je n’ai pas exactement les mêmes paramètres

fp2x@masime:~$ alias l
alias l='ls -lApst'
fp2x@masime:~$ l /bin/su /usr/bin/sud*
156 -rwsr-xr-x 1 root root 157760 janv. 11  2016 /usr/bin/sudo
 76 -rwxr-xr-x 1 root root  76800 janv. 11  2016 /usr/bin/sudoreplay
  0 lrwxrwxrwx 1 root root      4 janv. 11  2016 /usr/bin/sudoedit -> sudo
 40 -rwsr-xr-x 1 root root  40168 nov.  18  2015 /bin/su
fp2x@masime:~$ getent group sudo
sudo:x:27:fp2x
fp2x@masime:~$

Et j’ai la même chose sur un conteneur (lxc) en testing.

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

F. Petitjean

« Celui qui, parti de rien, n’est arrivé nulle part n’a de merci à dire à personne !! »
Pierre Dac

PengouinPdt · Octobre 11, 2016, 12:32pm

Oui, en effet, par défaut … les droits appartiennent à root

Ce qui est bizarre, c’est qu’en console, il ne reconnaît pas mon pass lors de la saisie, telle que 'sudo apt update ', mais si je demande à exécuter en mode graphique une application qui demande la saisie du pass, tel que synaptic, c’est bien le pass user et non root … qui fonctionne !

grandtoubab · Octobre 11, 2016, 12:34pm

si tu mets ton user dans le groupe sudo, évidemment que ça lui accorde le droit d’utiliser sudo, c’est fait pour ça

PengouinPdt · Octobre 11, 2016, 12:39pm

stp, @grandtoubab, ne me prends pas pour un idiot
le problème n’est pas là !
essaye, stp, d’analyser le problème … ou de ne pas répondre à chaud.
C’est une évidence pour toi … cela l’est pour moi aussi de l’usage de ‘sudo’.

mon user est dans le groupe ‘sudo’ !
mon pass est demandé en mode graphique et fonctionnel, tel que l’usage de synaptic … celui de ‘root’ est refusé !
en mode terminal, cela échoue … (telle que ‘sudo apt update’) …
(et, entre temps, la machine a été redémarré plus d’une fois :p)

par contre, si je saisie en mode terminal ‘su’ … j’y ai accès et je tape le pass admin … - cela est lié au fait que seuls les utilisateurs faisant partie du groupe ‘sudo’ ont le droit de l’exécuter

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

Durcir Linux : su, sudo

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

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