Typischer Anwendungsfall für ein Gruppenpasswort

Ich habe mehr als ein halbes Jahrhundert Unix-Erfahrung überprüft und weder meine Kollegen noch ich haben jemals ein Passwort für eine Gruppe ( sgund gpasswd) festgelegt. Was wäre ein typischer Anwendungsfall für ein Gruppenpasswort oder ist es so ziemlich nur aus historischen Gründen dort?

Auch ich habe dieses Feature noch nie gesehen, auch nicht ein einziges Mal. Den meisten SAs ist nicht einmal bewusst, dass diese Einrichtung vorhanden ist. Beim Durchsuchen der Manpage gpasswdgab es diesen Hinweis:

Hinweise zu Gruppenkennwörtern

  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.

Warum gibt es sie?

Ich denke, sie waren eine natürliche Idee, um das Modell des Benutzers nachzuahmen, der Passwörter hat, und es machte Sinn, dieses Anwendungsfallmodell auch für Gruppen zu duplizieren. Aber in der Praxis sind sie für nichts wirklich nützlich.

Die Idee mit einem Gruppenkennwort ist, dass Sie, wenn Sie Zugriff auf eine bestimmte Gruppe benötigen (einer, der Sie nicht angehören), dies mit dem newgrpBefehl tun und mit einem Kennwort aufgefordert werden können, um Zugriff zu erhalten zu diesen alternativen Gruppen.

Das große Problem bei ihnen ist, dass es für jede Gruppe nur ein einziges Kennwort gibt, sodass die Benutzer gezwungen sind, dieses Kennwort gemeinsam zu verwenden, wenn mehrere Benutzer Zugriff auf diese eine bestimmte Gruppe benötigen.

Gruppen

Die meisten Umgebungen, denen ich begegnet bin, haben normalerweise Personen in sekundäre Gruppen eingeteilt und diesen Gruppen dann Zugriff auf Dateien im Dateisystem gewährt, und dies hat so ziemlich die gesamte Nutzung gedeckt, die auftreten muss.

sudo

Mit dem Aufkommen sudozusätzlicher Berechtigungen könnten diese nach Bedarf an Gruppen weitergegeben werden, was möglicherweise von Gruppenkennwörtern bereitgestellte Anwendungsfälle weiter untergräbt. Wenn Sie Benutzern mehr Berechtigungen gewähren mussten, war es viel einfacher, Rollen zu erstellen sudound dann nur dem Benutzernamen oder der Gruppe, in der sie sich befanden, Berechtigungen zu erteilen, um die Berechtigungen zu erhöhen, damit sie eine bestimmte Aufgabe ausführen können.

ACLs

Schließlich hat die Möglichkeit, Zugriffssteuerungslisten (Access Control Lists, ACLs) zu erstellen, wirklich die letzte Flexibilität gebracht, die das Berechtigungsmodell Benutzer / Gruppe / Andere allein nicht bieten konnte, und die mögliche Notwendigkeit, Gruppenkennwörter zu verbergen, in den Hintergrund gedrängt.

Hier ist eine praktische Anwendung für Gruppenkennwörter, die ich für mich auf unserem Arbeitsserver implementiert habe, da die Protokolle darauf hinweisen, dass mein Konto brutal erzwungen wurde (oder ein Wörterbuchangriff hätte sein können).
Ich habe ssh-keygenmit puttygenRespekt Schlüsselpaare für die Verwendung auf meiner Workstation und meinem Heimcomputer generiert. Für den Schlüssel, den ich von zu Hause aus verwende, ist ein Passwort erforderlich. Ich habe beide öffentlichen Schlüssel zur .ssh/authorized_keysGruppe hinzugefügt , eine Gruppe marionettemit einem Kennwort und ohne Mitglieder erstellt. Als root habe ich visudodie folgenden Zeilen hinzugefügt.

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

