Les administrateurs de sécurité sont responsables de votre machine et de ce qui se passe sur votre machine. Cette responsabilité viole le modèle de sécurité de base pour une machine Unix mono-utilisateur car l'administrateur (une partie absente) est root sur votre machine, vous n'êtes pas. Unix n'est pas vraiment configuré pour ce modèle.

Les administrateurs doivent pouvoir installer des contrôles de sécurité sur votre machine afin de protéger l'entreprise, pas seulement les données, le réseau et les autres nœuds. Si l'utilisateur local disposait d'un accès root, les administrateurs ne contrôlent plus ces contrôles. C'est le principe de base.

Oui, il y a des tonnes de raisons pour lesquelles root est nécessaire pour faire de mauvaises choses ou pour transformer la machine en un nœud malveillant et toutes ces raisons sont de bonnes raisons de ne pas fournir un accès root. Et oui, il existe de nombreuses façons de contourner ces limitations et de nombreuses façons pour l'utilisateur local de faire de mauvaises choses. Mais en fin de compte, l'utilisateur local et le propriétaire des risques ne peuvent pas être en concurrence pour le contrôle ou la responsabilité de la machine.

Quelques raisons qui me viennent à l'esprit:

• L'empoisonnement ARP ou les attaques par inondation de réseau sur le réseau nécessiteraient généralement un accès root à une machine sur le réseau.

• Pouvoir installer des programmes non autorisés pourrait exposer l'entreprise à une responsabilité légale si ces programmes sont eux-mêmes illégaux (par exemple parce qu'ils sont piratés ou ne sont pas autorisés à des fins lucratives ou autre).

• Si l'entreprise a une sorte de surveillance à distance des employés (ou souhaite avoir la possibilité d'avoir une telle surveillance même si elle n'est pas encore en place), donner aux utilisateurs un accès root leur permettrait pour contourner cela.

• Ne pas avoir d'accès root signifie que vous ne pouvez pas rm -rf / bin , ou un certain nombre d'autres choses destructrices, et ni toute personne ayant accès à vos informations de connexion peut-elle accéder à vos informations de connexion, il n'y a donc aucune chance que votre entreprise ait besoin de vous aider à vous remettre de cette situation.

• Si votre entreprise pourrait redéployer votre machine si vous partez , ils pourraient se sentir plus à l'aise de le faire avec faire un nettoyage complet et une réinstallation si vous n'y avez jamais eu accès root.

• Donner aux gens un accès root est facile, si cela devient nécessaire; supprimer complètement l'accès root est difficile si cela devient nécessaire.

• Le principe général du moindre privilège est que vous ne devez donner accès à personne / à rien ils n'en ont pas activement besoin.

• Simplement ne pas avoir quitté l'époque des serveurs partagés parce que c'est un processus qui a fonctionné et que rien n'a brisé l'inertie (l'hypothétique problème des singes et des échelles).

Cette réponse ne vise pas à contredire les réponses existantes, mais plutôt à les compléter car elle est trop longue pour un commentaire.

Une partie de la raison est (comme d'autres l'ont fait allusion) que les utilisateurs ne peuvent pas faire confiance à ne pas faire de choses insensées / malveillantes. Mais une autre partie est de savoir à qui incombe la responsabilité de réparer les choses lorsque cela se produit?

Je suis un développeur full-stack et des développeurs à temps partiel avec un accès root non seulement à mes propres machines de développement, mais à un certain nombre de notre production serveurs et au moins un certain niveau d'accès à l'hyperviseur sur lequel ils sont déployés. Mais si je me trompe, je suis la partie (ou au moins une partie) avec les compétences, l'expertise et la responsabilité pour y remédier. Ce n'est pas le cas de l'utilisateur final typique: si Bobby l'utilisateur effectue son installation Windows qui contenait des données critiques et / ou était utilisé pour un travail critique, alors Bobby n'est pas celui qui doit intervenir sur son / sa journée de congé ou de faire des heures supplémentaires non rémunérées pour y remédier. Sans parler de la réponse à la comment Bobby a réussi à couler presque à lui seul le navire.

Les services informatiques limitent donc les privilèges des utilisateurs finaux en partie parce que cela réduit les leurs exposition au risque.

AFAIK, il y a 4 raisons principales pour ne pas donner accès administrateur aux utilisateurs standard sur leurs bureaux:

• protéger la machine elle-même (pas toujours très efficace) et les autres machines du réseau contre d'éventuelles attaques utilisant cette machine comme relais (déjà couvertes par d'autres réponses)
• protègent l'équipe de support informatique contre les attaques de niveau administrateur qui nécessiteront beaucoup de travail pour corriger (déjà couvert par d'autres réponses)
• conserver toutes les machines avec (plus ou moins) la même configuration pour pouvoir faire simplement des déploiements à distance à partir d'une seule machine d'administration - la plus petite taille de l'équipe de support, la moins chère pour le entreprise
• empêcher (ou au moins essayer de) les utilisateurs d'installer des programmes sans rapport avec leur travail - un utilisateur jouant à des jeux au travail ou concevoir sa future cuisine n'est pas très productif ...

