Bug 3840

Summary:	uids are reused without effective file cleanup
Product:	[Retired] Red Hat Linux	Reporter:	dharris
Component:	shadow-utils	Assignee:	Cristian Gafton <gafton>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	low	Docs Contact:
Priority:	medium
Version:	6.0
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	1999-08-24 01:11:41 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description dharris 1999-06-30 21:25:14 UTC

The uid allocation algorithm in the useradd program allows
uid reuse, and the userdel program makes no attempt to
cleanup the files of a user. Together this is a bad problem
when you consider setuid scripts.

Here's how the uid reuse happens: the useradd program
simply finds the largest uid in the in the auto-select uid
range (by default 500 to 60000) and adds one to it to get
the new uid. If we delete a user with the largest uid in
that range (i.e. the most recently created user) then their
uid will be re-used by useradd when the next user is added.

This is a big deal for me. I am setting up a virtual
hosting system where I am allowing virtual domain users to
setup and remove additional users on the fly with a web
based interface. A hacker simply creates a new user, then
creates a setuid shell as that user in one of his
directories, then deletes the new user leaving the setuid
shell. The next user added to the system is now compromised
because that setuid shell exists with the same uid. Repeat
this hack whenever a user is added and its extra deadly.

Now you might say that it is my responsibility to remove
files belonging to a user when I remove them. In fact the
userdel program takes this viewpoint. But when I considered
how to actually purge the system of the user's files, I
could not see a way to do it. The hacker just sets up
multiple setuid shells as the compromised user and uses
them to re-recreate any shells that I delete. Because I
have to sweep through the filesystem to delete the files, I
simply can't delete all of the setuid shells. That is
unless there is some way to ban that user from running. Or
set a disk quota of zero. But that's a lot of pain just to
remove a user.

A better solution is just not to reuse uids. Well, at least
not until 55000 users have been allocated. But that will
take quite a long time, effectively closing the security
hole I described above.

I think this that Solaris does not reuse uids, so I'm not
alone in my thinking here.

I have a patch that modifies useradd to not reuse uids
until it has wrapped through the entire range. It stores a
single number of state info in /etc/nextuid. I'll send this
patch through e-mail in a bit, along with my RPM file diff.

Comment 1 Cristian Gafton 1999-07-29 07:07:59 UTC

userdel has no way of tracking user's files. As for the allocation
algorithm, it is hard to design a scheme that will accomodate the kind
of environment that you are setting up.

If you allow interactive creation of accounts with shell access from
the net then the fear of hackers should be the lower of your
concerns...

Comment 2 dharris 1999-07-29 19:07:59 UTC

Oh no, I'm not asking for userdel clean up the files. I just want
useradd to prevent UIDs from being re-used. The problem comes when
you have UID reuse without the file cleanup. The solution is to
simply avoid reusing the UIDs.

Here's what happens with the current useradd:

# useradd userone
# id userone
uid=504(userone) gid=504(userone)
# userdel userone
# useradd usertwo
# id usertwo
uid=504(usertwo) gid=504(usertwo)
# dir -d /home/user{one,two}
drwx------   4 usertwo  usertwo      /home/userone
drwx------   4 usertwo  usertwo      /home/usertwo

First this is nasty for the system administrator, because now they
don't know the /home/userone files are owned by usertwo, instead of
showing up as a numeric user id what would tip the system
administrator off that they should be deleted. Second, this can be a
security hole if "userone" had shell access while the account
existed. They could have setup a setuid shell as "userone" which will
now be owned by "usertwo".

Here is how the patches Ive submitted behave:

# useradd userone
# id userone
uid=1502(userone) gid=1502(userone)
# userdel userone
# useradd usertwo
# id usertwo
uid=1503(usertwo) gid=1503(usertwo)
# dir -d /home/user{one,two}
drwx------   2 1502     1502         /home/userone
drwx------   2 usertwo  usertwo      /home/usertwo

Clear indication that the /home/userone files are not owned by a
valid user and no possible security hole where userone can setup
files that end up being owned by usertwo.

Anyway, this idea that UIDs should not be reused is not original to
me.. I remember that Solaris worked that way and I think they
commented on it in their useradd man page.

Comment 3 dharris 1999-07-29 19:12:59 UTC

Blaugh.. remove the words "they don't know" from the "First this is
nasty for the system administrator..." sentence and it makes a lot
more sense. Sorry for the stupid typo.

Comment 4 Cristian Gafton 1999-08-24 01:11:59 UTC

No matter what the policy for uid allocation is, somebody will have
issues with it. I feel that the current behavior is the best one given
the choices...