Cas d'utilisation typique d'un mot de passe de groupe

J'ai vérifié plus d'un demi-siècle d'expérience Unix et ni mes collègues, ni moi-même n'avons jamais défini de mot de passe pour un groupe ( sget gpasswd). Quel serait un cas d’utilisation typique pour un mot de passe de groupe ou est-ce quasiment uniquement là pour des raisons historiques?

Moi aussi, je n'ai jamais vu cette fonctionnalité utilisée, pas même une fois. La plupart des AS ne savent même pas que cette installation existe. En regardant la page de manuel, gpasswdil y avait cette note:

Notes sur les mots de passe de groupe

  Group passwords are an inherent security problem since more than one 
  person is permitted to know the password. However, groups are a useful 
  tool for permitting co-operation between different users.

Pourquoi ils existent

Je pense qu'ils étaient une idée naturelle en imitant le modèle de mots de passe d'utilisateur, qu'il était logique de dupliquer également ce modèle de cas d'utilisation pour des groupes. Mais en pratique, ils ne sont vraiment pas utiles à quoi que ce soit.

L’idée d’un mot de passe de groupe est que, si vous deviez accéder à un groupe particulier (un groupe dont vous n’apparteniez pas à la liste des membres), vous pouvez le faire en utilisant la newgrpcommande et obtenir un mot de passe pour y accéder. à ces groupes alternatifs.

Le gros problème avec eux est qu’il n’ya qu’un seul mot de passe pour chaque groupe, ce qui oblige les gens à partager ce mot de passe lorsque plusieurs personnes ont besoin d’accéder à ce groupe.

Groupes

La plupart des environnements que j'ai rencontrés ont généralement mis des personnes dans des groupes secondaires, puis ont donné à ces groupes l'accès aux fichiers du système de fichiers, ce qui a permis de satisfaire à peu près tout l'utilisation qui devait en être faite.

sudo

Avec l’avènement d’ sudoautorisations supplémentaires, des autorisations supplémentaires pourraient être accordées aux groupes, ce qui affaiblirait davantage les cas d’utilisation fournis par les mots de passe des groupes. Si vous aviez besoin d'autoriser plus d'autorisations aux utilisateurs, il était beaucoup plus facile de créer des rôles sudo, puis simplement d'autoriser le nom d'utilisateur ou le groupe dans lequel ils se trouvaient, ainsi que les autorisations pour élever leurs autorisations afin qu'ils puissent effectuer une tâche particulière.

ACL

Enfin, la possibilité de créer des listes de contrôle d'accès (ACL) a réellement apporté la dernière flexibilité que le modèle d'autorisations Utilisateur / Groupe / Autre ne pouvait pas fournir seul, reléguant à néant tout besoin éventuel de mots de passe de groupe.

Voici une utilisation pratique des mots de passe de groupe, que j'ai moi-même mis en œuvre sur notre serveur de travail, car les journaux indiquaient que mon compte était forcé (ou aurait pu être une attaque par dictionnaire).
Je ssh-keygenet puttygenrespectueusement à générer des paires de clés pour l' utilisation de mon poste de travail et ordinateur à la maison. La clé que j'utilise de chez moi nécessite un mot de passe. J'ai ajouté les deux clés publiques à la .ssh/authorized_keys, créé un groupe marionetteavec un mot de passe et aucun membre. En tant que root, j'avais l'habitude visudod'ajouter les lignes suivantes.

Cmnd_Alias      SUDOING = /bin/bash, /usr/bin/sudo -i
%marionette     ALL=NOPASSWD:SUDOING

J'ai désactivé le mot de passe de mon compte, personne ne peut s'y connecter de cette façon. Je ne me connecte maintenant qu'avec mes clés et entrer dans le groupe protégé par mot de passe newgrp marionetteme permet de devenir root en utilisant sudo -i.
Sans cette NOPASSWD:option, vous aurez besoin du mot de passe de votre compte utilisateur. S'il est désactivé et que ce groupe n'en possède pas NOPASSWD, vous ne pourrez pas le faire sudo -i. Le mot de passe de votre compte d’utilisateur sera également requis si votre liste de commandes n’a pas /bin/bashou quel que soit le shell que votre racine utilise par défaut.

Bien que cela allonge le chemin de la progression de quelques pas, cela ajoute une bonne couche de sécurité. Si vous choisissez de créer tous vos comptes comme ceci, créez un compte local avec un mot de passe et des privilèges sudo, mais refusez l'entrée ssh /etc/ssh/sshd_configen ajoutant quelque chose comme:

DenyUsers root caan
DenyGroups root daleks

Cela est nécessaire pour l'accès local au cas où vous réinstalleriez et oublieriez de sauvegarder vos clés d'accès.

Je n'ai jamais vu de cas d'utilisation pour ce mot de passe aussi. Et cela représente environ 20 ans d'expérience * nix.

Le seul cas d'utilisation qui me vienne à l'esprit est de le régler sur "!" - verrouillé, pour que personne ne faisant partie de ce groupe ne puisse y accéder avec la newgrpcommande.

Si je regarde dans / etc / group sous SLES ou dans / etc / gshadow sur des systèmes basés sur RedHat, cela semble être le cas d'utilisation "typique". SLES n'a même pas pris la peine de créer un mécanisme fantôme pour ce mot de passe.

Permettez-moi de suggérer un cas d'utilisation.

Tout d’abord, permettez-moi de dire que nous sommes tellement habitués au terme «utilisateur» que nous n'y pensons même pas. Mais "utilisateur" n'est pas vraiment un utilisateur . Par exemple, à la maison, nous avons trois ordinateurs: l'ordinateur portable de mon épouse, mon ordinateur portable et un ordinateur de bureau commun. Lorsque j'utilise l'ordinateur portable de ma femme, je me connecte avec son compte utilisateur. Quand elle utilise mon ordinateur portable, elle se connecte avec mon compte utilisateur. Si quelqu'un a besoin du poste de travail, il utilise le compte commun unique. Nous voyons ici que ce que le système informatique appelle "utilisateur" n’est pas vraiment un utilisateur mais un flux de travail - un ensemble d’activités.

Voici la question: Pourquoi ne puis-je pas avoir plus d'une activité - une pour chaque travail différent que j'ai? Je peux. Sur mon ordinateur de travail, j'ai créé (à titre expérimental) de nombreux utilisateurs différents afin que je puisse me concentrer sur la tâche en cours. Je mets tous ces utilisateurs dans le même groupe afin de pouvoir accéder à mes fichiers, quel que soit l'utilisateur que j'utilise actuellement.

Alors, où se situe gpasswd dans tout cela?

Le comportement par défaut d’Ubuntu consiste à créer un groupe spécial pour chaque utilisateur.

Et si nous décidions de considérer ces groupes primaires en tant qu'utilisateurs et de considérer les utilisateurs du système comme des workflows ?

Que ces nouveaux utilisateurs auraient besoin d'un mot de passe pour se connecter, non? Voici la place de gpasswd. Il me reste à comprendre comment se connecter au groupe (jusqu'à présent, je sais que vous pouvez changer de groupe avec gpasswd si vous êtes déjà connecté).