C'est depuis toujours mon idéologie qu'en tant qu'utilisateur, vous pouvez faire ce que vous voulez sous Linux et pour tout le reste, il y en a toujours sudo. sudopermet d'exécuter peu de choses que d'autres utilisateurs, le plus souvent dans le cas de l' rootadministration système. sudoa été une ressource plus avantageuse pour déléguer certaines de mes tâches courantes et privilèges en tant qu’utilisateur (root) à d’autres et pour aider à mieux gérer mon temps et le temps des autres sans élever les privilèges au-delà de ce qui est requis. Dans le même temps, c’est ma confiance en eux qui garde leurs entrées présentes dans lesudoersfichier de configuration. Je ne sais pas si cela pourrait être lié, mais que puis-je dire, c’est que sudo vous donne une meilleure perspective de sécurité pour savoir qui est tout et que peut-il faire avec ses privilèges de confiance. Même si quelque chose ne va pas, ils restent responsables. (Je peux toujours faire quelques pointes sournoises avec des informations de journal sudoers pour trouver les coupables également). Mes gars m'ont toujours dit qu'ils devaient taper sudo pour tout ce qu'ils voulaient faire avec des privilèges élevés dans un environnement Linux. Ici, j'ai trouvé la même question aussi.
Pour voir les solutions et ma quête pour trouver des alternatives, je suis tombé sur les contrôles d’accès basés sur les ressources,RBAC mais dans une autre aventure Solarisavec des outils tels que pfexecetc. sur la conscience et la vigilance de ce que les administrateurs système voudraient faire de leurs privilèges.
Considérant les solutions disponibles de RBAC et ses implémentations dans le monde Linux, je suis tombé par hasard sur
SELinux http://www.ibm.com/developerworks/linux/library/l-rbac-selinux/
grsecurity http://en.wikipedia.org/wiki/Grsecurity
et bien qu'il y ait d'autres implémentations, je les considérerais dans le haut de la liste. L'implémentation de RBAC représente un travail considérable dans une organisation, en particulier lorsque les utilisateurs sont nombreux. RBAC semblerait une meilleure solution dans des environnements homogènes. Cependant, lorsqu'il existe des installations Unix hétérogènes sur le réseau et que la base de données des utilisateurs est commune, cela pourrait peut-être échouer. SELinux n'étant pas évolutif / implémenté sous Solaris, les outils RBAC / pfexec ne sont pas implémentés sous Linux. Différentes approches existent pour faire une seule chose. Par exemple: http://blogs.oracle.com/darren/entry/opensolaris_rbac_vs_sudo_howto
Différentes installations à l'échelle du réseau peuvent ne pas prendre en charge cette approche (cependant, openrbac pourrait être considéré comme une approche d'implémentation commune), comme sudoers est une approche à hôte unique ou n'est pas capable de configuration centralisée dans le réseau / domaine./etc/sudoersbesoin d'être synchronisé à chaque changement. De plus, il existe une exigence de base de connaissances lors de l’exploitation du fichier sudoers: il est nécessaire de comprendre le langage de politique de la configuration de sudoers afin de ne commettre aucune erreur et d’autoriser les octrois. RBAC peut offrir une approche centralisée dans une certaine mesure, tandis que les profils de sécurité peuvent être communs, l’ajout / la suppression d’un utilisateur du rôle attribué peut être effectuée à partir d’un seul endroit (c’est-à-dire l’endroit où les informations utilisateur / mot de passe / groupe sont stockées domaine comme LDAP, NIS ou AD). Cela impliquerait également implicitement de comprendre les commandes nécessaires pour opérer sur la base de données RBAC, telles que smexec, smmultiuser, étant peu nombreuses.
Sudo peut offrir une approche plus multiplateforme, même dans ce cas, il fonctionne sur toutes les plates-formes Unix / similaires qui offrent les fonctionnalités setuid. sudoEt tous deux RBACréussissent à donner aux utilisateurs non-root des privilèges qui peuvent être obtenus sans donner le rootmot de passe lui-même. Sudo peut donner une approche plus fine / granulaire sur les arguments de ligne de commande pouvant être utilisés lors de l'exécution des commandes et limiter uniquement les commandes avec arguments pouvant être exécutées avec des privilèges élevés. Bien que RBAC puisse restreindre l'utilisation des commandes ou des fichiers binaires installés sans avoir le moindre contrôle sur les arguments de ligne de commande. L’audit est bien meilleur et intégré à l’environnement RBAC alors quesudoCela dépend de la configuration et des contraintes de sécurité (par exemple, ne pas accorder le shell et en particulier, les hôtes sont autorisés à se connecter aux autres hôtes sans aucun problème). Ce ne sont là que quelques-unes des différences que je pourrais citer. Personnellement, j’ai tendance à utiliser le sudo plutôt que le RBAC, bien qu’avec ces limitations, je puisse surmonter certaines difficultés. Jusqu'à ce que tous les problèmes soient résolus par RBAC afin de mieux tirer parti de sudo, je ne pense pas que sudo disparaîtra, car c'est simple.