[Bug 908115] [NEW] pam_umask: make "usergroups" check more secure against false privilege escalation

[ceg]

Public bug reported:

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

http://lists.debian.org/debian-devel/2010/05/msg00887.html
and the discussion followed:
http://lists.debian.org/debian-devel/2010/05/msg01069.html

> 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
   requirement.

** Affects: pam (Ubuntu)
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to pam in Ubuntu.
https://bugs.launchpad.net/bugs/908115

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

Status in “pam” package in Ubuntu:
  New

Bug description:
  Secure UPG detection checks 2) and 3)  where summarized here:

  http://lists.debian.org/debian-devel/2010/05/msg00887.html
  and the discussion followed:
  http://lists.debian.org/debian-devel/2010/05/msg01069.html

  > 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
     requirement.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pam/+bug/908115/+subscriptions