[Résolu] Sudoers via Visudo

TuxLife · Le 23/01/2024, à 08:32

Bonjour, j'ai n petit souci au niveau de l'attribution des droits d'exécutiion donnés à certains utilisateurs via la modification du fichier "sudoers".
Lorsque je crée des accès à un simple utilisateur pour deux commandes différentes, l'une d'elles fonctionne mais l'autre ne peut être exécutée par manque de droit.
L'utilisateur est le même, les droits aussi (à priori), seule la commande est différente. Lorsque je tape la commande rebelle dans le terminal, elle ne s'exécute pas et reçois un message d'erreur.
Je joins également une capture du sudoers. Si vous pouvviez m'aider là-dessus, ce serait fort aimable de votre part.

Merci!

SUDOERS: 
# Host alias specification

# User alias specification

# Cmnd alias specification

# User privilege specification
root    ALL=(ALL:ALL) ALL
tux     ALL=(ALL:ALL) /usr/sbin/ifconfig
tux     ALL=(ALL) NOPASSWD:/usr/sbin/ifconfig
tom     ALL=(ALL:ALL) /usr/sbin/ifconfig
tom     All=(ALL:ALL) /usr/bin/zenity
tom     All=(ALL) NOPASSWD:/usr/bin/zenity
tom     ALL=(ALL) NOPASSWD:/usr/sbin/ifconfig
# Members of the admin group may gain root privileges
%admin ALL=(ALL) ALL

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

ERREUR:

tux@tux-fix:~$ su tom
Mot de passe : 
tom@tux-fix:/home/tux$ sudo zenity
[sudo] Mot de passe de tom : 
Désolé, l'utilisateur tom n'est pas autorisé à exécuter « /usr/bin/zenity » en tant que root sur tux-fix.
tom@tux-fix:/home/tux$

Dernière modification par TuxLife (Le 30/01/2024, à 17:58)

xubu1957 · Le 23/01/2024, à 09:57

Bonjour,

Pour ajouter toi-même les balises code à ton message #1 :

Cliquer sur le lien « Modifier » en bas à droite du message
Sélectionner le texte
Cliquer sur le <> de l'éditeur de message

moko138 a écrit :

1) Les balises-code sont les < > (crochets bleus) de la barre de mise en forme.

_ _ _
3) /!\ Si vous avez plusieurs retours à donner, séparez-les bien (toujours pour la lisibilité) :
comme
cela.

Comme demandé dans le premier message du tutoriel Retour utilisable de commande

SUDOERS:

# Host alias specification

# User alias specification

# Cmnd alias specification

# User privilege specification
root    ALL=(ALL:ALL) ALL
tux     ALL=(ALL:ALL) /usr/sbin/ifconfig
tux     ALL=(ALL) NOPASSWD:/usr/sbin/ifconfig
tom     ALL=(ALL:ALL) /usr/sbin/ifconfig
tom     All=(ALL:ALL) /usr/bin/zenity
tom     All=(ALL) NOPASSWD:/usr/bin/zenity
tom     ALL=(ALL) NOPASSWD:/usr/sbin/ifconfig
# Members of the admin group may gain root privileges
%admin ALL=(ALL) ALL

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

ERREUR:

tux@tux-fix:~$ su tom
Mot de passe :
tom@tux-fix:/home/tux$ sudo zenity
[sudo] Mot de passe de tom :
Désolé, l'utilisateur tom n'est pas autorisé à exécuter « /usr/bin/zenity » en tant que root sur tux-fix.
tom@tux-fix:/home/tux$

Et pour info, dans le fil Problème connexion Ethernet via CPL

Le 01/07/2019, bruno a écrit :

Hors-sujet.
Au passage les commandes ifconfig sont obsolètes. Il serait préférable d'aider les demandeurs avec les commandes ip:
#3 : remplacer par ip a (ou ip address show)
#4 : remplacer par ip link set enp4s0 up|down

Dernière modification par xubu1957 (Le 23/01/2024, à 10:00)

jplemoine · Le 23/01/2024, à 10:10

Je pense qu'il faut revoir la syntaxe :
- une ligne par utilisateur
- on doit pouvoir fusionner les lignes NOPASSWD avec la ligne précédente

bruno · Le 23/01/2024, à 10:16

Bonjour,

Il faut nous expliquer ce que tu veux faire. Telles quelles les commandes ip et zenity peuvent être lancés par n'importe quel utilisateur.
Et surtout zenity ne devrait jamais être lancé en root.

Attention à ta façon d'utiliser su / sudo.

Si tu veux obtenir le shell d'un autre utilisateur c'est :

sudo -i -u tom

ou

su -l tom

(voir man sudo et man su)
Avec ta commande tu t'es substitué à l'utilisateur tom en conservant l’ensemble des variables d’environnement de l'utilisateur tux.

jplemoine · Le 23/01/2024, à 10:38

bruno a écrit :

Et surtout zenity ne devrait jamais être lancé en root.

