L'utilisation de CmndAlias ALLne sera jamais sûre
Il y a 1000 façons de fonctionner service network restartsans faire sudo service network restart. Voici un exemple de ce qu'un utilisateur méchant pourrait essayer:
$ echo "service network restart" > /tmp/hax
$ chmod a+x /tmp/hax
$ sudo /tmp/hax
Si vous fournissez aux utilisateurs l' ALLalias de commande, puis essayez de créer une liste noire, ils pourront toujours trouver un moyen de la contourner. Blacklist bash, et ils utiliseront python. Liste noire python, et ils utiliseront Perl. Mettez Perl en liste noire et ils utiliseront PHP. Personne ne veut ça!
Si vous ne voulez vraiment pas que quelqu'un fasse quelque chose, vous devez faire comme Thomas le dit et créer une liste blanche des choses qu'il est autorisé à faire.
Configuration d'une liste blanche avec une exception
Un exemple de petite liste blanche avec exclusion peut être trouvé vers le bas de man sudoers:
pete HPPA = /usr/bin/passwd [A-Za-z]*, !/usr/bin/passwd root
The user pete is allowed to change anyone's password except for root on the HPPA
machines. Note that this assumes passwd(1) does not take multiple user names
on the command line.
(En fait, cet exemple de la page de manuel n'est pas sûr et peut être exploité pour changer le mot de passe de root! Voir les commentaires ci-dessous pour savoir comment.)
Nous pouvons essayer d'adapter cela à votre cas, de proposer toutes les servicecommandes au groupe du personnel, mais d' exclure les service networkcommandes qui vous concernent:
%staff ALL = /usr/sbin/service *, \
! /usr/sbin/service *network*, \
! /usr/sbin/service *NetworkManager*
(Le ALLdans cette position fait référence à Host_Alias, pas à Cmnd_Alias - confus n'est-ce pas?)
L'utilisateur ne pourra pas exécuter sudo bashou sudo teeou sudo wgetou sudo /path/to/malicious_script. Vous pouvez ajouter à la liste blanche plus de commandes d'administration pour vos utilisateurs si vous faites attention. Soyez précis!
Remarque: J'ai ajouté l' *avant le mot networkci-dessus, juste au cas où un drapeau inoffensif serait ajouté à l' serviceoutil à l'avenir. Imaginons qu'un --verboseindicateur ait été ajouté à l'avenir, les utilisateurs pourront alors exécuter ce qui suit:
$ sudo service --verbose network restart
Nous avons donc besoin de *pour consommer tous les drapeaux avant le nom du service. Le seul inconvénient est que cela pourrait bloquer d'autres services qui ne gênent pas réellement les utilisateurs, par exemple un service appelé safe-networkou network-monitorserait également rejeté.
Autoriser les utilisateurs à modifier un fichier à l'aide des autorisations de groupe
Ci-dessous, vous trouverez différentes tentatives d'utilisation de rnanothrough sudopour permettre aux utilisateurs de modifier un ou plusieurs fichiers. Mais en réalité, ils sont plus complexes et plus dangereux qu'ils ne devraient l'être.
Une solution beaucoup plus simple et plus sûre consiste à modifier les autorisations de groupe sur les fichiers spécifiques pour lesquels vous souhaitez ouvrir les droits de modification. Voici quelques exemples:
### Give steve the ability to edit his nginx config:
$ chgrp steve /etc/nginx/sites-available/steves_dodgy_project
$ chmod g+rw /etc/nginx/sites-available/steves_dodgy_project
### Let all members of the staff group edit the group_website config:
$ chgrp staff /etc/nginx/sites-available/group_website
$ chmod g+rw /etc/nginx/sites-available/group_website
Si vous avez besoin d'un contrôle plus précis (par exemple: accès pour seulement 3 utilisateurs, mais pas pour tous les membres du personnel), vous pouvez créer un nouveau groupe à l'aide de la addgroupcommande et y ajouter seulement quelques utilisateurs.
Permettre aux utilisateurs de modifier un fichier via sudo
Le reste de cette réponse est devenu une enquête sur la facilité avec laquelle il est possible de laisser des trous dans votre sudoconfiguration lorsque vous essayez d'offrir de la flexibilité à vos utilisateurs. Je ne recommanderais pas de faire l'une des choses suivantes!
Si vous souhaitez autoriser vos utilisateurs à modifier un fichier spécifique, vous pouvez essayer d'utiliser rnano:
%staff ALL = /bin/rnano /etc/nginx/sites-available/host
rnanone leur permettra que de modifier le fichier spécifié. Cela est important pour empêcher un utilisateur malveillant de modifier un service différent (par exemple /etc/init.d/urandom) et d'y ajouter une ligne qui s'exécuterait service network restart.
Malheureusement, je n'ai pas trouvé de moyen de restreindre rvimsuffisamment (l'utilisateur peut toujours ouvrir n'importe quel fichier en utilisant :e), nous sommes donc coincés avec nano.
Malheureusement, permettre aux utilisateurs de modifier plusieurs fichiers est beaucoup plus difficile ...
Laissez les utilisateurs éditer plusieurs fichiers (beaucoup plus difficile qu'il ne devrait l'être)
1. Approches dangereuses
Attention aux caractères génériques! Si vous offrez trop de flexibilité (ou toute flexibilité), elle peut être exploitée:
%staff ALL = /bin/rnano /etc/nginx/sites-available/* # UNSAFE!
Dans ce cas, un utilisateur malveillant pourrait modifier tout autre script de service parvenu, puis l'exécuter:
$ sudo rnano /etc/nginx/sites-available/../../../any/file/on/the/system
(Sudo empêche .et ..développe réellement la commande, mais malheureusement pas les arguments.)
J'espérais que quelque chose comme ça pourrait fonctionner, mais ce n'est toujours pas sûr:
%staff ALL = /bin/rnano /etc/nginx/sites-available/[A-Za-z0-9_-]* # UNSAFE!
Étant donné sudoqu'actuellement ne propose que des modèles globaux , cela *correspondra à tout - ce n'est pas une expression régulière!
(Edit: J'ai envisagé si vous pouviez vous en sortir avec ce qui précède dans votre situation, car il n'y a pas de sous-dossiers en dessous sites-available. Nous avons demandé qu'un caractère soit mis en correspondance après le dossier, et /..devrait échouer après un nom de fichier. Cependant, ce n'est pas un solution réalisable, car rnanoaccepte plusieurs arguments. Et en général, cela ne serait pas sûr sur un dossier qui avait des sous-dossiers!)
Même si nous n'avons pas de sous-dossiers, et que nous excluons toutes les lignes contenant /../, la règle offrant un *glob pourrait toujours être exploitée, car rnanoaccepte plusieurs arguments (en les parcourant <C-X>, et l'espace est heureusement accepté par le *glob.
$ rnano /etc/nginx/sites-available/legal_file /then/any/file/on/the/system
2. Pousser l'enveloppe (également finalement dangereux)
Et si nous rejetons toutes les lignes contenant des espaces ou essayons d'atteindre /..? Ensuite, une solution finale réalisable pourrait être la suivante:
# I tried hard to make this safe, but in the end I failed again.
# Please don't use this unless you are really smart or really stupid.
%staff ALL = /bin/rnano /etc/nginx/sites-available/*, \
! /bin/rnano */..*, \
! /bin/rnano /etc/nginx/sites-available/, \
! /bin/rnano */., \
! /bin/rnano * *
# CONCLUSION: It is still NOT SAFE if there are any subfolders, due to
# the bug in rnano described below.
Nous acceptons tout ce qui est "sous" le dossier mais nous rejetons également tout appel à rnanosi /..ou /.ou /.exclusion rend l' /..exclusion redondante, mais j'ai laissé les deux pour plus de clarté.)
J'ai trouvé le dossier et les /.exclusions étaient nécessaires car sinon l'utilisateur pourrait cibler le dossier lui-même. Maintenant, vous pourriez penser rnanoque bloquerait si pointé vers un dossier, mais vous auriez tort. En fait, ma version (2.2.6-1ubuntu1) démarre avec un léger avertissement et un fichier vide, puis <C-X>me demande d'entrer le nom de fichier dans lequel je souhaite enregistrer, ouvrant un nouveau vecteur d'attaque! Eh bien, au moins, il a refusé d'écraser un fichier existant (dans le seul test que j'ai fait). Quoi qu'il en soit, puisqu'il n'y a aucun moyen de mettre les sous-dossiers sur liste noire avec sudo, nous devons conclure que cette approche est à nouveau dangereuse. Désolé les utilisateurs!
Cette découverte m'a fait douter de la rigueur du nanomode "restreint" de. Ils disent qu'une chaîne n'est aussi forte que son maillon le plus faible. Je commence à ressentir la combinaison de la sudoliste noire de la magie noire et je ne suis rnanopeut-être pas plus sûr qu'une chaîne de marguerites.
3. Approches sûres mais limitées
Les globes sont très restreints - ils ne nous permettent pas de faire correspondre plusieurs fois une classe de personnage. Vous pouvez proposer plusieurs modifications de fichiers si tous vos noms de fichiers ont la même longueur (dans ce cas, hostsuivis d'un seul chiffre):
%staff ALL = /bin/rnano /etc/nginx/sites-available/host[0-9] # SAFE
Mais si vous souhaitez autoriser l'utilisateur à modifier divers fichiers, vous devrez peut-être spécifier explicitement chaque fichier:
%staff ALL = /bin/rnano /etc/nginx/sites-available/hothost \
/bin/rnano /etc/nginx/sites-available/coldhost \ # SAFE
/bin/rnano /etc/nginx/sites-available/wethost \
/bin/rnano /etc/nginx/sites-available/steves_dodgy_project
Ne soyez pas tenté d'utiliser un*à tout moment. Voir les sections 1. et 2. ci-dessus pour savoir pourquoi! N'oubliez pas: une petite fiche peut compromettre l'ensemble du compte superutilisateur et l'ensemble du système.
4. Écrivez votre propre vérificateur d'arguments (la sécurité est maintenant de votre responsabilité)
J'espère qu'ils ajouteront un support regexp à sudol'avenir; il pourrait résoudre de nombreux problèmes s'il est utilisé correctement. Mais nous pouvons également avoir besoin de la possibilité de vérifier les propriétés des arguments (pour autoriser uniquement les fichiers, uniquement les dossiers ou uniquement certains indicateurs).
Mais il existe une alternative pour créer de la flexibilité dans sudo. Passez la balle:
%staff ALL = /root/bin/staffedit *
Ensuite, écrivez votre propre staffeditscript ou exécutable pour vérifier si les arguments transmis par l'utilisateur sont légaux, et exécutez leur demande uniquement s'ils le sont.
networkingetnetwork-manager? Aussi, pourquoi vos utilisateurs y ont-ilssudoaccès? Ils ne devraient pas, sauf si vous voulez qu'ils aient des privilèges root complets.