Typischer Anwendungsfall für ein Gruppenpasswort

Typischer Anwendungsfall für ein Gruppenpasswort

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

Antwort1

Auch ich habe diese Funktion noch nie im Einsatz gesehen, nicht ein einziges Mal. Die meisten SAs sind sich nicht einmal bewusst, dass diese Funktion existiert. Beim Durchsehen der Manpage gpasswdfand ich diesen Hinweis:

Hinweise zu Gruppenpasswö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 es sie gibt

Ich denke, sie waren eine natürliche Idee, da sie das Modell der Benutzerkennwörter nachahmten, sodass es Sinn machte, dieses Anwendungsfallmodell auch auf Gruppen zu übertragen. Aber in der Praxis sind sie für nichts wirklich nützlich.

Die Idee hinter einem Gruppenkennwort besteht darin, dass Sie, wenn Sie Zugriff auf eine bestimmte Gruppe benötigen (eine Gruppe, als deren Mitglied Sie nicht aufgeführt sind), dies mit dem newgrpBefehl tun können und dann zur Eingabe eines Kennworts aufgefordert werden, um Zugriff auf diese alternativen Gruppen zu erhalten.

Das große Problem dabei ist, dass es für jede Gruppe nur ein einziges Passwort gibt. Dadurch sind die Benutzer gezwungen, dieses Passwort gemeinsam zu nutzen, wenn mehrere Personen Zugriff auf diese eine bestimmte Gruppe benötigen.

Gruppen

In den meisten Umgebungen, die ich gesehen habe, wurden die Benutzer normalerweise in sekundäre Gruppen eingeteilt und diesen Gruppen dann Zugriff auf die Dateien im Dateisystem gewährt. Damit wurden praktisch alle erforderlichen Verwendungszwecke abgedeckt.

sudo

Mit der Einführung sudozusätzlicher Berechtigungen konnten Gruppen nach Bedarf zugewiesen werden, was alle Anwendungsfälle, die Gruppenkennwörter möglicherweise ermöglichten, weiter untergrub. Wenn Sie Benutzern mehr Berechtigungen erteilen mussten, war es viel einfacher, Rollen zu erstellen sudound dann einfach ihrem Benutzernamen oder ihrer Gruppe, in der sie sich befanden, Berechtigungen zu erteilen, um ihre Berechtigungen zu erhöhen, damit sie eine bestimmte Aufgabe ausführen konnten.

Zugriffssteuerungslisten

Und schließlich bot die Möglichkeit, Zugriffskontrolllisten (Access Control Lists, ACLs) zu erstellen, das letzte bisschen Flexibilität, das das Berechtigungsmodell „Benutzer/Gruppe/Andere“ allein nicht bieten konnte, wodurch die mögliche Notwendigkeit von Gruppenkennwörtern in Vergessenheit geriet.

Antwort2

Hier ist eine praktische Anwendung für Gruppenkennwörter, die ich für mich selbst auf unserem Arbeitsserver implementiert habe, da die Protokolle anzeigten, dass mein Konto mit Brute-Force-Angriffen geknackt wurde (oder es könnte sich um einen Wörterbuchangriff gehandelt haben).
Ich habe ssh-keygenund verwendet puttygen, um Schlüsselpaare für die Verwendung von meiner Arbeitsstation und meinem Heimcomputer aus zu generieren. Der Schlüssel, den ich von zu Hause aus verwende, erfordert ein Kennwort. Ich habe beide öffentlichen Schlüssel zu hinzugefügt .ssh/authorized_keys, 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, so kann sich niemand mehr anmelden. Ich melde mich jetzt nur noch mit meinen Schlüsseln an und wenn ich die passwortgeschützte Gruppe mit betrete, newgrp marionettekann ich mich mit root anmelden sudo -i.
Ohne diese NOPASSWD:Option wird IhrBenutzerkontoPasswort. Wenn es deaktiviert ist und diese Gruppe nicht hat NOPASSWD, können Sie nicht sudo -i. Außerdem wird IhrBenutzerkontoKennwort, wenn Ihre Befehlsliste keins enthält, /bin/bashoder welche Shell auch immer Ihr Root standardmäßig verwendet.

Dies verlängert zwar den Weg zum Sudo-Befehl um einige Schritte, fügt aber eine gute Sicherheitsebene hinzu. Wenn Sie alle Ihre Konten auf diese Weise einrichten möchten, erstellen Sie ein lokales Konto mit einem Passwort und Sudo-Berechtigungen, verweigern Sie ihm jedoch den SSH-Zugriff, /etc/ssh/sshd_configindem Sie etwas wie 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.

Antwort3

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 einfällt, besteht darin, es auf „!“ – gesperrt – zu setzen, sodass niemand, der kein Mitglied dieser Gruppe ist, es mit dem newgrpBefehl ändern kann.

Wenn ich mir /etc/group auf SLES oder /etc/gshadow auf RedHat-basierten Systemen anschaue, scheint dies der „typische“ Anwendungsfall zu sein. SLES hat sich nicht einmal die Mühe gemacht, einen Shadow-Mechanismus für dieses Passwort zu erstellen.

Antwort4

Lassen Sie mich einen Anwendungsfall vorschlagen.

Lassen Sie mich zunächst sagen, dass wir so an den Begriff „Benutzer“ gewöhnt sind, dass wir nicht einmal darüber nachdenken. Aber „Benutzer“ ist nicht wirklich einBenutzer. Zu Hause haben wir beispielsweise drei Computer - den Laptop meiner Frau, meinen Laptop und einen gemeinsamen Desktop-Computer. Wenn ich den Laptop meiner Frau benutze, melde ich mich mit ihrem Benutzerkonto an. Wenn sie meinen Laptop benutzt, meldet sie sich mit meinem Benutzerkonto an. Wenn jemand den Desktop benötigt, verwendet er oder sie das eine gemeinsame Konto. Wir sehen hier, dass das, was das Computersystem "Benutzer" nennt, nicht wirklich einBenutzeraber einArbeitsablauf- eine Reihe von Aktivitäten.

Hier ist die Frage: Warum kann ich nicht mehr als eine Aktivität haben – eine für jeden meiner Jobs? Das kann ich. An meinem Arbeitscomputer habe ich (experimentell) viele verschiedene Benutzer erstellt, damit ich mich auf die aktuelle Aufgabe konzentrieren kann. Ich habe alle diese Benutzer in dieselbe Gruppe eingefügt, damit ich auf meine Dateien zugreifen kann, egal welchen Benutzer ich gerade verwende.

Wo passt also GPassWD hier hinein?

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

Was wäre, wenn wir uns entscheiden würden, diese primären Gruppen alsBenutzerund an die Systembenutzer zu denken alsWorkflows?

Dann bräuchten diese neuen Benutzer ein Passwort, um sich anzumelden, richtig? Hier ist der Platz für gpasswd. Ich muss noch herausfinden, wie ich mich mit der Gruppe anmelde (bis jetzt weiß ich nur, dass man mit gpasswd die Gruppe wechseln kann, wenn man bereits angemeldet ist).

verwandte Informationen