All of the arguments against this feature that I've seen so far either
fail to notice that the proposed feature isn't going to allow anyone to
fiddle with any environment variables that are known to be dangerous in
a stock system, or are of the variety that say "all knives should be
dull".

Anyway a hopefully brief response to what I hope were the most 
important points and questions in Curt's message:

[ On Tue, November  5, 1996 at 22:38:48 (-0800), Curt Sampson wrote: ]
> Subject: Re: bin/2905: setting environment vars from login
>
> On which system utilities. Given that the only things running are
> /bin/login, possibly an initial shell, and the application program,
> where do the other utilities come in (unless someone's snuck in
> some changed environment varibles)?

If you give me an initial shell (i.e. /bin/sh), I may be able to exploit
some race conditions to gain interactive shell access.  However I won't
have to muck with any environment variables to get them.  If there are
no race conditions to be exploited, then no amount of fiddling with
innocuous(*) environment variables will get me any further, unless of
course you've given me an explicit hole by using some variable in
/etc/profile that you don't first initialize.

(*) I.e. variables other than SHELL, PATH, LD_LIBRARY_PATH, or any
others that a grep of the source tree shows might be risky.

> Ok. Forget, for a moment, the words `shell access' and think,
> instead, `ability to execute an arbitrary program or read from or
> write to an arbitrary file. Do you not see that many programs, even
> if they don't allow shell escapes of any kind, can be convinced to
> do interesting and (to a hacker) useful things if we can manipulate
> their environment variables.

The proposed feature will not allow an arbitrary user to execute
arbitrary programs or read or write arbitrary files.  The proposed
feature won't let you manipulate the environment variables of programs
that might be of any utility to a cracker.

>   If you're in doubt, go back to the
> BoS list and look at many of the HP attacks that were posted
> recently. A lot of these are executed by convincing a program to
> write a file it shouldn't be writing.

URL's or other direct references please -- I don't run HP/UX.

Were these incidents the result of somone manipulating environment
variables with /bin/login?  Were these programs supplied with the
operating system?  If so, I guess the 64k question is why didn't vendor
prevent /bin/login from allowing these variables to be changed?  Can you
show how these attacks would work against NetBSD in conjunction with the
proposed change to /bin/login?

> In other words, you're going to make me spend half my life writing
> wrapper programs so that you can add a feature that I don't want.

No, I've suggested that this feature should be controlled at runtime,
hopefully through a de facto standard /etc/default/login control file,
and I'd even suggest extending the run-time control to allow an astute
admin to add more "not-to-be-fiddled-with" variables to the list login
won't allow the user to manipulate.

Unfortunately on systems less forward thinking than NetBSD you would
still be forced to write wrappers, yes, but that's life.

> Well, I had no idea that any version of login did this. What's
> going to happen to some admin a year or two down the road who missed
> this discussion? He's going to get bitten. This is why it should
> be explicitly enabled by the administrator.

Well, they're going to RTFM, as you should have, or at least we must
assume they will, so he won't get bitten unless he's unable to
understand the implications.  Yes, the documentation needs to be as
clear and obvious about this and all other potentially risky features.

After all, knives *are* supposed to be sharp, and ropes can be tied to
hanging trees.  We can only protect people from screwing up with the
software we provide in the system.  If someone adds some new program
without taking into account such a feature, then they get all they
deserve.  The vendor is not responsible for accidents caused by a sharp
knife, provided the knife doesn't cut through the vendor supplied
scabbard (and then only morally! ;-).

> Keep in mind, also, that you've not dealt with the problem of the
> admin who wants something particular executed in /etc/profile,
> before the user goes on to do whatever it is he wants to do. How
> do you secure that?

Well, first you modify /bin/sh so it defaults to "trap '' 1 2 15", etc.,
(at least while it's running /etc/profile) then you put the commands you
want in /etc/profile.  Have I missed anything?  Remember the proposed
change won't let anyone fiddle with SHELL or PATH or LD_LIBRARY_PATH (or
anything else that we can easily identify with a grep of the source tree
as something which might present a risk).

The only *real* risk we're adding is that measured by adding one more
not-so-obvious interdependency in the system sources.

-- 
							Greg A. Woods

+1 416 443-1734			VE3TCP			robohack!woods
Planix, Inc. <woods@planix.com>; Secrets Of The Weird <woods@weird.com>