Subject: Re: bin/2905: setting environment vars from login
To: None <current-users@NetBSD.ORG>
From: Greg A. Woods <>
List: current-users
Date: 11/04/1996 11:24:11
[ On Sun, November  3, 1996 at 17:55:00 (-0800), Curt Sampson wrote: ]
> Subject: Re: bin/2905: setting environment vars from login
> The problem here is that in this particular instance, *all* tools on the
> system may be `security critical.'

Well, that depends on your local policy.  In a general purpose unix
system though I'd say that only setuid-root programs are secruity
critical.  As you begin to implement a more restrictive policy, more and
more tools become responsible for enforcing that policy too.

> Unix itself really has only three levels of access: root, normal
> user, and none at all. Many sysadmins need to add the ability to
> have access levels between `normal user' and `none at all.' Generally,
> this is done by running a certain program from the login prompt. Then
> we have only to worry about what the user can do from within that
> program, rather than what the user can do with access to any program
> in the system.
Yes, so?

> Quite often, we rely on environment variables to determine what
> that user can do.

Maybe you do, but I never have beyond a well defined policy where I know
at all levels which environment variables are innocuous, and which are
not, and usually a simple grep of the source tree will show me where my
policy might be violated, or possibly where I must add another variable
to the list of dangerous data bins.

>      If the program allows shell escapes, setting the
> SHELL environment variable to a different program may let us disable
> shell escapes, for example.

Well, that depends on your security policy and how it is implemented.
Generally though, assuming you can disable shell access by setting SHELL
to something non-shell-ish, isn't really going to be very effective,
*especially* on a *BSD machine.  In most cases, esp. as the tools become
more effective, it's important for the tool itself to know it's running
in a restricted environment and "do the right thing".  Giving it a bogus
SHELL value as a hint to invoke the security policy is a *bad* idea.

(This is one scenario where triggering behaviour based on the value of
argv[0] is probably the most elegant form of implementation possible,
esp. in a binary-only environment.)

> In short, it's much easier to secure a particular program if we
> can count on a fixed environment, rather than a random one. Adding
> the ability to set environment variables in the login prompt defeats
> this.

I thought it was well known that security-sensitive unix programs should
*never* rely on anything in the environment, since *obviously* that's
data that can be modified by the user, and therefore cannot be trusted.

However in some environments certain compromises have been made in order
to allow implementation of the most flexible restricted environment
possible.  But may of us have been there, done that, at *least* 10 years
ago.  Check out an old SysVr2.2 manual for the details.  There's no
magic involved, and at least in such systems where *only* environment
variables are important, this is a *trivial* problem to solve in a
nearly provable manner.  Doesn't SCO UNIX meet C2 while *still* allowing
this feature????  I think so.

In SysVr3 and before there is/was a restricted shell (and a retricted
editor), and since there are not likely any other unknown ways of
tripping up chroot, it's much easier to build a true restricted
environment.  In *BSD these features have been partially given up
(though I suppose with source it's easy for an expert systems programmer
to add them back, N times, provided the other bugs/holes are also
closed), so you can't expect to easily build a retstricted environment
in the first place.  Therefore why worry about setting innocuous
environment variables from login?  If it's done right it won't even
cause problems in the future, let alone now.

If NetBSD as a collective group wants to support restricted environments
as a *real* feature, then we should spend our time making them possible
in the delivered environment instead of falling back on our laurels and
saying "Use the Source".

> This is really asking for a complete re-working of the Unix security
> model. Regardless of whether or not this is an unfair thing to ask,
> but I think it would be best to do that before we add the ability
> to set environment variables on login, rather than after.

No, I don't think so.  At least not the UNIX security model I grew up
with since V7.  The model I know has one, and only one, privileged state
(i.e. euid==0, as you implied in your opening paragraph), and everything
else is derrived outside the kernel, including whether or not access is
given (for any uid).

Perhaps you missed my point.  There are already far more risky things in
*BSD than just allowing login to set known innocuous environment
variables.  Worrying about the future impact of such a feature, while
not worrying about current problems, is not very productive,
*especially* in face of the fact that if login does allow setting of
innocuous environment variables then programmers will (hopefully) be
more inclined to think about the implications of environment variables
ahead of time and decide which are not innocuous.  I don't mind
extending the policy login enforces in the future, but I do mind not
deciding ahead of time that it needs to implement a standard policy.

Poor integration of new features with the current security policy, or
trying to change the current security policy without understanding all
of the implications, is where any of this falls down, and awareness is
the only real solution, though doing the integration as close to the
NetBSD core as possible will help since those folks can be assumed to be
more aware than most, I hop!  ;-)

							Greg A. Woods

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