Dans quelle mesure la conservation des scripts non root dans /etc/init.d est-elle sécurisée?


15

J'ai une application qui fonctionne comme un démon et est contrôlée par un script dans /etc/init.d
Parfois, nous devons changer certains paramètres de démarrage / contrôle de ces scripts, puis redémarrer le démon. Ces scripts n'ont qu'une autorisation d'écriture pour l'utilisateur root, donc lors de la modification de ces scripts, j'ai besoin des privilèges root.

Ce que je pensais, c'est que devrais-je faire d'un utilisateur non root le propriétaire de ces scripts. De cette façon, seuls root et un utilisateur spécial peuvent modifier ces scripts.

Est-il acceptable de conserver certains fichiers n'appartenant pas à root dans les répertoires /etc/init.d?
Ou est-ce absurde, perturbant l'ordre naturel du système?


1
mauvaise idée, non.
ChuckCottrill

Réponses:


17

Ce qui me vient immédiatement à l'esprit, c'est qu'un utilisateur défavorisé peut exécuter des choses au démarrage en tant que root , ce qui est souhaitable pour les crackers qui:

  • Vous souhaitez augmenter les privilèges d'autres comptes
  • Vous souhaitez utiliser votre serveur pour héberger un service non autorisé
  • Vous voulez démarrer les robots IRC / Spam si le serveur redémarre
  • Vous voulez envoyer une requête ping à un vaisseau mère pour dire "Je suis de nouveau debout" et peut-être télécharger une nouvelle charge utile
  • Vous voulez nettoyer leurs pistes
  • ... autre méchanceté.

Cela est possible si votre utilisateur défavorisé est en quelque sorte compromis, peut-être par le biais d'un autre service (http / etc). La plupart des attaquants exécuteront rapidement un lsou findsur / de tout /etcjuste pour voir si de telles possibilités existent, il y a des shells écrits dans divers langages qu'ils utilisent qui rendent cela simple.

Si vous gérez le serveur à distance, principalement via SSH, il y a de fortes chances que vous ne le voyiez même pas à moins d'inspecter le script init, car vous ne verrez pas la sortie au démarrage (cependant, vous devriez utiliser quelque chose qui vérifie les hachages de ces scripts par rapport aux hachages connus pour voir si quelque chose a changé, ou un logiciel de contrôle de version, etc.)

Vous ne voulez certainement pas que cela se produise, root doit vraiment posséder ce script d'initialisation. Vous pouvez ajouter l'utilisateur de développement à la liste des sudoers afin qu'il soit suffisamment pratique pour mettre à jour le script, mais je vous conseillerais de ne pas autoriser l'accès en écriture défavorisé à quoi que ce soit dans init.d


5
tl; dr : Si vous faites cela, l'utilisateur non root est aussi bon que root au prochain démarrage. Vous suppliez d'être pwned.
Warren Young

9

En plus des très bons points soulevés par Tim Post, j'ajouterais que pour une configuration où plusieurs personnes doivent être capables de pousser les modifications sur un serveur, vous devriez envisager d'utiliser une sorte de système de gestion de configuration.

Si vous utilisez par exemple marionnette, chef, ou cfengine, vous pouvez demander aux utilisateurs concernés de modifier les fichiers localement, puis de pousser les modifications avec la gestion de la configuration. La façon exacte de configurer cela variera bien sûr en fonction du système que vous utilisez, mais correctement configurée, elle inclura un logiciel de version facilitant le retour à une version antérieure d'un fichier de configuration quand (remarque: quand , pas si !) quelqu'un a fait une erreur. Cela vous permettra également de copier plus facilement la configuration sur un système de test séparé, etc.


Garder vos scripts et même vos fichiers de données de configuration versionnés dans un système de gestion de configuration / version est une excellente idée, même sans considérer si un système pourrait être compromis.
ChuckCottrill

En effet - je l'ai utilisé pour corriger des erreurs sur quelques magnitudes plus souvent que je l'ai utilisé pour réparer un système compromis.
Jenny D

Merci beaucoup . Parce qu'ici, la plupart du temps, un utilisateur dédié utilise cette application, donc sudo fonctionne parfaitement et c'est ce que je faisais depuis longtemps. MAIS je suis vraiment très intéressé par le système de gestion de versions pour les configs. Chère Jenny, pouvez-vous me fournir une référence pour le faire OU TOUT EXEMPLE !! :).
Akaks

1
Si vous ne voulez pas suivre l'itinéraire complet marionnettes / chef / cfengine, etc., j'utiliserais personnellement www.perforce.com. Nous l'avons utilisé pour ~ 100 serveurs dans le temps avant l'existence de la marionnette et leur licence eval est suffisante pour un serveur. Le principal avantage est que vous pouvez extraire des fichiers VC à n'importe quel endroit du système de fichiers au lieu d'être limité à un sous-chemin. Les autres options sont joeyh.name/code/etckeeper , ou en utilisant n'importe quel VC combiné avec des scripts pour déplacer des fichiers vers le répertoire approprié.
Jenny D
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.