Ich habe das Passwort meines Kontos deaktiviert. Auf diese Weise kann sich niemand anmelden. Ich melde mich jetzt nur noch mit meinen Schlüsseln an und gebe die passwortgeschützte Gruppe mit ein, um newgrp marionettemich als Root zu registrieren sudo -i.
Ohne diese NOPASSWD:Option ist ein Passwort für Ihr Benutzerkonto erforderlich . Wenn es deaktiviert ist und diese Gruppe nicht hat NOPASSWD, können Sie dies nicht tun sudo -i. Es wird auch Ihr Benutzerkontokennwort erfordern, wenn Ihre Befehlsliste keine /bin/bashoder eine von Ihrem Root standardmäßig verwendete Shell hat.

Dies verlängert zwar den Sudo-Pfad um einige Schritte, erhöht jedoch die Sicherheit. Wenn Sie alle Ihre Konten so einrichten möchten, erstellen Sie ein lokales Konto mit einem Kennwort und Sudo-Berechtigungen. Verweigern Sie jedoch die Eingabe von ssh, /etc/ssh/sshd_configindem Sie Folgendes hinzufügen:

DenyUsers root caan
DenyGroups root daleks

Dies ist für den lokalen Zugriff erforderlich, falls Sie eine Neuinstallation durchführen und vergessen haben, Ihre Zugriffsschlüssel zu sichern.

Ich habe auch noch nie einen Anwendungsfall für dieses Passwort gesehen. Und das sind ungefähr 20 Jahre * nix Erfahrung.

Der einzige Anwendungsfall, der mir in den Sinn kommt, ist, ihn auf "!" - locked, damit niemand, der nicht Mitglied dieser Gruppe ist, mit dem newgrpBefehl zu ihr wechseln kann .

Wenn ich in / etc / group auf SLES oder / etc / gshadow auf RedHat-basierten Systemen nachschaue, scheint dies der "typische" Anwendungsfall zu sein. SLES hat sich nicht einmal die Mühe gemacht, einen Schattenmechanismus für dieses Passwort zu erstellen.

Lassen Sie mich einen Anwendungsfall vorschlagen.

Lassen Sie mich zunächst sagen, dass wir an den Begriff "Benutzer" so gewöhnt sind, dass wir gar nicht daran denken. Aber "Benutzer" ist nicht wirklich ein Benutzer . Zum Beispiel haben wir zu Hause drei Computer - den Laptop meiner Frau, meinen Laptop und einen normalen Desktop-Computer. Wenn ich den Laptop meiner Frau benutze, logge ich mich mit ihrem Benutzerkonto ein. Wenn sie meinen Laptop benutzt, loggt sie sich mit meinem Benutzerkonto ein. Wenn jemand den Desktop benötigt, verwendet er den einen gemeinsamen Account. Wir sehen hier, dass das, was das Computersystem "Benutzer" nennt, nicht wirklich ein Benutzer ist, sondern ein Workflow - eine Reihe von Aktivitäten.

Hier ist die Frage: Warum kann ich nicht mehr als eine Aktivität haben - eine für jeden Job, den ich habe? Ich kann. An meinem Arbeitscomputer habe ich (experimentell) viele verschiedene Benutzer angelegt, damit ich mich auf die aktuelle Aufgabe konzentrieren kann. Ich stelle alle diese Benutzer in dieselbe Gruppe, damit ich auf meine Dateien zugreifen kann, egal welchen Benutzer ich gerade benutze.

Also, wo passt das gpasswd dazu?

Das Standardverhalten von Ubuntu besteht darin, für jeden Benutzer eine spezielle Gruppe zu erstellen.

Was ist, wenn wir uns entscheiden, diese primären Gruppen als Benutzer und die Systembenutzer als Workflows zu betrachten ?

Dann benötigen diese neuen Benutzer ein Passwort, um sich anzumelden, oder? Hier ist der Ort von gpasswd. Ich muss noch herausfinden, wie ich mich mit der Gruppe anmelde (bis zu diesem Punkt weiß ich, dass Sie mit gpasswd die Gruppe wechseln können, wenn Sie bereits angemeldet sind).