pam_umask: make "usergroups" check more secure against false privilege escalation
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
pam (Ubuntu) |
New
|
Undecided
|
Unassigned |
Bug Description
Secure UPG detection checks 2) and 3) where summarized here:
http://
and the discussion followed:
http://
> 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.