Typical use case for a group password

Question

I checked more than half a century worth Unix experience and neither my colleagues, nor myself has ever set a password on a group (sg and gpasswd). What would be a typical use case for a group password or is it pretty much only there because of historic reasons?

Answer 1

I too have never ever seen this feature used, not even one time. Most SA's aren't even aware that this facility exists. In looking at the man page for gpasswd there was this note:

Notes about group passwords

  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.

Why they exist

I think they were a natural idea in mimicking the model of user's having passwords, that it made sense to duplicate that use case model to groups as well. But in practice they're really not all that useful for anything.

The idea with a group password is that if you needed to gain access to a particular group (one that you weren't listed as being a member of), you could do so using the newgrp command, and be challenged with a password to gain access to these alternative groups.

The big problem with them is that there is only a single password for each group, thus forcing people to share this single password, when multiple people required access to this one particular group.

Groups

Most environments I've come across have typically put people in secondary groups, and then given these groups access to files on the filesystem, and this has satisfied pretty much all the usage that needs to occur.

sudo

With the advent of sudo additional permissions could be handed out on an as needed basis to groups, further undermining any use cases that group passwords may have provided. If you needed to allow users more permissions, it was much easier to create roles in sudo and then just allow there username or group that they were in, permissions to elevate there permissions so that they could perform a particular task.

ACLs

Finally the ability to create Access Control Lists (ACLs) really gave the last bit of flexibility that the User/Group/Other permissions model couldn't provide alone, relegating any possible need for group passwords to obscurity.

Answer 2

Here's a practical use for group passwords, that I implemented for myself on our work server, since the logs indicated my account was being brute-forced (or could have been a dictionary attack).
I used ssh-keygen and puttygen respectfully to generate key pairs for use from my workstation and home computer. The key I use from home requires a password. I added both of the public keys to the .ssh/authorized_keys, created a group marionette with a password and no members. As root I used visudo to add the following lines.

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

I have disabled my account's password, you no one can log into it that way. I now login only with my keys and entering the password-protected group with newgrp marionette allows me to become root using sudo -i.
Without the NOPASSWD: option it will require your user account password. If it is disabled and this group does not have NOPASSWD, you will not be able to sudo -i. It will also require your user account password if your command list does not have /bin/bash or whatever shell your root is using by default.

While this does make the path to sudoing a few steps longer, it adds a good layer of security. If you choose to make all your accounts like this, create one local account with a password and sudo privileges, but deny it ssh entry from /etc/ssh/sshd_config by adding something like:

DenyUsers root caan
DenyGroups root daleks

This is necessary for local access in case you reinstall and forgot to backup your access keys.

Answer 3

I added a password to my docker group.

As you may know, access to the Docker daemon (which is typically implied by the membership in the docker group) effectively gives you full root rights on the machine, as you can run any code with docker run -v /:/root ... with full write access to the filesystem. It's roughly equivalent to passwordless sudo.

If you configure a password on the docker group, you can enable access to the Docker daemon for that terminal session only by running newgrp docker and entering your password. This is roughly equivalent to su or sudo's cookie feature. Unlike su, you remain logged in as yourself and not root - only your primary group changes to docker.

Answer 4

I have never seen a use-case for that password, too. And that is about 20 years of *nix experience.

The only use-case that comes to my mind is to set it to "!" - locked, so no one, not being a member of that group can change to it with the newgrp command.

If I look into /etc/group on SLES or /etc/gshadow on RedHat-based systems this seems to be the "typical" use-case. SLES did not even bother to create a shadow-mechanism for that password.

Answer 5

Let me suggest a use case.

First let me say that we are so used to the term "user" that we even don't think about it. But "user" is not really a user. For example, at home we have three computers - the laptop of my wife, my laptop and common desktop computer. When I use the laptop of my wife I login with her user account. When She use my laptop she logs in with my user account. If somebody needs the desktop he or she uses the one common account. We see here that the thing the computer system calls "user" is not really a user but a workflow - a set of activities.

Here is the question: Why can't I have more than one activity - one for every different job that I have? I can. At my work computer I've created (experimentally) many different users so I can focus on the current task. I put all these users in the same group so I can access my files no mater which user I am currently using.

So where does the gpasswd fits in this?

The default behavior of Ubuntu is to create a special group for every user.

What if we decide to think about these primary groups as users and to think about the system users as workflows?

Than these new users would need a password to login, right? Here is the place of gpasswd. I still need to figure out how to login with the group (up to this point what I know is that you can switch groups with gpasswd if you are already logged in).