The default subordinate ID assignment creates risk for collision with existing user ID's, creating potential for arbitrarily changing UID/GID and gain

Search code, repositories, users, issues, pull requests...

submited by

Style Pass

2025-01-13 11:30:02

The default subordinate ID assignment creates risk for collision with existing user ID's, creating potential for arbitrarily changing UID/GID and gaining unauthorized access to data and network resources.

Confirmed on: Debian 12, Red Hat Enterprise Linux 9, Red Hat Enterprise Linux 10. All recent versions of distributions that are using shadow-utils 4.4 and greater.

When new local users are added to the system via any of the shadow-utils tools (adduser, useradd and during system install), each user is given a unique block of 65,536 UID's and GID's, starting at UID/GID 100000. For example, the following system has two local users added on it:

Subordinate ID configuration delegates the right of usage of the specified range(s) to the user in a user namespace and is most often used for rootless containerization. However, containerization utilities are not required to enter a namespace and can be done via multiple means, including using the default shadow-utils tooling 'newuidmap' and 'newgidmap.' This allows for the user to arbitrarily change to the POSIX user ID of any ID within the range delegated to them.

In the following example, the user ID Jon - UID/GID 1000 - has been delegated a UID/GID range of 65,536 ID's starting at 100000. The network has other ID's configured via LDAP for centralized user management and login, with network users home directories on NFS.