Date:        Mon, 13 Nov 2000 19:46:33 +1100
    From:        matthew green <mrg@eterna.com.au>
    Message-ID:  <12762.974105193@eterna.com.au>

  | you're asking that the library trust it's caller.  that will never be
  | the case....as much as we would like it to be.

Actually, this is a bit backwards - the library in this case is a
pretty trivial innocuous file reader.   The part doing the trusting
is the application - which is setuid - and then which is trusting
that the library isn't doing anything to subvert it behind its back.

That HOSTALIASES can be aimed at a file which can cause unwanted effects
when the library (knowing nothing of any special privs it might just
happen to have) access it is the problem.

It seems to me that the only correct solution which can really work in
these cases is a library audit, make it clear which library routines
are subject to end-user (as distinct from application) manipulation of
their actions, either directly, or (as here, indirectly about half a
dozen layers deep into the name->address translation routines) and then
make sure that all setuid applications that call those library routines
do so with the uid set in the appropriate form for correct operation.

The "caller is setuid so I will ignore HOSTALIASES" (and other similar
"solutions") are just band aids to avoid having to think about correctly
fixing the applications - in all of these cases the base problem is the
setuid application, and a set of poor assumptions about the library
routines that are used (in the truly old days, almost no programs used
any library routines, other than libm sometimes, and the sys call
interfaces - in that kind of environment, a setuid program would know
exactly what was open to abuse, because it was all there directly in the
immediate source - these days we are building more and more complex
libraries for greater convenience, which is fine most of the time, but
a nightmare for setuid solutions).

Keeping setuid programs small, lean, and clean is the way to fix
all of this, though whether we can really do that thoroughly enough
to fix all the problems is anyone's guess.    One kernel mod might
be to ignore the setuid bit on any binary larger than 32KB?

kre