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

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?

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

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.