Je voudrais créer un nouvel utilisateur et lui donner un accès sudo. Pour être précis, je veux qu'il utilise sudo vim et éditez httpd.conf. J'ai écrit ceci dans sudoers :

user ALL=(ALL) /usr/bin/vim /etc/httpd/confs/httpd.conf

J'ai cependant entendu dire que cela pouvait être risqué. Pourquoi est-ce problématique ? Quelle est la gravité du problème ?

Réponse acceptée :

Bien que vous restreigniez les arguments de la ligne de commande, rien n'empêche l'utilisateur d'utiliser vim pour ouvrir, modifier et écraser n'importe quel fichier aléatoire une fois qu'il s'exécute en tant que root.

L'utilisateur peut exécuter sudo vim /etc/httpd/conf/httpd.conf puis

• effacer tout ce texte du tampon d'édition
• puis, pour plus de commodité, sourcez un fichier existant (bien que ce ne soit même pas obligatoire) :par exemple la configuration sudo
  :r /etc/sudoers REMARQUE :Sauf restriction par SELinux, l'utilisateur peut lire tout déposer par ici !
• s'accorder plus de privilèges sudo user ALL=(ALL) NOPASSWD: ALL
• écraser l'ancienne configuration :w /etc/sudoers

Je peux imaginer des dizaines de façons similaires pour votre utilisateur d'accéder, de modifier ou de détruire votre système.

Vous n'aurez même pas de piste d'audit sur les fichiers qui ont été modifiés de cette manière, car vous ne le verrez que modifier votre configuration Apache dans les messages du journal sudo. Il s'agit d'un risque de sécurité lors de l'octroi de sudo privilèges à n'importe quel éditeur.

C'est plus ou moins la même raison pour laquelle accorder des droits de niveau racine sudo à des commandes telles que tar et unzip est souvent non sécurisé, rien ne vous empêche d'inclure des remplacements pour les binaires système ou les fichiers de configuration système dans l'archive.

Un deuxième risque, comme de nombreux autres commentateurs l'ont souligné, est que vim permet les échappements du shell , où vous pouvez démarrer un sous-shell à partir de vim qui vous permet d'exécuter n'importe quelle commande arbitraire . Depuis votre session sudo vim, ceux-ci s'exécuteront en tant que root, par exemple l'échappement du shell :

• :!/bin/bash vous donnera un shell root interactif
• :!/bin/rm -rf / fera de bonnes histoires dans le pub.

Que faire à la place ?

Vous pouvez toujours utiliser sudo pour permettre aux utilisateurs de modifier des fichiers qu'ils ne possèdent pas de manière sécurisée.

Dans votre configuration sudoers, vous pouvez définir une commande spéciale réservée sudoedit suivi du chemin d'accès complet (caractère générique) au(x) fichier(s) qu'un utilisateur peut modifier :

user ALL=(ALL) sudoedit /etc/httpd/conf/httpd.conf /etc/httpd/conf.d/*.conf

L'utilisateur peut alors utiliser le -e basculez dans leur ligne de commande sudo ou utilisez le sudoedit commande :

sudo -e /etc/httpd/conf/httpd.conf
sudoedit /etc/httpd/conf/httpd.conf

Comme expliqué dans la page de manuel :

Le -e (edit) L'option indique qu'au lieu d'exécuter une commande, l'utilisateur souhaite modifier un ou plusieurs fichiers. Au lieu d'une commande, la chaîne "sudoedit" est utilisée lors de la consultation de la politique de sécurité.
Si l'utilisateur est autorisé par la politique, les étapes suivantes sont suivies :

• Des copies temporaires sont faites des fichiers à modifier avec le propriétaire défini sur l'utilisateur appelant.
• L'éditeur spécifié par la règle est exécuté pour modifier les fichiers temporaires. La politique sudoers utilise les variables d'environnement SUDO_EDITOR, VISUAL et EDITOR (dans cet ordre). Si aucun de SUDO_EDITOR, VISUAL ou EDITOR n'est défini, le premier programme répertorié dans l'éditeur sudoers (5) l'option est utilisée.
• S'ils ont été modifiés, les fichiers temporaires sont recopiés à leur emplacement d'origine et les versions temporaires sont supprimées.
  Si le fichier spécifié n'existe pas, il sera créé.
  Notez que contrairement à la plupart des commandes exécutées par sudo, l'éditeur est exécuté sans modification de l'environnement de l'utilisateur appelant. Si, pour une raison quelconque, sudo n'est pas en mesure de mettre à jour un fichier avec sa version modifiée, l'utilisateur recevra un avertissement et la copie modifiée restera dans un fichier temporaire.

Les sudoers le manuel contient également une section entière expliquant comment il peut offrir une protection limitée contre les fuites d'obus avec le RESRICT et NOEXEC options.

restrict Évitez de donner aux utilisateurs l'accès aux commandes qui leur permettent d'exécuter des commandes arbitraires. De nombreux éditeurs ont un mode restreint dans lequel les échappements du shell sont désactivés, bien que sudoedit soit une meilleure solution pour exécuter des éditeurs via sudo. En raison du grand nombre de programmes qui offrent des échappements du shell, restreindre les utilisateurs à l'ensemble des programmes qui ne le font pas est souvent irréalisable.

et

noexec
De nombreux systèmes prenant en charge les bibliothèques partagées ont la possibilité de remplacer les fonctions de bibliothèque par défaut en pointant une variable d'environnement (généralement LD_PRELOAD) vers une autre bibliothèque partagée. Sur de tels systèmes, la fonctionnalité noexec de sudo peut être utilisée pour empêcher un programme exécuté par sudo d'exécuter d'autres programmes. Remarque, ... ...
Pour activer noexec pour une commande, utilisez le NOEXEC tag comme documenté dans la section Spécifications de l'utilisateur ci-dessus. Voici à nouveau cet exemple :
aaron shanty = NOEXEC: /usr/bin/more, /usr/bin/vi
Cela permet à l'utilisateur aaron d'exécuter /usr/bin/more et /usr/bin/vi avec noexec activé. Cela empêchera ces deux commandes d'exécuter d'autres commandes (comme un shell).