Je voudrais créer un nouvel utilisateur et lui donner un accès sudo. Pour être précis, je veux qu'il utilise sudo vimet édite 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?

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 tout 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 cela ne soit même pas requis): par exemple la configuration sudo
  :r /etc/sudoers REMARQUE: Sauf restriction par SELinux, l'utilisateur peut lire n'importe quel fichier de cette façon!
• s'octroyer 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 dont votre utilisateur peut désormais accéder, modifier ou 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é dans l'octroi de sudoprivilèges à n'importe quel éditeur.

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

Un deuxième risque, comme de nombreux autres commentateurs l'ont souligné, est qu'il vimpermet des échappements shell , où vous pouvez démarrer un sous-shell depuis 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 shell:

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

Que faire à la place?

Vous pouvez toujours utiliser sudopour permettre aux utilisateurs de modifier des fichiers dont ils ne sont pas propriétaires de manière sécurisée.

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

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

L'utilisateur peut ensuite utiliser le -ecommutateur dans sa ligne de commande sudo ou utiliser la sudoeditcommande:

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

Comme expliqué dans la page de manuel :

L' -e (edit)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 prises:

• Des copies temporaires sont faites des fichiers à éditer avec le propriétaire défini sur l'utilisateur appelant.
• L'éditeur spécifié par la stratégie est exécuté pour modifier les fichiers temporaires. La stratégie sudoers utilise les variables d'environnement SUDO_EDITOR, VISUAL et EDITOR (dans cet ordre). Si aucun SUDO_EDITOR, VISUAL ou EDITOR n'est défini, le premier programme répertorié dans l' sudoersoption éditeur (5) est utilisé.
• 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é avec l'environnement de l'utilisateur appelant non modifié. 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.

Le sudoersmanuel contient également une section complète sur la façon dont il peut offrir une protection limitée contre les échappements de shell avec les options RESRICTet NOEXEC.

restrict Évitez de donner aux utilisateurs l'accès aux commandes qui permettent à l'utilisateur d'exécuter des commandes arbitraires. De nombreux éditeurs ont un mode restreint où les échappements 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 shell, restreindre les utilisateurs à l'ensemble des programmes qui ne le sont pas est souvent impossible.

et

noexec
De nombreux systèmes qui prennent 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 ces 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 la NOEXECbalise comme indiqué dans la section Spécifications utilisateur ci-dessus. Voici cet exemple encore:
aaron shanty = NOEXEC: /usr/bin/more, /usr/bin/vi
Ceci permet à l' utilisateur d'exécuter aaron /usr/bin/moreet /usr/bin/viavec noexec activé. Cela empêchera ces deux commandes d'exécuter d'autres commandes (comme un shell).

Cette configuration permet à cet utilisateur de modifier ce fichier. Pour ce faire, il démarre un viméditeur avec les droits root.

Une fois la vimcommande lancée, l'utilisateur peut faire ce qu'il veut avec cet éditeur. - Il peut ouvrir un fichier différent ou même lancer un shell à partir de vim.

Par conséquent, l'utilisateur peut désormais afficher et modifier des fichiers arbitraires et exécuter des commandes arbitraires sur votre système.

Serrures de sécurité

Certains programmes, comme par exemple less, vi, vimet more, aux autres programmes à exécuter à partir d' une commande shell que l' on appelle évasion Shell ou échapper à l'interpréteur de commandes. Dans ces cas, vous pouvez utiliser NOEXECpour empêcher certains programmes d'autoriser l'exécution d'autres privilèges de programmes. Exemple:

fulano ALL = (ALL) ALL NOEXEC:  /bin/vi, /usr/bin/less, /usr/bin/vim, /bin/more

Cela permettrait à l'utilisateur de modifier ou non et de visualiser en mode privilégié n'importe quel fichier sur le système exécutant vim et plus, mais désactiverait la possibilité d'exécuter d'autres programmes avec des privilèges à partir de l'interpréteur de commandes d'échappement vim.

sudoComprend surtout plusieurs verrous de sécurité (par défaut) qui peuvent empêcher les tâches dangereuses, telles que la redirection de la sortie standard de l'exécution d'un programme ( STDOUT) vers des fichiers en dehors du répertoire de base de l'utilisateur.

