pam_umask: make "usergroups" check more secure against false privilege escalation

Bug #908115 reported by ceg on 2011-12-23
This bug affects 1 person
Affects Status Importance Assigned to Milestone
pam (Ubuntu)

Bug Description

Secure UPG detection checks 2) and 3) where summarized here:
and the discussion followed:

> When /etc/passwd specifies my UPG as my primary group, why does it matter if my own user is added to my group in [/etc/group]?

That is convention 2) for UPGs.

For the system itself there should be no direct effect, as it should work just as well without separate groups file. However, with the convention that a UPG will be set as primary group but not added to the user in the group file (while all other groups are added), you make the group identifiable as an UPG group even
if additional users are added to the group.

That allows to detect that:

 A) Only additional users were added (intentionally) to the UPG, and the umask
    should still be relaxed to xxy. (In general, you'd create separate groups
    to enable user collaboration on UPG systems, so tools may
    very well give a warning/hint about it if you try to add a
    user to a UPG. However, this if very helpful, for example, if one user uses sub-users for different tasks.)

 B) The group can be deleted if the user is deleted.

Specificly, debian's adduser command uses this convention to detect if it can delete the UPG together with the user, if the user is deleted.
Unfortunately, debian's adduser command has a bug that keeps it from ensuring the convention 3).
With regular groups added to the system, it just takes the next free UID, which is not equal to the next free GID anymore. Instead it should seek for the next free pair of GUI==UID, possibly even based on a hash to increase the chance of of a unique username to have the same numerical IDs accross different systems.

3) UID==GID was questioned to be a requrement, probably because it was
   seen that it isn't be enforced, but it can be of great help if you
   are looking at a filesystem (removable drive) without knowing the
   corresponding passwd/groups file.

   So maybe it is sane that UID==GID is a requirement, and its only an
   adduser bug when it does not skip IDs that have been taken by non
   UPG groups when creating users, and thus does not deliver that

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers