mkdir() and security hole ***** ONE-LINE FIX !! ****

[Bill.Stewart.[ho95c]]

nice(-255);	/* always win race condition  - fixes security bug */
		/* nice(-255) is not very nice, but root has its privileges */
		/* works with official mkdir and Doug's */

The original articles in news.admin pointed out a race
condition in the /bin/mkdir used by V7 and System V
older releases.  (mkdir runs setuid root, mknod's a
directory then chowns it to getuid() - if you're fast you
can rmdir the directory and ln /etc/passwd, especially if
you nice -19 mkdir.)  Doug Davis posted a public-domain
mkdir which he claimed fixed the problem.  Other people have
pointed out that it helps, but doesn't prevent the race
condition, and it's free source for people who only have
binary systems.

Put a nice(-255) as the first line of your mkdir, and you'll
"never" lose the race!!  The race condition worked, because
on a loaded system, you could guarantee that sometimes your
rm-and-link hack would happen between the mknod() and the chown(),
as long as you ran the mkdir niced so it had a low priority.

But remember that you're setuid root, so you don't have to be
nice() just because some luser told you to be.
Nice(-255) truncates to the nastiest priority a user-level
process can have, no matter how nice() the mkdir had
originally been.

Under System V, nice() returns -1 if it can't get the nice value you
asked for; my 4.1BSD manual doesn't say what it does.  It's good
programming practice to do

	if (nice(-255) == -1) { perror("mkdir fails:"); exit(1); }

but it really can't happen since you're root.

====== commentary =======
The security bug was REAL, for systems using a setuid-root mkdir
command instead of mkdir() system call.  SVR3.0 and 4.2BSD both
have mkdir(), but earlier System V, V7, and 4.1BSD all use the
older approach.  The nice(-255) isn't a 100% cure, but I've been
unable to break any of our systems since we installed it, and
it doesn't break anything.

	Multiprocessor systems may still have some risk.
	
We looked at some alternatives like Doug's and Dan's that
might have the potential to cause trouble - mkdir is a critical
enough program that I'd want to thoroughly test anything that
wasn't really simple before I used it, but this change is as
transparent as any I could think of.  We may still try some more
hacks, but this is cheap, easy, and works for uniprocessors.

-- 
#				Thanks;
# Bill Stewart, AT&T Bell Labs 2G218 Holmdel NJ 201-949-0705 ho95c.att.com!wcs
#
#	News.  Don't ask me about News.