Sauf erreur de ma part, zenity permet juste d’améliorer la présentation des scripts : je ne vois pas de problème de sécurité à le lancer en root.
Donc, pourquoi ?

bruno · Le 23/01/2024, à 10:59

@jplemoine: Je dis cela par ce qu'autoriser zenity en root revient à donner tous les privilèges (--file-selection --save, par exemple).

Concernant l'erreur rencontré par TuxLife c'est sans doute dû à une mauvaise utilisation de visudo. Attention les directives sont appliquées dans l'ordre et quand plusieurs directives correspondent à un même utilisateur seule la dernière est appliquée. C'est pourquoi il vaut mieux placer les directives spécifiques aux utilisateurs en dernier. Idéalement dans un fichier à part en utilisant la commande :

visudo /etc/sudoers.d/dierctives_pour_toto

Dernière modification par bruno (Le 23/01/2024, à 11:17)

jplemoine · Le 23/01/2024, à 16:10

bruno a écrit :

@jplemoine: Je dis cela par ce qu'autoriser zenity en root revient à donner tous les privilèges (--file-selection --save, par exemple).

Oui vu son cet angle...

bruno · Le 23/01/2024, à 16:28

Non ce n'est pas une question de point de vue, mais de sécurité de base.
Quand on accorde à un utilisateur standard, sans privilèges, le droits d'exécuter une application en tant que root, il faut être sûr que cette application ne permet pas de faire tout est n'importe quoi.
En l’occurrence avec cette commande :

sudo zenity --file-selection --save

l'utilisateur a accès à un sélecteur de fichier qui lui permet (clic droit sur un dossier) d'ouvrir ensuite un explorateur de fichier en root. Il est donc de fait root.

jplemoine · Le 23/01/2024, à 17:04

jplemoine a écrit :

Sauf erreur de ma part, zenity permet juste d’améliorer la présentation des scripts : je ne vois pas de problème de sécurité à le lancer en root.

bruno a écrit :

Non ce n'est pas une question de point de vue, mais de sécurité de base.

En fait, je répondais à ma réflexion : "je ne vois pas de problème de sécurité" : En fait, zenity en lui-même ne pose pas de problème de sécurité.
C'est le fait de le lancer en root sans mot de passe qui pose problème.
Sinon (lancement en root avec demande de mot de passe), sauf erreur de ma part, tu as les mêmes droits qu'en console.
J'ai bon ?

bruno · Le 23/01/2024, à 18:04

Avec ou sans saisie de son mot de passe (avec ou sans NOPASSWD dans le sudoers) l'utilisateur tom aura de fait tous les droits root (cf. exemple en #8). Ce qui pose problème c'est de lancer zenity en tant root alors que l'utilisateur doit avoir des privilèges restreints.

Nuliel · Le 23/01/2024, à 20:42

Bonjour,
Juste pour info, je pense que juste mettre "zenity" dans le sudoers devrait pas poser de problème de sécurité puisque seule la commande zenity sans argument pourra être passée avec sudo. S'il y avait "zenity * " (et tout un tas d'autres équivalents) alors ce serait un problème. Et je pense aussi qu'il est important d'avoir le chemin absolu de zenity. Mais bon, dans tous les cas, mettre zenity comme commande dans sudoers c'est pas une bonne idée.
Sinon l'idée d'utiliser des binaires présents de base sur la distribution c'est une méthode pas mal utilisée (pour windows, on appelle cela les lolbas): https://gtfobins.github.io/

TuxLife · Le 30/01/2024, à 17:51

