[ On Mon, November  4, 1996 at 12:57:41 (-0800), Curt Sampson wrote: ]
> Subject: Re: bin/2905: setting environment vars from login
>
> I'm glad you have full source code for all of your programs.
> Unfortunately, I don't, and I don't care to modify login to screen
> certain variables every time I install a new program for which I
> don't have source.

Unfortunately I have not always had full source for all my systems.

However I do always have source for new programs I install, or am at
least able to write secure wrappers for these programs that can carefuly
enforce control over the environment of the new application.  (I've
never installed a system which was required to enforce a strict security
policy but which didn't have a compiler, and I wouldn't recommend that
anyone try to do so.)

In other words I've never had a problem enforcing local policy on
binary-only SysV boxes where login allows setting innocuous environment
variables.  All the system-supplied binaries implement a consistent and
documented policy and clearly define the noxious environment variables
that login won't allow the user to over-ride, and of course if I was
adding any new programs to such systems they were either in source form
or wrapped by local source and I could easily stop them from doing
"stupid" things based on random variables that might be under a user's
control.  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.

> This policy is also a lot of work to maintain. If you're going to keep
> a local source tree and maintain this sort of policy, I can't see what
> the problem would be with running a modified login. Whereas those who
> don't want to do this sort of thing shouldn't be exposed to these sorts
> of security risks by putting this in the standard distribution.
 
Obviously I still don't see the problem of adding this feature to NetBSD
so long as we clearly maintain a self-consistent security policy about
which variables are prone to causing problems.  So long as all new tools
which are *integrated* into NetBSD are monitored for such risks, the
overall increase in risk to the system, as delivered, is zero, while the
net gain in functionality is positive, and we'll be bringing the
standard distribution more in line with the capabilities of equivalent
commercial operating systems.

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.

So, perhaps I'm suggesting the argument in this case should be more in
the line of: if you don't like this feature then you're free to comment
it out in your local builds.  However since it's relevant to building a
secure system it would be much better to carefully and fully integrate
it into the system once at the "source" so that those who obviously do
want this feature won't be at risk from their own mistakes aggravated by
the need to constantly and repeatedly re-invent the wheel, so to speak.

I.e. the problem with forcing people to maintain a locally modified
version of a program as critical as login is that you're opening many
more people up to increased risk since each and every one of them will
have to duplicate effort.  If the system supplies a well tested
implementation of a feature then the risk of locally maintained copies
containing bugs will be nil.

If we do it once, and we do it well, *everyone* will benefit, including
those who don't want the feature in their local environments (since we
can make it easy for them to disable too).

Of course if we stole one more feature from SCO (which is also in
SysVr4), we could even allow control of this feature at run-time!
(i.e. /etc/default/*)

Fear mongering about increased security risks where there are none is
not productive.  If you know of any such documented risks, then by all
means let us hear about them so we can ensure our implementation does
not suffer the same fate.

-- 
							Greg A. Woods

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