Question Limiter l'utilisation de `sudo -s`


J'installe Nagios sur certains de mes serveurs Linux et j'ai un problème. le check_ide_smart plugin nécessite un accès root au système pour fonctionner. Pour l'exécuter, j'utilise le check_by_ssh plug-in pour ssh dans le compte nagios sur l'hôte distant, puis exécutez check_ide_smart en utilisant sudo.

J'ai initialement ajouté les lignes suivantes à /etc/sudoers pour permettre au programme de fonctionner:

nagios  ALL=NOPASSWD: /usr/lib/nagios/plugins/check_ide_smart

Bien que cela fonctionne très bien lorsqu'il est exécuté localement, je rencontrais un problème lorsqu'il était exécuté depuis Nagios: aucun téléscripteur n'était généré, ce qui empêchait le plugin de fonctionner.

J'ai creusé dans la page de manuel de sudo et trouvé l'option -s, qui génère un shell et exécute le programme. Quand j'ai essayé d'utiliser sudo -s, J’ai rencontré des problèmes d’autorisation puisque le -s change apparemment la commande en /bin/bash -c /usr/lib/nagios/plugins/check_ide_smart, ce qui n'est pas autorisé par le fichier sudoers. J'ai essayé de changer le fichier sudoers pour utiliser cette commande à la place, mais cela n'a pas fonctionné et utiliser des guillemets est une erreur de syntaxe.

Je l’ai finalement fait fonctionner en utilisant la ligne suivante /etc/sudoers:

nagios ALL=/bin/bash

Cela me semble vraiment faux, car je permets à l'utilisateur de nagios de créer un shell racine avec lequel il peut tout faire.

À ce stade, je pensais que peut-être, en plaçant la commande dans un script shell sur lequel l'utilisateur nagios aurait des privilèges de lecture seule, fonctionnerait, j'ai donc créé un script shell:

#!/bin/sh
/bin/bash -c /usr/lib/nagios/plugins/check_ide_plugin $@

Malheureusement, je n’ai jamais pu obtenir les paramètres passés ($@) pour fonctionner correctement avec le plugin, donc je ne sais pas si cela fonctionnerait.  Modifier: J'avais besoin de citer le $@ pour que cela fonctionne. Merci @derobert et @pjz. Je ne sais toujours pas si cela fonctionnerait depuis que je l'ai fait fonctionner en utilisant la solution de @ Mike Arthur.

Y at-il un moyen que je peux obtenir sudo -s travailler sans permettre la génération d'une coque racine?

Réponse:

Ajout de la ligne suivante à /etc/sudoers:

nagios ALL=NOPASSWD: /bin/bash -c /usr/lib/nagios/plugins/check_ide_smart *

Notez l'astérisque de fin; sans cela, cela ne fonctionne pas. Merci @ Mike Arthur pour la réponse.


8
2018-05-07 15:12


origine




Réponses:


nagios ALL=NOPASSWD: /bin/bash -c /usr/lib/nagios/plugins/check_ide_smart *

Cela devrait fonctionner et permettre des arguments.


7
2018-05-07 15:15



Ça n'a pas marché. Voir mon édition pour plus de détails. - Chris Lieb
@Chris Lieb: vous devrez changer votre appel de "sudo -s ..." à "sudo / bin / bash -c ...". Alors ça devrait marcher. J'ai une configuration similaire qui fonctionne ici (pas Nagios, mais similaire). - Martin C.
Je l'ai corrigé, essayez-le maintenant (avec l'astérisque pour les caractères génériques). - Mike McQuaid
L'astérisque l'a fait. Merci. - Chris Lieb


Pour votre information, vous devez citer $ @ dans votre script shell pour que tout fonctionne correctement:

#!/bin/sh
/bin/bash -c /usr/lib/nagios/plugins/check_ide_plugin "$@"

$@ est magique. De la page de manuel bash,

@ Se développe jusqu'aux paramètres de position, en commençant par un. Quand   le développement se fait entre guillemets, chaque paramètre   se développe en un mot séparé. C'est-à-dire que "$ @" est équivalent à "$ 1"   "$ 2" ... Si l'expansion double-citée se produit dans un mot,   le développement du premier paramètre est joint au   début du mot original et l’extension du   le dernier paramètre est joint à la dernière partie de l'original   mot. Quand il n'y a pas de paramètre de position, "$ @" et $ @   développer à rien (c'est-à-dire qu'ils sont supprimés).

De plus, le démarrage de bash ne fera pas apparaître un pty; Bien que je sois perplexe quant à la raison pour laquelle votre plugin Nagios a besoin d’un terminal pour fonctionner. Il ne devrait pas. Peut-être que le problème actuel est l'assainissement de l'environnement de sudo?


2
2018-05-07 16:06



Ce plugin est le seul à avoir posé problème. Aucun des autres que j'ai configurés jusqu'à présent ne nécessite un accès root. Je n'ai donc pas eu besoin d'utiliser sudo pour eux. Pour cette raison, je ne sais pas si le problème est causé par le fait que sudo ne génère pas de shell ou par le plug-in check_ide_smart nécessitant l'exécution d'un shell. - Chris Lieb


À la place d'utiliser sudo -s et en lançant un shell root, permettez à votre utilisateur nagios d’utiliser sudo sans utiliser de tty. !requiretty. Votre /etc/sudoers devrait avoir les éléments suivants:

# Allow Nagios extra privs
Defaults:nagios !requiretty
nagios ALL=NOPASSWD: /usr/lib/nagios/plugins/check_ide_plugin

... qui permettra un accès direct au sudo, sans mot de passe ni tty. Vous pouvez laisser le "check_ide_plugin" désactivé si vous voulez un accès sudo à tous les plugins.

Nous utilisons également NRPE, ce qui semble un peu plus sûr que check_by_ssh, mais cela nécessite un peu plus de configuration. Même idée dans / etc / sudoers, échangez simplement nagios avec nrpe. :)

~ Tommy


1
2018-04-02 23:37





Essayez le script à nouveau mais mettez des guillemets autour de votre $ @:

#!/bin/sh
/bin/bash -c /usr/lib/nagios/plugins/check_ide_plugin "$@"

0
2018-05-07 16:06





Je ne pense pas qu'il soit possible d'utiliser -s sans générer un shell root (en supposant que vous ayez besoin des privilèges root). L'option -s est spécifiquement là pour générer un shell. C'est ce que -s signifie. De sudo (8):

-s [command]
    The -s (shell) option runs the shell specified by the SHELL
    environment variable if it is set or the shell as specified
    in passwd(5).  If a command is specified, it is passed to
    the shell for execution.  Otherwise, an interactive shell
    is executed.

-1
2018-05-07 16:12



Un shell est exécuté, mais son courant est de permettre tout appel à /bin/bash, qui permet également la création d’un shell interactif sans aucune limitation ni restriction quant aux commandes pouvant être appelées. - Martin C.