2017-06-10 1 views
0

Je suis tenté d'utiliserExiste-t-il des dangers pour setuid avec l'autorisation root sur updatedb?

# chmod u+s /usr/bin/updatedb 

pour pouvoir courir partout, partout. Y a-t-il une raison pour laquelle je ne devrais pas? Je veux dire, cela augmente-t-il l'insécurité dans mon système, sachant que seul l'utilisateur root peut utiliser updatedb, alors que tout le monde peut utiliser locate?

+1

Pourquoi quelqu'un * * autre que 'root' doivent exécuter' updatedb'? Il y a un risque avec * n'importe quel code qui fonctionne comme root, car chaque programme est un vecteur pour une attaque. Les programmes devraient fonctionner uniquement avec les permissions dont ils ont besoin, et rien de plus. – chepner

+0

parce que quand je crée/copie des fichiers sur mon ordinateur (git, etc) je dois mettre à jourb pour utiliser locate sur les nouveaux fichiers. Je n'utilise pas sudo car je ne veux pas que mon compte ait ces droits. Donc quand je git clone, je dois su - root, updatedb pour se déconnecter. c'est vraiment merdique –

+0

Vous pouvez configurer 'sudo' pour que la chose * only * que vous pouvez utiliser avec' sudo' soit 'updatedb'. – chepner

Répondre

0

La principale raison pour laquelle je peux penser est que updatedb est pas déjà setuid dans une distro que je connaisse, il pourrait ne pas avoir été examiné dans la mesure où un programme normalement setuid aurait été. Même locate est seulement SETGID Arch Linux:

$ stat --format %A $(which locate) 
-rwxr-sr-x 

Cela signifie qu'il est exécuté avec le groupe du propriétaire du fichier:

$ stat --format %G $(which locate) 
locate 

Il est exécuté en tant que groupe « localiser », mais en tant qu'utilisateur d'origine. Cela minimise la surface d'attaque à laquelle le groupe "locate" a accès, qui est probablement la seule base de données de localisation. Setid et setgid sont très rarement des choses dont vous avez besoin pour vous changer en tant qu'utilisateur (je n'ai jamais eu besoin de plus de 10 ans d'utilisation de Linux). Executables de paquets sont setuid ou setgid lors de l'installation si elles doivent être, comme locate ci-dessus ou sans doute le plus célèbre programme setuid, sudo:

$ stat --format %A $(which sudo) 
-rwsr-xr-x 

updatedb est généralement géré par une tâche cron. Si cela ne suffit pas souvent pour vous que vous avez plusieurs alternatives:

  • Run sudo updatedb (pas besoin su) chaque fois que vous voulez une liste de fichiers mis à jour.
  • Augmentez la fréquence du travail cron. Cela peut être remplacé lors de la prochaine mise à jour du paquet qui a installé le travail cron en premier lieu, mais d'un autre côté, il peut simplement ajouter un autre travail cron.
  • Ajoutez un autre travail cron avec une fréquence plus élevée.
  • Exécutez un service en tant qu'utilisateur root pour surveiller les répertoires importants pour les modifications et exécuter updatedb lorsque des fichiers sont ajoutés ou supprimés. Cela pourrait déjà exister (je ne sais pas), ou vous pouvez créer votre propre avec inotifywait. Assurez-vous simplement de deux choses:
    1. Ne pas regarder votre disque entier pour les changements, car il sera en cours d'exécution updatedb constamment.
    2. Ne pas exécuter un updatedbpar fichier modifier, car vous pourriez alors exécuter des milliers dos à dos.
+0

voulez-vous dire que si j'installe un paquet (via apt dans mon cas) il sera automatiquement setuid si configuré comme ça? –

+0

J'aime l'idée de surveiller un répertoire spécifique pour lancer updatedb. Mais y a-t-il des vulnérabilités à permettre à un utilisateur d'exécuter du code en tant que root (comme su does, iirc) si ce code est toujours exécuté en tant que root et semble aussi "innocent" que updatedb? Disons que quelqu'un avec de mauvaises intentions a accès à updatedb. que peut-il faire ? –

+0

C'est une question très différente, et peut-être plus appropriée pour security.SE ou unix.SE. – l0b0