Est-ce un risque pour la sécurité d'exécuter mes tâches crontab en tant que root?


8

J'ai quelques tâches cron que j'exécute - principalement des choses liées à la sauvegarde.

Je dois faire une sauvegarde bloquée comme / etc / apache2 / sites / available etc, qui nécessite un accès root.

J'ai quelques questions:

Lors de l'exécution sur un serveur sans tête:

  1. Sous quel utilisateur le script est-il exécuté (en supposant que je ne spécifie pas d'utilisateur dans l'entrée de tâche cron)?
  2. Est-il correct d'exécuter le script de sauvegarde en tant que root - ou cela pose-t-il une question de sécurité?

BTW, mon serveur exécute Ubuntu 10.0.4 LTS

Réponses:


15

Si vous avez suffisamment accès au script et pris des précautions raisonnables, exécuter quelque chose à partir de root crontab n'est généralement pas un risque pour la sécurité.

Mais n'exécutez pas un script en tant que root qu'un utilisateur non root peut modifier ou écraser. Cela s'applique aux travaux exécutés à partir de cron ainsi que de manière interactive.

Si ce script comprend d'autres fichiers, la même chose s'applique également à eux.

En cas de doute, utilisez toujours le principe du moindre privilège. Si vous n'êtes toujours pas sûr, vous pouvez toujours poser des questions spécifiques sur les forums et dans IRC.


Il y a (presque) toujours un moyen d'exécuter quelque chose en tant qu'utilisateur non root. Si tout le reste échoue, l'utilisation de sudo pour limiter un utilisateur à des commandes spécifiques limite également le risque de faire du mal.

Donc, avec l'exemple que vous avez donné de sauvegarde de / etc / apache2 / sites-available, ce fichier est par défaut lisible par n'importe qui, ce qui implique qu'il s'agit d'un accès à la destination accessible en écriture uniquement par root.

Vous pouvez résoudre ce problème en

  • créer un groupe appelé backupadmins (par exemple)
  • définissez le groupe sur le répertoire de destination sur backupadmins
  • ajouter un utilisateur appelé backupuser (par exemple)
  • ajoutez l'utilisateur backupuser aux administrateurs de sauvegarde de groupe.
  • rendre le répertoire accessible en écriture par le groupe backupadmins
  • exécutez la tâche cron à partir de la crontab de backupuser.

+1 pour les instructions utiles, étape par étape. Votre réponse a été extrêmement utile. J'avais l'intention de suivre ce chemin de toute façon, mais comme c'était la première fois que je le faisais, il est rassurant de voir qu'il est recommandé ici (et beaucoup de gens semblent d'accord avec votre recommandation).
user35402

BTW, si je crée le groupe d'utilisateurs et l'utilisateur comme vous le suggérez, pourrai-je accéder à / etc / apache / sites-available et à d'autres dossiers qui sont (à juste titre), limités à un accès root uniquement?. Comment contourner ce problème?
user35402

3

Cela dépend de ce que font les scripts. S'ils sont en train de sauvegarder des trucs, il est probablement très bien qu'ils soient root - si un utilisateur malveillant écrase ces scripts, vous avez probablement de plus gros problèmes de toute façon.

S'ils font des choses stupides comme exécuter des fichiers trouvés dans des répertoires, ou tout ce qui pourrait être influencé par le contenu des répertoires Web, alors vous devrez probablement chercher des alternatives.


2

Partout dans le monde, des millions de tâches cron sont exécutées en tant que root tous les jours (ou quelle que soit la période définie).

L'important est que les autorisations appropriées soient définies. Si vous exécutez quelque chose qui est accessible en écriture à tout le monde, un utilisateur ou un processus malveillant pourrait changer ce qu'il fait.

Les tâches Cron sont généralement gérées par le propriétaire de la crontab. Un utilisateur crontab peut être /var/spool/cron/crontabs/usernamepar exemple. Cronjobs qui sont /etc/crontab,/etc/cron.d/ ou /etc/cron.hourly(quotidienne, hebdomadaire, mensuelle) seront gérés par la racine. Il est important que la propriété et les autorisations soient également correctes pour ces fichiers crontab.

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.