Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ut-sally.UUCP
Path: utzoo!decvax!decwrl!pyramid!ut-sally!std-unix
From: std-unix@ut-sally.UUCP (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: TZ and TERM per process (really environments and setuid scripts)
Message-ID: <4106@ut-sally.UUCP>
Date: Mon, 3-Feb-86 16:10:14 EST
Article-I.D.: ut-sally.4106
Posted: Mon Feb  3 16:10:14 1986
Date-Received: Tue, 4-Feb-86 00:01:48 EST
References: <4029@ut-sally.UUCP>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 29
Approved: jsq@sally.UUCP

From: harvard!mit-eddie!frog!rfm (Bob Mabee)
Date: Sun, 2 Feb 86 20:56:51 est
Organization: Charles River Data Systems, Framingham MA

Several posters have mentioned that a setuid program or shell script can be
compromised by suitably altering the environment list.  This is a nasty
problem because tools (the shell, library functions) are likely to develop
new dependencies on the environment as new functionality is added, and we
are not likely to think of all the possible attacks.

I suggest that the kernel should close this hole once and for all, by clearing
the environment at the point in exec() where it implements the SETUID mode.

Some programs operate incorrectly when invoked from single-user mode, or the
startup scripts, or cron, because the environment is deficient.  For example,
the time zone is likely to revert to EST.  This change forces at least the
SETUID programs to be tested (implies debugged) under such conditions.
Obviously, the time zone should default to something inappropriate for the
development site, so you notice during testing.

Instead of clearing the environment, exec() could substitute a canonical
administrative environment, from a kernel holding area or from a file.
Note that exec() is in a good position to fetch arbitrary files - it uses
high-level kernel facilities just like a user program.

				Bob Mabee @ Charles River Data Systems
				decvax!frog!rfm

Volume-Number: Volume 5, Number 31