OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: so, just how many library environment variables can specify filnames?????
From: Robert Elz (kremunnari.OZ.AU)
Date: Wed Nov 22 2000 - 07:46:34 CST

    Date: Wed, 22 Nov 2000 04:30:30 -0500 (EST)
    From: woodsweird.com (Greg A. Woods)
    Message-ID: <20001122093030.5BC5B4proven.weird.com>

  | Or any other privileged process. The FreeBSD bug I mentioned was in
  | login, which is not setuid and thus not protected in the same ways.

Other than via exploiting bugs in things like telnetd that allow the
obscure environment strings to be sent over the net, how does a normal
user get an environment variable into a non-setuid privileged process?

Either the user has privileges already, of the process is setuid, or
the process runs with the permissions of the user (and clearly imposing
rules in the latter case is absurd, the user can always compile their
own code to do whatever they like).

setuid processes are the only way to increase privilege in unix, and
hence the only interesting case - as the enironment is inherited,
there's no way you can effect daemon processes.

  | Oddly enough almost all the proposals to fix the more generic bug of
  | this nature will prevent side-effects from the "read" part, and at least
  | the open_as() proposal will also prevent them from the "open" part as well.

Yes, there have been several proposals all of which seem as if they
could work - the O_REGONLY is clearly the simplest, easiest to
implement, and likely to be safe (though it would mean that people
could no longer store their HOSTALIASES or TZ on an unmounted floppy...)
Alan Barrett's "open if stat buffer matches" clearly the most general
and perhaps even the cleanest, open_as() is somewhere in between,
and probably the one of the three worth dropping first (being as it
isn't trivial, and isn't complete either).

  | In other words it doesn't just look dangerous -- it *is* dangerous!

Of course, so are lots of things, the trick is to avoid the danger,
while keeping the functionality - not to say "I don't need that, so
you can't have it".

  | Are you saying that we should entrench our habits and usages with every
  | feature that comes along, regardless of whether it is actually dangerous
  | at the time, or whether it's just potentially dangerous because it goes
  | against the generic rules for safe designs, only to end up in this
  | situation where people don't want to lose a feature no matter how
  | dangerous it might have become in the mean time? You can't eat your
  | cake and still have it too.

No, I'm saying that we need to weigh up the benefits of features that
are proposed, against the risks. Then take whatever steps we can to
reduce, or even eliminate the risks, whenever the benefits suggest that
the feature is worthwhile.

  | Furthermore there's at least a couple of existing alternatives to the
  | dangerous version of the $TZ feature,

No there aren't - there's no conceivable way to enter a complete
timezone spec in the TZ variable as a literal (if there were, the
file format would never have been created in the first place).
About all that is possible is to have it handle the current time,
and a couple of transitions (the last two, last & next, or the next two).
That is, unless you live in one of those very rare areas of the world
where the timezone rules are, and have always been nice and regular.
Many of us don't. That just isn't good enough.

kre