Comment 2 for bug 712710

Scenario:

Group "printers" is defined in LDAP with GID=4 because that's how it was always defined in some legacy corporate Unix environment. All users who are allowed to print are a member of this group. A local administrator notices this and configures his system to have the "adm" group - which Ubuntu wants to be GID=4 - to have a GID of 1004.

The nsswitch.conf file is configured to use files then LDAP for group lookups (which most any tool or how-to will do) , and the sudoers file which comes with Ubuntu grants unlimited access to people in the adm group, Time passes, and everything works. The admin decides that this Ubuntu thing is alright, that the Q/A system doesn't suck, and updates seem to work well. He decides to enable automatic instalation of updates.

Oh no! There's a security-related update to base-passwd! Well, rest easy admin - the automatic update setting will pull the update down and install it. The update-passwd tool, running in "assume yes" mode, helpfully notices that some foolish admin has changed the adm GID to something other than 4, so it changes it back. It sends an email, but the admins don't notice that email amid all the other notifications that they only spot-check.

Now, when users log in, they still get membership in the printers group from LDAP. The system still records this in the group vector as "4", because that's the number returned by a getgrnam("printers") call. So, file access and whatnot based on the printers group still works just like it always has. No one notices that running "id" or "groups" shows them as a member of adm - because no one runs those commands in normal day to-day usage. They don't do an "ls -l" on the print queues, either, and most programs don't do a double reverse-lookup from name to gid and back to name just to ensure that things are kosher. But eventually, a malicious user does notice that he's a member of the adm group - because this is what a getgrgid(4) returns. Maybe he ran "groups". Who knows. Oh, and he runs "sudo -l". Since sudo uses the name of the group, it doesn't notice that the GID has changed; it doesn't care that there's a conflict. "My, look at the sudo rule I've gained..."

Now everyone who used to only be able to print because they were in the printers group (or whatever the LDAP GID=4 groul granted, you get the point) has unlimited sudo access. One "sudo -i" later, and the logs have been tampered with, removing a way of tracking down the malicious user. All because update-passwd didn't bother to respect the NSS settings, and modified the local group file in an unsafe way.

This is not a particularly contrived situation; as part of a team which manages several thousand Unix systems from multiple vendors (and which is finally in the process of moving to a centralized user repository), I see local-remote UID/GID mismatches pretty regularly. It usually doesn't result in this kind of privilege escalation, but then, maybe we just missed it. :)

As such,I maintain that this bug at least enables a security problem, if not causing one outright.