Cependant, après y avoir réfléchi, je n'arrive pas à comprendre pourquoi le code exécutable partagé sur un serveur interne ne devrait pas avoir 777 autorisations.
Parce que vous ne faites pas seulement confiance à chaque utilisateur - ce qui peut être raisonnable sur un serveur interne où "tout le monde" qui a accès devrait avoir ce contrôle - vous faites également confiance à chaque processus sur ce serveur. Le serveur Web. Le serveur SSH. Le client DHCP. Chaque tâche planifiée et chaque service. Même les processus exécutés en tant que "nobody" et "nogroup". Toutes sortes de processus qui pourraient être exploités par un attaquant pour obtenir ou étendre leur accès.
Parce que si vous allez être aussi bâclé dans le développement interne, quelqu'un va être aussi bâclé sur un système de production ou client, parce que "c'est comme ça que nous l'avons corrigé en interne".
Parce qu'un attaquant prendra plaisir à trouver ce petit système qui n'est qu'interne et qui n'est ni important ni protégé, voyez les faiblesses comme les fichiers d'application Web inscriptibles, utilisez-les pour accéder au système et commencez à en tirer parti pour aller quelque part. Je parie que les mots de passe que les gens utilisent sur ce système fonctionnent également sur d'autres systèmes internes plus précieux. Peut-être que vous utilisez également le même mot de passe root sur tous les serveurs ? C'est toujours amusant à trouver.
Je vais appuyer @gowenfawr et dire que élever de meilleurs chimpanzés est un objectif en soi ici. (maintenant je vais extrapoler sauvagement sur votre culture d'entreprise)
Dans ma société de développement de logiciels, nous constatons une tendance croissante des clients à demander des preuves de nos pratiques de sécurité, non seulement dans les environnements de production, mais également dans notre processus de développement et dans l'informatique d'entreprise en général. Il s'agit d'une demande parfaitement raisonnable car :
- Une sécurité négligée dans la production met leurs données en danger. Voir :Violation d'Equifax en 2017.
- Une sécurité bâclée dans le développement conduit les développeurs à écrire des produits bâclés. Cependant, l'attitude selon laquelle la sécurité est importante doit venir de la direction pour donner aux développeurs une formation à la sécurité, du temps pour effectuer des révisions de code appropriées et la volonté de donner la priorité à la correction des failles de sécurité par rapport aux fonctionnalités des clients. Autoriser des pratiques bâclées est la preuve que la culture d'entreprise ne favorise pas la sécurité.
- Des pratiques de sécurité informatiques négligentes entraînent des virus sur le réseau, qui peuvent entraîner des virus dans le code. Voir la célèbre tentative de porte dérobée Linux de 2003 où quelqu'un s'est introduit par voie électronique dans le référentiel de code de sauvegarde et a inséré un changement de code malveillant, en espérant qu'il finirait par être fusionné dans le référentiel principal.
Alors, est-ce une décision dont vous seriez fier de parler à un client ?
Conclusion : Le principe du moindre privilège est l'un des principes de codage sécurisé les plus fondamentaux. C'est un état d'esprit qui devrait faire partie de tout processus de développement logiciel. Il s'agit de poser la question "Est-il nécessaire d'affaiblir notre sécurité comme ça ?", plutôt que "Est-ce que quelqu'un peut prouver que c'est dangereux ?". Les pirates sont toujours plus intelligents que vous.
Bien sûr si chmod 777 est nécessaire pour une raison quelconque, alors cela devient le moindre privilège, et il pourrait y avoir une discussion légitime sur la sécurité à avoir ici, mais il semble qu'il n'y en ait pas; ce n'est que de la paresse. Cela ne me donne pas confiance que le principe du moindre privilège est suivi dans le produit lui-même, par exemple comment les données sont stockées, combien de données supplémentaires sont renvoyées à partir des appels d'API, quelles informations sont enregistrées ou partout où le principe du moindre privilège est pertinent pour votre produit.
À moins que le programme ne nécessite des autorisations d'écriture, je ne comprends pas pourquoi votre collègue a utilisé chmod -R 777 /opt/path/to/shared/folder quand chmod -R 775 /opt/path/to/shared/folder autoriserait toujours les autorisations de lecture et d'exécution, et obtiendrait l'accès souhaité.
Étant donné que les membres de votre équipe sont les seuls à avoir accès au serveur, vous leur faites confiance. Avoir un accès global en écriture n'est pas nécessairement une mauvaise chose. Mais le but est également d'empêcher les programmes malveillants ou malveillants de modifier ou de supprimer les fichiers. Un ransomware pourrait être un exemple, qui est exécuté par Alice, avec les autorisations de l'utilisateur.
- /home/alice/ --- (drwxrwxrwx alice alice)
- /home/bob/ --- (drwxrwx--- bob bob)
Pour le scénario ci-dessus, le rançongiciel exécuté par Alice chiffrerait et écraserait tous les fichiers auxquels elle a accès en écriture. Étant donné qu'Alice ne le fait pas appartiennent au groupe bob et /home/bob/ n'a pas de rwx global Alice n'a aucun accès. Cependant, si Bob devait exécuter le ransomware avec des autorisations d'utilisateur, Bob a rwx autorisations car /home/alice/ utilise le rwx global autorisations. Ainsi, les répertoires personnels d'Alice et de Bob seront désormais chiffrés par le ransomware.
L'ajout d'utilisateurs à un groupe est assez simple, Linux :Ajouter un utilisateur au groupe (Primaire/Secondaire/Nouveau/Existant). Cela ajoutera le nom d'utilisateur :alice , au bob groupe. Chown -R bob:bob où user:group possède le répertoire, récursivement. chmod -R 750 fournira récursivement rwxr-x--- autorisations, afin qu'Alice puisse lire et exécuter dans /home/bob/ répertoire, mais ne peut pas écrire.
sudo adduser alice bobsudo chown -R bob:bob /home/bob/sudo chmod -R 750 /home/bob/
Le principe du moindre accès est principalement de se protéger contre les utilisateurs malveillants. Cependant, les programmes malveillants sont également une préoccupation très sérieuse. C'est pourquoi la lecture, l'écriture et l'exécution globales, ensemble ------rwx est un très mauvais principe de sécurité. Cette idée est réalisée en ajoutant alice au bob groupe. Maintenant l'utilisateur alice a r-x autorisations à /home/bob/ tandis que d'autres utilisateurs en dehors de bob groupe ne peut pas, sauf root. De même, si Bob voulait partager des fichiers avec Alice, mais ne voulait pas qu'Alice ait un accès de groupe, un nouveau groupe, appelé AB où Alice et Bob sont dans le groupe pourrait être créé. Maintenant un répertoire /opt/AB_share/ (rwxrwx---) pourrait être créé, et les commandes ci-dessus appliquées. Uniquement ceux dans le AB groupe aurait accès.