Bonjour à tous et permettez-moi avant tout de m'excuser du temps de réponse à mon propre post! De fait, je pensais recevoir une notification par mail d'une réponse à mon poste mais que neni!
MERCI pour vos réponses pertinentes et je reviens vers vous car j'ai trouvé le pourquoi du non-foctionement de mon sudoers.
Mon erreur vient très certainement de ma fatigue mais surtout du fait que j'ai tapé des minuscules en lieu de majuscules pour certains "ALL"...
@jplemoine: Merci de m'avoir averti au sujet de cette faille de sécurité à laquelle je n'avais clairement pas songé!
Je débute dans ce genre de manipulation et la communauté aide énormément!
Pour répondre, mon but est le suivant:
J'ai trois ados à la maison et chacun a en sa possession un ordinateur tournant sous Edubuntu avec accès internet mais ils abusent clairement du temps passé sur la toile alors je suis occupé à mettre en place un système de "crédit" heure internet avec un script au démarrage de la machine qui désactive leur carte réseau.
Une série de scripts réinitialisés chaque lundi à 17:00 qui, une fois exécutés, activent la carte réseau pour une durée de 1 heure ou 2 heures selon le script choisi. (avec messages à l'écran via Zenity)
Après ce délais, la carte réseau se désactive à nouveau avec un message d'avertissement.
D'où l'utilisation de IFCONFIG qui fonctionne parfaitement mais nécessite sudo pour cette tâche.
Pourquoi Zenity en root? J'ai remarqué que si je ne l'exécute pas en root, rien ne s'affiche!

J'ai à présent un autre coincement dû au fait que si ils ferment le terminal pendant "l'heure internet" le script s'arrête et la carte réseau ne se désactive pas le temps une fois écoulé. Logique... Je cherche là -dessus à présent.
Merci à tous!

bruno · Le 30/01/2024, à 18:07

nuliel a écrit :

je pense que juste mettre "zenity" dans le sudoers devrait pas poser de problème de sécurité puisque seule la commande zenity sans argument pourra être passée avec sudo.

Non pas avec la syntaxe utilisée ici. Il faut ajouter "" après zenity pour empêcher l'utilisateur de passer des arguments.

man sudoers a écrit :

A simple file name
allows the user to run the command with any arguments they wish. However, you may also specify command line argu‐
ments (including wildcards). Alternately, you can specify "" to indicate that the command may only be run without
command line arguments.

De manière générale sudoers est un outil dangereux à manier avec les plus grandes précautions.

Dernière modification par bruno (Le 31/01/2024, à 12:59)

bruno · Le 30/01/2024, à 18:23

@Tuxlife : tu peux désactiver une interface avec sudo et un utilisateur non privilégié peut relancer la connexion avec nmcli.

Démonstration :

[bruno@aboulafia:~]$ ping -c1 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=53 time=13.4 ms

--- 1.1.1.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 13.386/13.386/13.386/0.000 ms

[bruno@aboulafia:~]$ sudo ip link set enp3s0 down

[bruno@aboulafia:~]$ ping -c1 1.1.1.1
ping: connect: Le réseau n'est pas accessible

[bruno@aboulafia:~]$ nmcli connection up Connexion\ filaire\ 1 
Connexion activée (chemin D-Bus actif : /org/freedesktop/NetworkManager/ActiveConnection/4)

[bruno@aboulafia:~]$ ping -c1 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=53 time=13.4 ms

--- 1.1.1.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 13.431/13.431/13.431/0.000 ms

TuxLife · Le 31/01/2024, à 12:52

bruno a écrit :

@Tuxlife : tu peux désactiver une interface avec sudo et un utilisateur non privilégié peut relancer la connexion avec nmcli.

Démonstration :

[bruno@aboulafia:~]$ ping -c1 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=53 time=13.4 ms

--- 1.1.1.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 13.386/13.386/13.386/0.000 ms

[bruno@aboulafia:~]$ sudo ip link set enp3s0 down

[bruno@aboulafia:~]$ ping -c1 1.1.1.1
ping: connect: Le réseau n'est pas accessible

[bruno@aboulafia:~]$ nmcli connection up Connexion\ filaire\ 1 
Connexion activée (chemin D-Bus actif : /org/freedesktop/NetworkManager/ActiveConnection/4)

[bruno@aboulafia:~]$ ping -c1 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=53 time=13.4 ms

--- 1.1.1.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 13.431/13.431/13.431/0.000 ms

Merci beaucoup Bruno, de plus, hier soir j'ai fais un triste constat: il suffit de pousser sur le bouton wifi du portable pour réactiver la carte réseau... J'évolue et apprend de mes erreurs, là je pense agir du côté du firewall et désactiver les ports 80 et 443 afin de couper le trafic internet tout en restant connecté sur le réseau privé. Est-ce une bonne idée? Merci.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 23/01/2024, à 08:32

[Résolu] Sudoers via Visudo

#2 Le 23/01/2024, à 09:57

Re : [Résolu] Sudoers via Visudo

#3 Le 23/01/2024, à 10:10

Re : [Résolu] Sudoers via Visudo

#4 Le 23/01/2024, à 10:16

Re : [Résolu] Sudoers via Visudo

#5 Le 23/01/2024, à 10:38

Re : [Résolu] Sudoers via Visudo

#6 Le 23/01/2024, à 10:59

Re : [Résolu] Sudoers via Visudo

#7 Le 23/01/2024, à 16:10

Re : [Résolu] Sudoers via Visudo

#8 Le 23/01/2024, à 16:28

Re : [Résolu] Sudoers via Visudo

#9 Le 23/01/2024, à 17:04

Re : [Résolu] Sudoers via Visudo

#10 Le 23/01/2024, à 18:04

Re : [Résolu] Sudoers via Visudo

#11 Le 23/01/2024, à 20:42

Re : [Résolu] Sudoers via Visudo

#12 Le 30/01/2024, à 17:51

Re : [Résolu] Sudoers via Visudo

#13 Le 30/01/2024, à 18:07

Re : [Résolu] Sudoers via Visudo

#14 Le 30/01/2024, à 18:23

Re : [Résolu] Sudoers via Visudo

#15 Le 31/01/2024, à 12:52

Re : [Résolu] Sudoers via Visudo

Pied de page des forums