Subject: Re: bin/2905: setting environment vars from login
To: Greg A. Woods <>
From: Curt Sampson <>
List: current-users
Date: 11/05/1996 08:00:01
On Tue, 5 Nov 1996, Greg A. Woods wrote:

> Surely nobody in a security-consious environment installs a
> setuid-root binary from some arbitrary third party without trusting that
> third party *and* without fully understanding how it enforces a security
> policy.

A setuid root binary, no. But I seem to be having a great deal of
difficulty making you preceive that the problem is not just root
access, it's shell access of any kind.

And yes, in some situations one does install a binary in a security-
conscious environment without trusting the vendor. I'm thinking in
particular of an accounting system I installed for a client which
was a disaster in terms of Unix security. One of the things I ended
up doing was to set it up so that program is run on login, and none
of the regular users nobody has access to a shell. I didn't have
a C compiler availiable. You think it would have been better for
me in this situation to have to tell the client to go out and spend
a significant amount of extra money on a C compiler and my time to
write a wrapper? What's the benefit here, aside from increasing
the value of my consulting contract?

> If you're saying you do (want to be able to) add tools which rely on the
> values in "random" environment variables to define local security
> policy, then all I can say is that your local security policy isn't very
> well thought out.

Yes. In some poorly documented systems I don't even have any
assurance of all the environment variables the damn program uses.

You'll note I've never objected to you doing your little `security
policy' thing on system utilities. Just leave the login unable to
set environment variables by default. Otherwise it's just one more
stupid little security hole that someone is going to forget to plug
one day, and it's going to hurt them. Unix is already a huge amount
of work to secure; making it more work just to add a relatively
useless feature should be the decision of the local site administrator,
not of the vendor.


Curt Sampson		Info at
Internet Portal Services, Inc.	
Vancouver, BC   (604) 257-9400		De gustibus, aut bene aut nihil.