グループパスワードの一般的な使用例

私は半世紀以上Unixでの経験に値するものをチェックしました。同僚も私もグループ（sgとgpasswd）にパスワードを設定したことはありません。グループパスワードの典型的なユースケースは何でしょうか、それとも歴史的な理由からそこにしかありませんか？

私もこの機能を使用したことは一度もありません。ほとんどのSAは、この機能が存在することさえ認識していません。マニュアルページを見ると、gpasswd次の注意事項がありました。

グループパスワードに関する注意

  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.

なぜ存在するのか

ユーザーがパスワードを持っているというモデルを模倣するのは自然な考えだと思います。そのユースケースモデルをグループにも複製することは理にかなっています。しかし、実際には、それらは何に対してもそれほど有用ではありません。

グループパスワードのアイデアは、特定のグループ（自分がメンバーとしてリストされていないグループ）にアクセスする必要がある場合、newgrpコマンドを使用してアクセスでき、パスワードを取得してアクセスできるようにするというものです。これらの代替グループに。

それらの大きな問題は、グループごとにパスワードが1つしかないため、複数の人がこの特定のグループへのアクセスを要求したときに、人々がこの1つのパスワードを共有することを強制することです。

グループ

私が出くわしたほとんどの環境は、通常、人々を二次グループに入れてから、これらのグループにファイルシステム上のファイルへのアクセス権を与えました。

須藤

sudo追加のアクセス許可の出現により、必要に応じてグループに配布され、グループパスワードが提供する可能性のあるユースケースがさらに損なわれます。ユーザーにさらに多くのアクセス許可を許可する必要がある場合、ロールを作成してsudoから、ユーザーがいたユーザー名またはグループを許可し、特定のタスクを実行できるようにアクセス許可を上げる許可を与える方がはるかに簡単でした。

ACL

最後に、アクセス制御リスト（ACL）を作成する機能により、ユーザー/グループ/その他のアクセス許可モデルだけでは提供できなかった柔軟性が最後に得られ、グループパスワードの必要性が不明瞭になりました。

これは、ログが私のアカウントがブルートフォースされている（または辞書攻撃である可能性がある）ことを示しているためです。
私が使用ssh-keygenしてputtygen丁重に私のワークステーションや自宅のコンピュータから使用する鍵ペアを生成します。自宅から使用するキーにはパスワードが必要です。両方の公開鍵をに追加し、パスワードを使用し.ssh/authorized_keysてグループmarionetteを作成しましたが、メンバーはありません。ルートとしてvisudo、次の行を追加しました。

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

アカウントのパスワードを無効にしたため、その方法でログインすることはできません。キーでのみログインし、パスワードで保護されたグループに入ると、をnewgrp marionette使用してrootになることができますsudo -i。オプション
なしではNOPASSWD:、ユーザーアカウントのパスワードが必要になります。無効になっていてNOPASSWD、このグループにない場合は、できませんsudo -i。また、コマンドリストにルートがないか、ルートがデフォルトで使用しているシェルがない場合は、ユーザーアカウントのパスワードが必要/bin/bashです。

これにより、sudoingへのパスが数ステップ長くなりますが、セキュリティの優れたレイヤーが追加されます。このようにすべてのアカウントを作成する場合は、パスワードとsudo特権を持つ1つのローカルアカウントを作成しますが、/etc/ssh/sshd_config次のようなものを追加して、sshエントリを拒否します。

DenyUsers root caan
DenyGroups root daleks

これは、アクセスキーを再インストールしてバックアップを忘れた場合のローカルアクセスに必要です。

そのパスワードのユースケースも見たことがありません。そして、それは約20年間の* nix経験です。

私の頭に浮かぶ唯一のユースケースは、「！」に設定することです。-ロックされているため、そのグループのメンバーではないユーザーはnewgrpコマンドで変更できません。

SLESの/ etc / groupまたはRedHatベースのシステムの/ etc / gshadowを調べると、これは「典型的な」ユースケースのようです。SLESは、そのパスワードのシャドウメカニズムを作成することすらしませんでした。

ユースケースを提案させてください。

まず、「ユーザー」という言葉に慣れているので、それについては考えていません。しかし、「ユーザー」は実際にはユーザーではありません。たとえば、自宅には3つのコンピューターがあります。妻のラップトップ、私のラップトップ、および一般的なデスクトップコンピューターです。妻のラップトップを使用するときは、彼女のユーザーアカウントでログインします。彼女は私のラップトップを使用するとき、私のユーザーアカウントでログインします。誰かがデスクトップを必要とする場合、彼または彼女は1つの共通アカウントを使用します。ここで、コンピュータシステムが「ユーザー」と呼ぶものは、実際にはユーザーではなく、ワークフロー一連のアクティビティ。

ここに質問があります：なぜ私は複数の活動をすることができません-私が持っているさまざまな仕事ごとに一つですか？できます。職場のコンピューターでは、（実験的に）さまざまなユーザーを作成しているため、現在のタスクに集中できます。これらすべてのユーザーを同じグループに入れて、現在使用しているユーザーに関係なくファイルにアクセスできるようにします。

では、gpasswdはどこに収まるのでしょうか？

Ubuntuのデフォルトの動作では、すべてのユーザーに対して特別なグループが作成されます。

これらのプライマリグループをユーザーと見なし、システムユーザーをワークフローと見なすことにした場合はどうなりますか？

これらの新しいユーザーは、ログインするためにパスワードが必要ですよね？ここにgpasswdの場所があります。グループでログインする方法を理解する必要があります（この時点まで、すでにログインしている場合はgpasswdでグループを切り替えることができます）。