Newsgroups: comp.unix.admin
Path: utzoo!utgpu!jmason2
From: jmason2@gpu.utcs.utoronto.ca (Jamie Mason)
Subject: Running random user programs as ROOT?!
Message-ID: <1991Jun21.233414.10848@gpu.utcs.utoronto.ca>
Summary: Can be hazardous to your system's health
Organization: University of Toronto Computer Services Advisor
References: <91161.131540SCHDAVZ@YaleVM.YCC.Yale.Edu> <70@pyuxf.UUCP> <319@dlss2.UUCP> <22940@ogicse.ogi.edu> <1991Jun19.191124.20380@cs.utk.edu> <1991Jun20.023256.12713@gpu.utcs.utoronto.ca> <677526078.470@mindcraft.com>
Date: Fri, 21 Jun 1991 23:34:14 GMT

In article <1991Jun20.023256.12713@gpu.utcs.utoronto.ca> I wrote:
|	Of course, the administator's mistake was *not* that he had "."
| in is path.  His mistake was that he helped a user with a problem with
| their personal files *as root*.  What he/she should have done is su'ed to
| the user with the problem, then used *that* shell to solve the problem.
| Remember that root can su to anyone *without* entering a password.  By
| poking around the user's files *AS THE USER*, there is no chance of
| accidentally executing something nasty as root.

In article <677526078.470@mindcraft.com> karish@mindcraft.com (Chuck Karish) writes:
> I don't think this is true on systems that support saved-set-user-ID.
> A Trojan horse program could su back to root under some circumstances.

	I hope not.  Su sets *real* and effective user ID.  The
saved-set-user-ID should be wiped out by the su program when SUing to the
user's account.  Otherwise SU is *horribly* broken.

	Please remember that SU is setuid root.  So it runs as root,
whether or not is was called by root.  The difference is that it does not
demand a password when called by root.

	So if you could use saved-set-user-ID to seteuid() back to root
when SU had been called by root (your argument), then you could since SU
is setuid rood, do it when it was called by J. Random User.  Of course
that is *really* horribly broken, so I hope your argument is wrong.

>It's often worth trying to reproduce a problem from several different
>logins.  Problems caused by user environment settings can be
>difficult to diagnose.

	And problems cause by sysadmins running pontentially dangerous
user programs *as root* can be difficult to diagnose, detect, or repair.

Jamie  ...  Lurker in the Process Table
Written On  Friday, June 21, 1991  at  07:29:37pm EDT