En général, il est impossible de savoir avec certitude - même un programme apparemment parfaitement sûr peut avoir des vulnérabilités qui signifient qu'il peut être utilisé pour des actions arbitraires - mais voici quelques points à vérifier :
Le programme effectue-t-il l'une des actions suivantes ?
- Révéler le contenu de fichiers ou d'appareils arbitraires
- Copiez, déplacez, écrivez ou supprimez des fichiers arbitraires.
- Définir/modifier des variables d'environnement arbitraires (qui seront récupérées par d'autres processus privilégiés) ou apporter des modifications arbitraires à des variables spécifiques.
- Invoquez des IOCTL ou interagissez avec des appareils arbitraires.
- Modifier la propriété ou les autorisations sur des fichiers arbitraires.
- Montez des systèmes de fichiers arbitraires ou modifiez les options de montage sur les systèmes existants.
- Autoriser l'accès direct à la mémoire du système ou d'un processus arbitraire (tel qu'un débogueur).
- Autoriser le lancement de programmes arbitraires.
Tout programme qui fait l'un de ces éléments n'est pas sûr d'accorder à un utilisateur à faibles privilèges sudo accès à. Cela exclut, par exemple, tout programme ayant la possibilité de spécifier un fichier de sortie (généralement via un -o ou -f paramètre), traiter un fichier d'entrée d'une manière qui révèle son contenu (même via un message d'erreur suffisamment informatif indiquant que le format d'entrée est erroné) et la grande majorité des exécutions de script (y compris les shells).
Si vous remplacez arbitraire dans ces chèques avec limité ou spécifique , alors vous avez repoussé le problème d'une étape (ou plusieurs) :faites n'importe laquelle des choses que le programme peut faire mener à de tels événements arbitraires, peut-être à travers de multiples niveaux d'indirection ? Par exemple, si votre programme permet à l'utilisateur de définir une variable d'environnement unique, cela obligera un programme privilégié à lire un fichier différent de celui attendu, et ce fichier différent obligera le système à autoriser les utilisateurs à monter un fichier image de leur choix comme un système de fichiers avec le setuid peu respecté, vous ne devez pas autoriser les utilisateurs non fiables à exécuter ce programme.
Cependant, ce n'est pas parce qu'un programme réussit toutes ces vérifications qu'il est réellement sûr. Par exemple, s'il effectue certaines actions réseau (telles que l'écoute sur des ports restreints ou l'envoi de paquets bruts), il peut être dangereux car il peut y avoir un autre programme sur le réseau (ou sur la même machine) en supposant que chaque processus capable de le faire les choses appartiennent à un utilisateur de confiance - après tout, ces actions nécessitent root - et vous avez rompu cette hypothèse. De plus, la liste des puces ci-dessus n'est que des choses auxquelles j'ai pensé en quelques minutes; il y a presque certainement des moyens d'escalader les privilèges que je n'ai pas inclus.
Enfin, comme pour toutes les questions de sécurité, cela dépend de votre modèle de menace.
- L'attaquant (utilisateur non approuvé) est-il proche de la machine avec un accès physique, ou est-il distant ? Il est extrêmement difficile d'empêcher un attaquant déterminé disposant d'un accès physique de devenir root, surtout s'il doit pouvoir (re)démarrer la machine sans assistance, alors réfléchissez aux risques que vous êtes prêt à accepter.
- La machine est-elle partagée entre les utilisateurs ? Ensuite, vous devez envisager des attaques inter-utilisateurs supplémentaires, telles que le déni de service (en consommant des ressources excessives ou en rendant la machine inutilisable).
- Exigez-vous la non-répudiation (la capacité de prouver qui a fait quelque chose) ? Ensuite, vous devez vous assurer que vous pouvez lier toutes les actions effectuées via
sudoà l'utilisateur qui les a faites. - Avez-vous besoin d'empêcher l'utilisateur de faire certaines choses que même un utilisateur non root peut généralement faire (comme exécuter des programmes arbitraires dans son propre contexte utilisateur même si ces programmes sont des choses comme des jeux ou des cryptomineurs, ou ouvrir un client TCP connexions à des hôtes et des ports arbitraires) ? Ensuite, vous devez également considérer les moyens par lesquels vous appliquez cette restriction et empêcher l'exécution en tant que sudo de tout programme qui pourrait permettre à l'utilisateur de contourner la restriction.
Etc. Une réponse vraiment complète ne sera pas possible ici; ça dépend de trop de choses. Cependant, je dirai ceci :c'est très difficile pour s'assurer qu'un utilisateur non approuvé, étant donné la possibilité d'exécuter en tant que root tout programme non trivial (qui n'a pas été explicitement conçu pour être exécuté en toute sécurité de cette façon), ne peut pas faire quelque chose d'inattendu. Même si l'un de ces programmes n'autorise rien que vous jugez important d'empêcher, il peut être possible d'enchaîner plusieurs programmes de ce type pour atteindre l'objectif de l'attaquant.
Cela se résume essentiellement au problème d'arrêt, vous pouvez auditer le code ou désosser le binaire, mais même s'il n'y a pas de "fonctionnalités" qui vous permettent d'exécuter des commandes arbitraires, il pourrait toujours y avoir des vulnérabilités dans le binaire ou sudo lui-même qui pourraient conduire à exécution arbitraire de commandes en tant que root pour les utilisateurs activés.