System V.2.2 setuid() broken

[Boyd Roberts]

In article <3942 at rpp386.UUCP> jfh at rpp386.UUCP (The Beach Bum) writes:
>this `feature' prevents a trojan horse from doing a
>
>	if (getuid () == 0) {
>		setuid (0);
>		chown ("/bin/sh", 0, 0);
>		chmod ("/bin/sh", 04711);
>	}
>
>thereby giving you the famed password free su command.
>

No, you have just _lost_ BIG.  How do I become root with this _alleged_
trojan horse.  Are we saying that our systems are full of holes?  I
think we are.  Are we not?

Security violations usually occur due to bad file-system permissions
or dozey setuid programs.  Think about ex*preserve, back a while.

If getuid() returns 0, I AM ROOT, dammit.  I AM _REALLY_ ROOT.
When I am _really_ root I can do anything I damn please, except
on System V.  Check out the System V exec code, where it does the
setuid (gid) stuff.  It is broken.

System V setuid() is severly broken.  Here I am, _really_ root,
but _effectively_ some dumb mortal (back in the _old_days_ root
was not affected by setuid (gid) bits) and I can't set my real
and effective uid to my real uid.  Surely some mistake.

It is NOT the UNIX way to systematically break the kernel to
support paranoid delusions of grandeur.  Security hole, trojan
horse... don't make me laugh.  Where are the kernel hacks of
yesteryear who actually _understood_ the kernel?

At times like these I reach for my V6 source listing and
read the code.  In those days the original implementors
_knew_ the deal and did the _job_.  It _never_ ceases to amaze
me at what comes out of AT&T (USG?).

Come System 5.5 and I'll be satisfied.  OS/360 written in C.


Boyd Roberts			boyd at basser.cs.su.oz
				boyd at necisa.necisa.oz

``When the going gets wierd, the weird turn pro...''