Mais il ne peut pas protéger les données sur la machine ni plus généralement les données accessibles à l'utilisateur, être sur la machine locale ou sur un serveur. C'est là que les sauvegardes viennent à la rescousse.

Votre machine n'est pas uniquement utilisée par vous. Il est également utilisé par votre équipe de support de bureau.

Si j'ai un accès root à une boîte - en particulier une boîte Windows jointe à un domaine - je peux installer n'importe quel nombre d'astuces différentes que je pourrais utiliser pour compromettre tout autre utilisateur de la boîte. Disons, par exemple, un keylogger.

Ensuite, tout ce que j'ai à faire est de persuader un ingénieur du support de se connecter pour résoudre un "problème" fraîchement fabriqué (comme casser le secret partagé de Kerberos), attendez-les pour passer à l'administrateur de domaine et je viens de compromettre l'ensemble du réseau.

Le keylogger ne sera-t-il pas détecté par le scanner de logiciels malveillants? Pas si j'ai root, ce ne sera pas le cas.

Vous obtenez ce dont vous avez besoin pour faire votre travail. Si votre travail nécessite un accès root, vous l'obtenez - avec le discours de pouvoir / responsabilité associé. Mon travail est de protéger tout le monde contre vous.

Si vous voulez vraiment root sur votre poste de travail personnel, pensez au BYOD - mais si vous le cassez, vous le corrigez.

L'entreprise doit protéger les choses. Ils doivent protéger leur secret commercial, mais ils doivent également protéger des éléments tels que les données des utilisateurs. Si chaque employé a une autre configuration potentiellement non sécurisée sur son bureau, l'entreprise n'a aucune chance de s'assurer qu'il n'y a pas de vol de données ni de perte de données. Une gestion centralisée par des professionnels permet de sécuriser les ordinateurs et d'éviter la perte accidentelle de données.

Dans le cas d'une boîte unix connectée à tout type de serveurs de fichiers NFS old school (v2 ou v3), l'accès root local permet effectivement à un utilisateur d'interférer avec les fichiers d'autres utilisateurs, puisque l'autorisation est partiellement implémentée côté client avec ces protocoles, tandis que l'authentification est sous le contrôle de l'utilisateur local de cette façon. Cela signifie que quelqu'un peut simplement poursuivre un compte utilisateur existant ou créé avec le même uid et avoir accès aux fichiers appartenant à cet uid sur NFS.

De plus, est "utilisé uniquement par un seul employé" le définitive ou la manière habituelle d'y travailler? Si les machines font partie d'un domaine d'authentification commun, parfois échangées entre les utilisateurs selon les besoins, ou si l'accès aux machines d'un collègue (mais pas à leurs données!) Est parfois autorisé, cela ressemble à un scénario purement mono-utilisateur, mais il utilise en fait des fonctionnalités multi-utilisateurs pour la gestion de l'équipement fins.

À partir d'un PDV de licence logicielle, je ne veux pas que les utilisateurs puissent installer des logiciels bon gré mal gré. Par exemple, un utilisateur souhaite installer Sublime Text, un éditeur de texte qui permet de l'utiliser gratuitement pendant une durée limitée. Il le supprime et le réinstalle après le temps imparti. Cela enfreindrait le CLUF.