Pourquoi ne pas utiliser chmod -R 777 sur le serveur interne pour le code source du projet?
Depuis mes jours de développement web amateur le principe du moindre privilège m'a frappé de ne pas utiliser chmod -R 777 dir. Personnellement, je n'en ai jamais eu besoin, donc je ne l'ai jamais utilisé.
Je travaille maintenant sur une équipe de développement professionnellement, et nous avons récemment déplacé le code exécutable vers un serveur interne partagé. Seules les personnes de l'entreprise peuvent accéder au serveur et nous faisons confiance à tout le monde dans notre entreprise. De toute façon, le code n'est pas particulièrement sensible.
Essayer d'exécuter un script† qu'un autre membre de l'équipe a écrit dans le dossier partagé a causé une erreur d'autorisations, donc "juste pour vérifier si cela fonctionnerait autrement" un collègue a exécuté chmod -R 777 /opt/path/to/shared/folder sur le projet. Une fois que cela a fonctionné, le collègue a dit qu'il était bien de le laisser tel quel au lieu de passer à une solution groups plus contrôlée pour nous.
Parce que je suis n chimpanzé je veux parler et dire que c'est une mauvaise pratique et nous devrions le changer en une solution groups. Cependant, après y avoir réfléchi, je ne peux pas trouver une raison pour laquelle le code exécutable partagé sur un serveur interne ne devrait pas avoir 777 autorisations.
Du point de vue de la sécurité, existe-t-il une raison de modifier les autorisations de notre dossier de projet de 777 à quelque chose d'un peu plus serré avec groups?
† Nous ne pouvons pas modifier les exigences d'autorisation de ces scripts.
Cependant, après y avoir réfléchi, je ne peux pas trouver une raison pour laquelle 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 fonctionnant en tant que "personne" et "nogroupe". Toutes sortes de processus pouvant être exploités par un attaquant pour gagner ou étendre son 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 sera ravi de trouver ce petit système qui n'est qu'interne et qui n'est pas important ou protégé, voyez les faiblesses comme les fichiers d'application Web inscriptibles, utilisez-les pour accéder au système et commencez à les exploiter pour arriver 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 seconder @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 avons constaté 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é bâclée dans prod met leurs données en danger. Voir: violation Equifax de 2017 .
- La sécurité bâclée dans le développement conduit les développeurs à écrire des produits bâclés. Vraiment cependant, l'attitude selon laquelle la sécurité est importante doit émaner de la direction pour donner aux développeurs une formation sur la sécurité, du temps pour effectuer des révisions de code appropriées et la volonté de prioriser la correction des failles de sécurité par rapport aux fonctionnalités client. Autoriser des pratiques bâclées comme la preuve que la culture d'entreprise ne favorise pas la sécurité.
- Des pratiques de sécurité bâclées en informatique conduisent à des virus dans le réseau qui peuvent conduire à des virus dans le code. Voir la fameuse tentative de porte dérobée Linux de 20 où quelqu'un s'est introduit électroniquement dans le référentiel de code de sauvegarde et a inséré un changement de code malveillant, espérant qu'il finirait par être fusionné dans le référentiel principal.
Est-ce donc 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 "Quelqu'un peut-il 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 il devient le moindre privilège, et il pourrait y avoir une discussion de sécurité légitime à avoir ici, mais il semble qu'il n'y en ait pas; c'est juste de la paresse. Cela ne me donne pas confiance que le principe du moindre privilège est appliqué dans le produit lui-même, par exemple comment les données sont stockées, combien de données supplémentaires sont renvoyées des appels API, quelles informations sont enregistrées, ou partout où le principe du moindre privilège est pertinentes 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 Alors que chmod -R 775 /opt/path/to/shared/folder Autorisait toujours les autorisations de lecture et d'exécution et obtenait l'accès souhaité.
Étant donné que les membres de votre équipe sont les seuls à avoir accès au serveur et que vous leur faites confiance. Avoir un accès en écriture global 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. Ransomware pourrait être un exemple, qui est exécuté par Alice, avec des autorisations utilisateur.
- / home/alice/--- (drwxrwxrwx alice alice)
- / home/bob/--- (drwxrwx --- bob bob)
Pour le scénario ci-dessus, le ransomware exécuté par Alice crypterait et écraserait tous les fichiers auxquels elle doit accéder en écriture. Étant donné qu'Alice n'appartient pas au groupe bob et /home/bob/ N'a pas global rwx Alice a zéro accès. Cependant, si Bob devait exécuter le ransomware avec des autorisations utilisateur, Bob dispose des autorisations rwx car /home/alice/ Utilise les autorisations globales rwx. Ainsi, les répertoires personnels d'Alice et de Bob seront désormais cryptés par le ransomware.
Ajouter des utilisateurs à un groupe est assez simple, Linux: Ajouter un utilisateur au groupe (primaire/secondaire/nouveau/existant) . Cela ajoutera le nom d'utilisateur: alice, au groupe bob. Chown -R bob:bob Où user:group Possède le répertoire, récursivement. chmod -R 750 Fournira récursivement les autorisations rwxr-x---, Afin qu'Alice puisse lire et exécuter dans le répertoire /home/bob/, 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 consiste principalement à protéger contre les utilisateurs malveillants. Cependant, les programmes malveillants sont également très préoccupants. C'est pourquoi global lire, écrire et exécuter, ensemble ------rwx Est un très mauvais principe de sécurité. Cette idée se fait en ajoutant alice au groupe bob. Désormais, l'utilisateur alice dispose des autorisations r-x Pour /home/bob/, Contrairement aux autres utilisateurs hors du groupe bob, à l'exception de root. De même, si Bob voulait partager des fichiers avec Alice, mais ne veut pas qu'Alice ait accès au 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---) pouvait être créé, et les commandes ci-dessus appliquées. Seuls ceux du groupe AB y auraient accès.