S'il est défini dans le fichier /etc/sudoersqu'un utilisateur peut exécuter avec des privilèges /usr/bin/vim, c'est-à-dire quelque chose comme ceci:

fulano ALL = (ALL) /bin/echo, NOEXEC: /bin/vi, /usr/bin/vim, /bin/more, /usr/bin/less

sudo permet à l'utilisateur régulier défini de s'exécuter /usr/bin/vim des manières suivantes:

sudo /usr/bin/vim
sudo vim

Mais être empêché d'exécuter vim comme suit:

cd /usr/bin
sudo ./vim

La réponse simple:

Voici une commande Vim:

:shell

Ils ont maintenant un shell racine.

Une amélioration incrémentielle possible de la sécurité serait de remplacer:

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

avec

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

puis faites exécuter l'utilisateur à la sudo rvim /etc/httpd/confs/httpd.confplace.

Vim prend en charge un mode restreint déclenché avec l'option de ligne de commande -Z ou en démarrant le programme en tant que rvim. Lorsque le mode restreint est activé, "toutes les commandes utilisant un shell externe sont désactivées". Cette approche n'empêcherait pas l'utilisateur d'utiliser une :split filecommande ex pour ouvrir d'autres fichiers, mais au moins devrait empêcher des commandes shell délibérément malveillantes comme :!rm -rf /.

Je suis d'accord avec la réponse de HBruijn selon laquelle l'exécution de vim en tant que root ouvre le système très largement et sudoedit serait une solution plus sûre.

Mais même alors, votre système serait probablement encore assez ouvert. En supposant au moins qu'un processus apache avec des privilèges root sera lancé sur la base de cette configuration. Il existe un million de façons de configurer apache de telle manière qu'il exécute des programmes externes. À titre d'exemple, considérons l'argument pipe de la directive CustomLog . Le manuel indique explicitement:

Sécurité:

Si un programme est utilisé, il sera exécuté en tant qu'utilisateur qui a démarré httpd. Ce sera root si le serveur a été démarré par root; assurez-vous que le programme est sécurisé.

Évidemment, si vos utilisateurs peuvent écrire la configuration, ils peuvent changer ce programme en ce qu'ils veulent, par exemple quelque chose qui exécute un script shell pour leur accorder des autorisations supplémentaires.

Pour cette raison, j'ai récemment piraté ensemble un moyen d'utiliser les capacités de telle manière qu'apache puisse gagner la capacité spéciale de se lier à un port privilégié même s'il s'exécute autrement en tant qu'utilisateur normal. De cette façon, les utilisateurs peuvent modifier la configuration et même lancer le serveur, et sont toujours en grande partie sûrs. Le seul problème est qu'ils peuvent lier n'importe quel processus sur n'importe quelle IP. Un certain degré de confiance demeure, car ils pourraient éventuellement trouver un moyen de planter le sshd du système, puis de lancer leur propre version dans le but d'obtenir le mot de passe root.

Il convient de noter que même un sudoedit {.../whatever.conf}peut constituer un risque pour la sécurité.

Créer un script shell /tmp/make_me_root.sh

!#/bin/sh

if [[ ! `grep -c 'domscheit ALL=(ALL) NOPASSWD: ALL' /etc/sudoers` ]] ; then
    echo 'domscheit ALL=(ALL) NOPASSWD: ALL' >> /etc/sudoers
fi

et appelez ce script dans votre fichier de configuration. Je connais plusieurs exemples où cette approche fonctionne:

samba -> commande log nt token

log nt token command = /tmp/make_me_root.sh

syslog-ng -> programme: Envoi de messages à des applications externes

log { 
    source{ system() } ; 
    destination { program("/tmp/make_me_root.sh") };
}; 

Apache -> CustomLog

CustomLog "|/tmp/make_me_root.sh"

Je suppose que l'on peut étendre cette liste sans fin.

Il vous suffit de redémarrer le service. Bien sûr, une fois que vous êtes root, vous inverserez ces lignes de configuration afin de brouiller vos traces.

Bien sûr, ce n'est pas du tout plus sûr. Comme dit précédemment, sudoedit est la manière la plus simple et la plus appropriée de le faire.

Ce que je veux ajouter, c'est que vim permet de lancer un shell, donc, non seulement peut éditer n'importe quel fichier système, il permet également de lancer un shell et de faire où il veut.

Essayez simplement de lancer un vim et tapez: sh